brunch

매거진 PM의 일상

You can make anything
by writing

C.S.Lewis

by 진용진 Mar 31. 2024

Continuous Discovery란?

지속적인 발견의 습관 저자 Terresa Torres 웨비나 요약

Continuous Discovery Habits(지속적인 발견의 습관)의 저자 Terresa Torres가 웨비나(The What & Why of Continuous Discovery - March 2024)를 진행해서 관련 내용을 요약해 봅니다. 제품팀 문화에 관심 있으신 분들께 도움이 되었으면 좋겠네요 :)



1. Product Delivery에서 Product Discovery 전환하는 트렌드

제품 개발에 있어 두 가지 주요 트렌드 (산업에 따라 5년~20년)가 관찰되고 있다.


첫번째 많은 기업들이 continuous delivery model 채택하고 있다. continuous integration, continuous deployment 용어에 익숙하면, 이러한 변화가 continuous discovery로 제품 개발 문화의 변화를 가속화하고 있음을 눈치챌 수 있다. 코드를 지속적으로 배포하니, 당연히 지속적으로 무엇을 만들어야할지 결정을 내려야하기 때문이다. (즉, 단순히 build-ship-maintain 모델의 한계 인식을 깨달은 것이다.)


두번째는 팀이 무엇을 만들지 결정할때 고객을 그 과정에 포함시키는 것이 필요하다는 것을 인식하기 시작한 것이다. 결국 중요한 것은 빠른 피드백 루프를 갖추는 것이다. 매일 매일 무엇을 만들때 우리가 올바른 방향성으로 간다는 것을 어떻게 확신할 것인가?


2. Continuos Discovery 란?

Weekly touch points with customers,

By the team building the product,

Where they conduct small research activities,

In pursuit of a desired product oucome.



3. Weekly touch points with customers

지속적인 피드백 메카니즘을 통해 모든 제품 개발의 의사결정을 고객의 input을 통해 진행한다는 의미이다. 제품 팀은 하루 종일 그것에 대해 생각하고, 모든 인터페이스 및 기능을 알고 있다. 하지만 고객은 항상 제품팀이 이해한만큼 또는 의도한 것처럼 제품을 경험하고 있지 않는다. 이것이 “지식의 저주”이다. 우리가 결정을 내릴 때 전문가 관점에서 내리기 때문에, 고객의 관점에서 결정을 내려야 한다는 것을 잊어버린다. 이 문제를 해결하기 위해 매주 고객과 대화를 하면서, 우리의 사고방식과 고객의 사고방식 사이의 격차를 줄이는 것이다. 


고객과 대화에서 주의점은 만든 기능을 검증하는 검증 마인드셋에 빠지는 것이다. 우리는 보통 모든 작업을 수행한 뒤 마지막에 검증을 한다. 디자이너는 디자인 작업을 완료하고 사용성 리서치를 통해 검증하고, 엔지니어는 배포 후에 QA 및 A/B 테스트로 검증을 한다. 하지만 고객과 co-create하는 마인드셋으로 바꾸면 모든 것이 다 완료된 것 보다 이른 시점에 무엇을 우리가 할지 빠르게 피드백을 받을 수 있다. Continuous Discovery 핵심 구성 요소는 고객과의 지속적인 피드백 루프이다.



4. By the team building the product

보통 프로덕트 매니저가 요구 사항을 수집하고, 디자이너에게 전달하고, 그 다음 엔지니어에게 전달했다. 이러한 분리는 효율적으로 보일 수 있지만 실제로는 그렇지 않고, 많은 재작업이 발생할 수 밖에 없다. Product trio 개념은 유연하다. 꼭 프로덕트 매니저, 디자이너, 엔지니어에 한정할 필요는 없다. 관련된 역할이 참여하면 더 나은 결정을 내릴 수 있다. 하지만 의사결정은 팀이 클수록 움직이 느려지기 때문에 균형있게 맞춰야한다. 제품 트리오가 desired outcome부터 이를 달성하기 위한 opportunity(pain point, unmet needs), 기회를 만들어주는 solution 여러가지를 discover 해야한다.


역사적으로 우리는 제품 팀을 output으로 관리했다. 비즈니스 리더와 이해관계자들이 무엇을 만들어야 할지를 정의한다. 그들은 특정 기능을 언제까지 만들어달라고 요청한다. 제품팀은 12개월짜리 로드맵을 받고 그 타임라인에 그 output을 개발했는지로 평가를 받는다. 


이 모델의 문제는, 기술에서 가장 멀리 떨어진 사람들, 경영진과 이해관계자들이 무엇을 만들어야 하는지 결정하는 데 가장 적합한 사람이라고 가정한다는 것이다. 우리는 이점이 사실이 아니라는 것을 알고 있다. 제품팀이 연초 또는 그 전 년도 중후반에 우리의 연간 계획을 수립할 때 다음 해에 우리가 무엇을 만들어야 할지 예측할 수 있다고 가정한다. 


