들어가며
프로덕트를 만드는 일을 하다 보면 자연스럽게 드는 질문이 있다. “우리가 제대로 된 것을 만들고 있는가?” 시간에 쫓기고 출시 일정에 매달리다 보면 정작 이 본질적인 질문은 뒤로 밀리기 마련이다.
나도 CTO로 일하면서 비슷한 경험을 많이 했다. 약속한 일정에 맞춰 기능을 출시하는 데 집중하다 보니, 정작 고객이 원하는 게 맞는지 확인하는 과정은 늘 후순위였다. 출시하고 나서야 “아, 이게 아니었구나”를 깨달을 때의 그 허탈함. 그래서 이 책(Continuous Discovery Habits)을 읽으면서 정리해두려고 한다.
Discovery와 Delivery
모든 제품 팀은 결국 두 가지 일을 한다. 무엇을 만들지 결정하는 것, 그리고 실제로 만들어내는 것. 전자를 Discovery(발견), 후자를 **Delivery(배송)**라고 부른다.
그런데 솔직히 대부분의 회사는 Delivery에만 집중한다. “약속한 시간과 예산에 맞춰 출시했나?”에 매몰되어 정작 “제대로 된 것을 만들었나?”는 질문을 잊어버린다. 이 책은 바로 이 불균형을 바로잡는 것을 목표로 한다.
한 가지 더 중요한 점이 있다. Discovery는 일회성 활동이 아니다. 디지털 제품은 절대 완성되지 않는다. 계속 진화할 수 있고, 진화해야 한다. 그래서 이 책에서는 팀이 새로운 제품을 발견하고 기존 제품을 반복적으로 개선할 수 있는 Continuous Discovery(지속적인 발견) 프레임워크를 소개한다.
제품 발견의 역사
Discovery가 어떻게 발전해왔는지 역사를 짚어보면 왜 지금 Continuous Discovery가 필요한지 더 잘 이해할 수 있다.
초창기: 비즈니스 리더가 결정하던 시대
소프트웨어 초창기에는 비즈니스 리더가 무엇을 만들지 결정했다. Discovery는 1년에 한 번, 연간 예산 프로세스에서 이루어졌다. 일정이 정해진 프로젝트가 특정 엔지니어링 팀에 할당되고, Product Manager는 작업과 예산, 일정만 관리했다. 때로는 비즈니스 요구사항을 제품 요구사항으로 전환하기도 했지만, 본질적으로 “결정”은 위에서 내려오는 것이었다.
문제는 뻔했다. 소프트웨어 개발은 예측 불가능해서 예산 초과, 기한 초과가 일상이었다. 비즈니스 요구사항이 고객의 요구사항보다 우선시되는 경우가 많았고, 제품을 출시한 후에야 고객이 만족하지 않는다는 사실을 인지하게 됐다. 엄청난 비용 낭비였다. 이런 유형의 팀을 **Delivery 팀(배달 팀)**이라고 부른다.
애자일 선언문 시대: 변화의 시작
애자일이 등장하면서 상황이 달라지기 시작했다. 애자일에서 강조하는 네 가지 원칙은 다음과 같다.
첫째, 짧은 주기와 빈번한 고객 피드백. 둘째, 지속적으로 유지할 수 있는 속도로 작업. 셋째, 고객 피드백에 빠르고 쉽게 적응할 수 있는 유연성 극대화. 넷째, 단순함 추구, 즉 극도로 최소한의 것만 개발하는 것이다.
스크럼과 칸반이 도입되고, UX와 유저 리서치를 통한 고객 피드백이 강조됐다. 그런데 여전히 문제가 있었다.
주기가 짧아지고 고객 피드백이 많아져도 원래의 아이디어를 고수하는 경우가 많았다. 예측 불가능한 작업을 여전히 예측하지 못했고, 스프린트가 오히려 지속적인 속도를 찾지 못하게 방해했다. 그리고 결정적으로, 제품 팀만 바뀐다고 되는 게 아니었다. 나머지 비즈니스가 바뀌지 않으면 유연성은 없는 것이나 마찬가지였다. 작동하지 않는다는 사실을 알게 되더라도 예산 범위 내에서 제시간에 맞춰 제공해야 했다.
사용성 테스트는 종종 프로세스 후반부에 너무 늦게 진행되어, 중요한 문제를 발견해도 이미 손쓰기엔 너무 늦은 경우가 많았다. 결국 팀은 계속 무엇을 제공했는지에 따라 평가받았다. 누가 사용했는지, 고객이나 비즈니스에 어떤 가치를 창출했는지 여부가 아니라.
그럼에도 불구하고 발전한 것들
그래도 애자일 덕분에 발전한 부분이 있다. 배포 주기가 단축됐고, 프로덕트를 더 잘 측정할 수 있게 됐다. 사용성 테스트를 더 잘하게 됐고, 작은 솔루션에서 큰 솔루션으로 반복하는 것도 잘하게 됐다.
다만 여전히 무엇을 만들지 결정하는 것은 어려웠다. 그래도 더 잘 측정하게 되면서 이 문제를 훨씬 더 심각하게 인식하게 됐다.
Discovery의 진화
결국 무엇을 만들지 결정하는 주체가 바뀌기 시작했다. 비즈니스 이해관계자에서 프로덕트 매니저로, 다시 프로덕트 매니저에서 제품 팀 전체로. Discovery 과정 전반에 걸쳐 고객을 참여시키게 됐다.
가장 큰 변화는 이것이다. Discovery가 끝날 때 아이디어를 검증하는 대신, 처음부터 고객과 공동 창작하기 시작한 것이다. Delivery Cycle이 짧아지면서 Discovery Cycle도 짧아졌다. 그렇게 Continuous Discovery가 등장했다.
이 책의 대상: 제품 트리오
이 책은 “PM, 디자이너, 개발자”로 구성된 제품 트리오를 대상으로 한다.
최소한의 Discovery를 위해서는 이 트리오가 필요하다. 물론 그 이상을 포함시킬 수도 있지만, 그에 따른 대가가 따른다. 속도가 느려지거나 의사결정의 균형이 깨지는 식으로.
필수 마인드셋 여섯 가지
많은 팀이 프레임워크, 도구, 방법론을 쫓는다. 새로운 혁신이 갑자기 제품 성공의 문을 열어줄 것이라고 기대하면서. 하지만 결국 이런 것들은 마인드셋이 동반되지 않으면 작동하지 않는다. 책에서는 여섯 가지 사고방식을 강조한다.
1. Outcome-oriented (결과 지향적)
결과물보다는 결과 중심으로 생각해야 한다. 이건 마인드셋이자 습관이어야 한다. 출시하는 솔루션으로 성공을 정의하기보다, 솔루션이 고객과 비즈니스에 창출하는 가치로 성공을 정의하는 것이다. 고객의 삶에 미친 영향, 비즈니스의 지속 가능성과 성장에 미친 영향 등 Impact로 성공을 측정해야 한다.
2. Customer-centric (고객 중심)
고객을 세상의 중심에 두는 것이다. 비즈니스의 목적은 고객을 창출하고 고객에게 서비스를 제공하는 것이다. 고객의 요구를 비즈니스 요구와 동등한 수준으로 끌어올려 고객 가치 창출에 집중해야 한다. 비즈니스 가치뿐만 아니라.
3. Collaborative (협업)
Digital Product의 Cross-functional한 특성을 이해해야 한다. 분업화되어 단계별로 결과물을 전달하는 사일로화된 모델을 거부해야 한다. PM이 결정하고 디자이너가 디자인하고 엔지니어가 코딩하는 방식 말고, 각자가 가진 전문성과 지식을 활용하면서 팀이 함께 의사 결정을 내리는 모델을 받아들여야 한다.
4. Visual (시각)
말과 글이 아닌 시각화가 필요하다. 이 책에 소개된 습관은 그림을 그리고, 생각을 외부화하며, 아는 것을 매핑하는 것이다. 공간적 추론 능력을 활용하는 습관을 가져야 한다.
5. Experimental (실험적 사고)
Discovery를 잘하려면 가정을 확인하고 증거를 수집하는 과학자처럼 사고하는 법을 배워야 한다. 내가 옳다고 증명하려 하지 말고, 내가 틀렸을 수 있음을 확인하려는 자세가 필요하다.
6. Continuous (지속성)
Discovery를 프로젝트 초반에 하는 일로 생각하지 않아야 한다. 개발 프로세스 전반에 걸쳐 지속적으로 Discovery 해야 한다. 구체적인 내용은 이후 챕터에서 다룬다.
Continuous Discovery의 정의
이미 많은 제품 팀에서 린 고객 개발을 위한 고객 인터뷰 기본 질문 5가지, 고객 인터뷰, 사용자 테스트, A/B 테스트를 채택하고 있다.
그러나 이런 Discovery 활동들을 체계적이고 지속 가능한 방식으로 채택하여 제품 결정에 지속적으로 반영하는 팀은 드물다.
그렇다면 단순히 Discovery가 아닌 Continuous Discovery란 무엇인가? 책에서는 다음과 같이 정의한다.
고객과 최소 주 1회 접점 (At a minimum, weekly touchpoints with customers) 제품을 개발하는 팀이 주도하여 (By the team building the product) 소규모 리서치 활동을 수행하며 (Where they conduct small research activities) 목표한 결과를 달성하기 위해 노력한다. (In pursuit of a desired outcome)
제품 팀은 매일 의사 결정을 내린다. 일상적인 의사 결정에서 최대한 많은 고객 의견을 반영하는 것이 Continuous Discovery다. 제품 팀이 한 달에 한 번만 고객과 소통한다면, 그 사이 한 달 동안의 의사결정은 고객의 의견 없이 이루어지게 되는 것이다.
나가며
이 글을 정리하면서 다시 한번 느꼈다. 우리는 너무 Delivery에만 집중하고 있었다는 것을. “제시간에 출시했나?”보다 “제대로 된 걸 만들었나?”가 더 중요한 질문인데, 현실에서는 전자에 치여 후자를 놓치기 쉽다.
특히 여섯 가지 마인드셋 중 결과 지향적(Outcome-oriented) 사고가 와닿았다. 기능을 출시하는 것 자체가 아니라, 그 기능이 고객과 비즈니스에 어떤 가치를 만들어냈는지로 성공을 측정해야 한다는 것. 말로는 쉽지만 실천하기는 정말 어렵다.
다음 글에서는 Continuous Discovery를 실제로 적용하기 위한 프레임워크를 다룬다.
댓글