지난 몇 년 동안 우리는 얼마나 많은 불확실성과 모호함이 있는지, 그리고 우리가 얼마나 적응해야 하는지를 배웠다. 그래서 이제 우리는 제품팀이 output 마인드셋을 넘어서, outcome 마인드셋으로 이동하는 것을 보고 있다. 즉, 특정 기능을 만들어달라고 정의하는 대신, 우리의 비즈니스가 이러한 특정 결과를 달성해야 한다고 이야기를 하는 시점인 것이다.



5. Where they conduct small research activities

고객과 접점의 시작은 고객 인터뷰이다. 매주 한명의 고객 인터뷰를 진행할 수 있는 방법을 찾는다. 월요일 아침에 오피스에 출근했을 때, 아무 것도 하지 않아도 이미 캘린더에 인터뷰가 잡혀 있는 상황이다. 고객이 제품이나 서비스를 사용하는 동안 자발적으로 옵트인할 수 있는 방식을 고려한다.


고객 인터뷰의 목표는 솔루션을 탐색하는 것이 아니라 기회(opportunity)를 발견하는 것이다. 기회는 충족되지 않은 고객의 unmet needs, pain point이다. 그것들을 기회(문제점 정의가 아닌, 더 큰 범위에서)라고 부른다. 왜냐하면 그것들은 제품팀이 고객의 삶에 긍정적으로 개입할 기회들이기 때문이다. 인터뷰를 하면서, 제품팀은 이 opportunity space를 구축한다.



6. In pursuit of a desired product oucome

인터뷰를 하면서, 제품 트리오는 기회(opportunity)를 수집하고, opportunity space를 매핑하여 outcome을 달성할 수 있는 모든 다양한 방법에 대한 큰 그림을 얻는다. 제품 트리오는 여러 기회 중에서 outcome 달성을 위해 가장 큰 기회(opportunity)를 선택할 것이다. 기회가 시작점이 될 것이고, 해당 기회에 대해 최소한 세 가지 다른 솔루션을 살펴볼 것이다. 이제 compare and contrast decision이라고 부르는 것을 설정할 것이다. Whether or not decision이 아니다. 대부분 팀은 ‘해야 하나, 말아야 하나?’, ‘이 아이디어가 좋은가,아닌가’ 방식에 이숙하다. 


이러한 의사결정의 문제점은 우리가 고객의 요구사항을 듣고, 바로 첫번째 아이디어로 뛰어든다. 그리고 우리는 이 아이디어를 개발해야하나 말아야 하나? 좋은가 아닌가? 이러한 틀에서 일을 한다. 이러한 틀에서 일하는 것의 함정은 인지적 편항에 빠지게 되는 것이다. 몰입 상승 효과(escalation of commitment)라 불리는데, 우리가 아이디어에 더 많이 투자할수록 그 아이디어와 자신을 동일시하게 된다. 흔히 우리가 ‘아이디어에 반했다’라고 표현하는 상황이다. 우리가 아이디어에 반할 때, 두 번째로 확증 편향(confirmation bias)에 빠진다. 우리가 사랑한 아이디어가 좋다는 증거를 더 쉽게 받아들이고, 아이디어에 결함이 있음을 제안하는 증거를 놓치게 된다.  


compare and contrast decision을 설정함으로써 이를 해결할 수 있다. 여러 솔루션을 살펴보고, 서로 비교하면서 어떤 아이디어가 적합할지 판단하는 것이다. 솔루션은 기능적 구현 보다 assumption 테스트를 통해 진행되며, outcome, opportunity 와 align하여 desirable, viable, feasible 관점에서 고려한다. 누군가 우리의 솔루션을 원하는지? 우리 비즈니스에 있어 개발할 필요가 있는 것인지? 우리가 구축할 수 있는 것인지? 고객이 쉽게 사용할 수 있을지? 잠재적 리스크, 윤리적 이슈는 없는지?



Continuous discovery team은 여러 아이디어 중에서 가장 위험한 가정을 테스트하여 가장 유망한 아이디어를 찾는다. '내 아이디어가 좋은가 아닌가'에 대한 몰입 상승 효과와 확인 편향의 함정에서 벗어나게 하며, 비교와 대조(compare and contrast)를 통해 결정을 내리게 한다. Continuous discovery team은 매주 고객과 인터뷰를 진행하여 충족되지 않은 oppotunity(니즈, 페인 포인트)를 밝혀내고, 이를 통해 opportunity space를 매핑하고 솔루션을 탐색한다. 타겟이 되는 oppotunity에 대해 최고의 세 가지 아이디어를 선정하고, 그 아이디어들의 기본 assumption을 신속하게 테스트하여 최적의 솔루션을 선택한다. 이 솔루션은 개발 백로그로 이동되어 엔지니어가 구축을 시작하며, 이 과정은 우리가 충분히 discover 했는지를 확인하는 피드백 루프 역할을 한다. 이후 팀은 반복하며, opportunity space를 가로질러 일함으로써 outcome에 영향을 미치기 시작합니다. 이것은 효과적인 Continuous discovery team의 일하는 문화이다.


브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari