De-risking: 프로덕트 팀의 시간을 날려 버리지 않으려면

프로덕트 팀, 리스크, 그리고 기회비용

스타트업이든 대기업이든 프로덕트를 만드는 팀은 항상 리스크(risk)를 짊어지고 있습니다. 무슨 리스크냐면, 커다란 기회비용(opportunity cost)을 지불할 리스크입니다.

당연한 얘기지만 프로덕트를 새로 만들 때, 또는 프로덕트에 새로운 기능을 추가하거나 기존 기능을 변경할 때는 팀(엔지니어, 디자이너 등)의 시간을 투입하게 됩니다. 5명 규모 프로덕트 팀이 2주일 동안 일해서 A라는 기능을 새로 만들었다고 해 봅시다. 여기에 투입된 시간은 5명 x 10영업일 x 8시간 = 400시간입니다. 꽤 많은 시간을 썼죠.

그런데 만약 A 기능을 사용자들이 외면한다면? 애초에 사용자들이 필요로 하지 않는 기능이었다면? 그러면 프로덕트 팀이 A 기능을 만드는 데 들어간 400시간은 그냥 날려 버린 셈입니다. 성과를 내고 회사 성공에 기여하는 데 400시간을 쓸 수 있었는데, 그 기회를 날려 버린 거죠. 기회비용을 지불한다는 것은 이런 뜻입니다.

프로덕트 매니저(product manager, PM)의 중요한 역할 중 하나는 이런 리스크를 줄이기(de-risking)입니다. 엔지니어와 디자이너들이 프로덕트를 만드느라 투입한 시간이 헛되이 날아가 버리지 않도록, 팀이 '될 만한' 프로덕트를 만들 수 있도록 하는 것입니다. 저는 새로운 기능을 기획하거나, 기능 명세서를 작성하거나, 아니면 프로젝트 관리를 하는 것이 아니라 de-risking을 하는 것이 PM의 가장 중요한 역할이라고 생각합니다.

이번 주 뉴스레터에서는 de-risking에 접근하는 데 도움이 되는 생각법들을 소개해 드리겠습니다. 먼저 프로덕트에 관해 구체적으로 어떤 리스크들이 존재하는지 알려드겠습니다. 그리고 리스크를 줄이는 여러 방법론들(A/B 테스트, 데이터, 정성 리서치, 고객 피드백, MVP) 중 무엇을 언제 활용하면 좋을지 알려드리겠습니다.

Four Big Risks: 프로덕트 팀이 시간을 날려 먹는 경우 4가지

앞에서 프로덕트 팀이 짊어지는 리스크는 큰 기회비용(opportunity cost)을 지불할 리스크, 다른 말로는 프로덕트 팀의 시간을 날려 버릴 리스크라고 이야기했습니다.

그런데 이런 설명만으로는 실제로 PM이 어떤 역량을 가지고 무슨 일을 해야 할지 이해하기엔 부족합니다. 저였다면 "음... 우리 팀이 귀중한 시간을 날려 먹지 않도록 열심히 해야겠군?🤔" 정도로만 생각했을 겁니다. PM이 어떤 액션을 해야 할지 파악하려면 프로덕트 팀에 구체적으로 어떤 리스크가 있는지 좀 더 손에 잡히게 정의할 필요가 있습니다.

다행히도 우리에게는 마티 케이건(Marty Cagan)이 남긴 복음서 "인스파이어드 (INSPIRED: How to Create Tech Products Customers Love)"가 있습니다. 사도 마티께서는 책을 사서 읽을 여유가 없는 사람들을 위해 블로그에 글도 남기셨습니다.

마티 케이건에 따르면, 프로덕트 팀이 시간을 날려 먹는 경우는 크게 4가지가 있습니다. (아, 물론 마티 케이건 본인은 '날려 먹는다'라는 속된 표현을 쓰진 않았습니다...)

1. 고객(사용자)들이 원하지 않는 프로덕트를 만들면 시간을 날려 먹게 됩니다. 이런 리스크를 value risk라고 합니다.
2. 사용자들이 이용하기 어려운 프로덕트를 만들면 시간을 날려 먹게 됩니다. 이런 리스크를 usability risk라고 합니다.
3. 프로덕트를 열심히 만들고 있는데, 알고 보니 기술적으로 구현하기 너무 어려워서 완성할 수 없다면 (그 사실을 엔지니어들이 이미 수많은 시간을 투입한 끝에서야 알게 되면) 시간을 날려 먹게 됩니다. 이런 리스크를 feasibility risk라고 합니다.
4. 고객들이 원하는 프로덕트를, 뛰어난 사용성으로, 기술적으로 완벽히 구현했는데 사업상 말이 되지 않는다면 (비용은 많이 드는데 돈을 벌 수 없거나, 법이나 규제 등의 문제로 배포할 수 없거나) 시간을 날려 먹게 됩니다. 이런 리스크를 business viability risk라고 합니다.

프로덕트 매니저라면 늘 이런 리스크가 있음을 인지하고, 어떻게 하면 우리 팀이 시간을 헛되이 날려 먹지 않을 수 있을지 방법을 강구해야 합니다. 일단 각 리스크에 대해 간단한 설명을 보태 보겠습니다.

(1 of 4) Value Risk: 고객들이 원하지 않는 프로덕트

어렵사리 출시한 프로덕트가 고객들로부터 외면받는 것만큼 프로덕트 팀의 속을 쓰리게 만드는 일도 없을 겁니다. 하지만 오늘도 어딘가의 스타트업들은 겪고 있는 일이기도 합니다. 고객들이 원하지 않는 프로덕트를 만들면 디자인과 엔지니어링에 들어간 막대한 시간과 노력은 송두리째 날아가 버립니다. 프로덕트 팀이 어마어마한 기회비용을 지불하게 되는 것이죠.

프로덕트가 고객들로부터 외면받는 데는 크게 두 가지 이유가 있습니다.

1. 첫 번째는 애초에 존재하지 않는 문제를 해결하려고 들었거나, 애초에 고객들이 갖고 있지 않은 욕구를 충족시키려고 들 때입니다.

   • 아무리 뛰어난 기술력과 매끄러운 사용성을 자랑한들, 문제나 욕구가 존재하지 않으면 고객들은 프로덕트를 이용할 이유가 없습니다.
   • 이런 프로덕트를 보면서 사람들은 말합니다. '이거 도대체 왜 만든 거야?'
   • 이런 리스크를 줄이기 위해 프로덕트 팀은 시장과 고객을 이해하기 위한 일들을 합니다. 정성적 리서치 등이 여기에 해당합니다.

2. 두 번째는 문제나 욕구는 제대로 짚었는데, 프로덕트가 그런 문제나 욕구를 해결해 주지 못할 때입니다.

   • 다른 말로, Problem-Solution Fit이 맞지 않는다고도 합니다. 솔루션(=프로덕트)이 문제를 해결해주지 못한다는 뜻입니다.
   • 예를 들어 직장인들의 시간 관리를 돕기 위한 앱을 만들었는데, 실제로 시간 관리에 별로 도움이 되지 않게 프로덕트가 만들어졌다면 고객들이 외면하겠죠.
   • 이런 리스크를 줄이기 위해 프로덕트 팀은 사전에 프로덕트 컨셉을 테스트하곤 합니다. 프로토타이핑(prototyping), MVP(minimum viable product) 출시 등이 여기에 해당합니다.

(2 of 4) Usability Risk: 고객들이 사용하기 어려운 프로덕트

충분히 사람들이 원하는 프로덕트를 만들었다고 하더라도, 사용자들이 그 프로덕트를 제대로 사용할 수 없다면 의미가 없습니다. 사용법이 너무 어렵거나, 사용자 경험이 논리적이지 않게 설계되어 있어 이해할 수 없는 경우가 여기에 해당합니다. 이런 리스크를 줄이기 위해 프로덕트 팀은 열심히 사용성 테스트(usability test)를 합니다.

(3 of 4) Feasibility Risk: 기술적으로 구현할 수 없는 프로덕트

아무리 좋은 컨셉의 프로덕트라고 하더라도 우리 팀이 그걸 기술적으로 구현할 수 없으면 무용지물입니다. 더 나쁜 것은, 엔지니어들이 한참 동안 시간을 쓰고 나서야 '어 이거 못 만들겠는데?'라고 알아차리는 것입니다. 이러면 그동안 디자인과 엔지니어링에 시간은 시간대로 투입했지만 결과물은 나오지 않는 최악의 경우가 됩니다. 이런 리스크를 줄이기 위해 엔지니어들은 사전에 기술 리서치를 수행하면서 이게 될 만한 일인지 판단합니다.

(4 of 4) Business Viability Risk: 사업상 말이 안 되는 프로덕트

잘 만든 프로덕트라 하더라도, 사업상 말이 되지 않는 경우가 있습니다. 대표적으로는 규제나 법률을 준수하지 않는 경우가 있습니다. 이 경우 프로덕트 팀의 시간을 날려 먹는 것은 물론이고, 추가적으로 법적 제재를 받을 수 있습니다.

또 다른 경우로는 비용과 수익 측면에서 수지가 맞지 않는 경우가 있습니다. 많은 사용자들이 즐겨 이용해서 서버 비용은 많이 나오는데, 사용자들이 돈을 지불할 의향은 없는 경우에 이럴 수 있겠죠. 운이 좋으면 투자금으로 몇 개월에서 몇 년까지 버틸 수 있겠지만, 지속 가능한 프로덕트는 아닙니다.

혹은 파트너들과의 관계 때문에 프로덕트를 출시하지 못하는 경우도 있을 수 있습니다. 중요한 협력사의 영역을 침범하는 프로덕트를 만들 경우, 회사에서는 협력사와의 관계를 잃지 않기 위해 프로덕트를 Kill 할 수도 있습니다. 이러면 역시나 프로덕트 팀의 시간을 날려 먹게 됩니다.

Business viability risk를 줄이기 위해 프로덕트 매니저는 우리 회사, 우리 사업의 구조를 잘 이해하고 있어야 합니다.

PM의 초점: Value Risk와 Business Viability Risk

프로덕트 매니저는 모든 리스크를 신경써야 하지만, 그중에서도 특히 value risk와 business viability risk를 신경써야 합니다. Usability risk는 프로덕트 디자이너가, Feasibility risk는 테크 리드가 가장 전문성을 갖고 해결할 수 있으니까요. (디자이너와 엔지니어에게 맡기고 PM은 손 놓고 있어도 된다는 뜻이 아니란 거 아시죠?)

A/B 테스트, 정성 리서치, MVP 등등...언제 어떤 방법을 활용할까

<스타트업을 위한 '실험'과 '가설' 개념 설명>에서 저는 리스크를 줄이는 가설 검증 방법들을 몇 가지 소개했습니다.

• 인터뷰나 설문조사 등 정성적 리서치(qualitative research)
• 아직 개발하지 않은 프로덕트의 수요를 파악하기 위해 랜딩페이지를 만들어서 하는 스모크 테스트(smoke test)
• A/B 테스트
• 기술을 개발하기 전에 일단 수작업으로 서비스를 제공함으로써 프로덕트에 수요가 있는지 알아보는 '메커니컬 터크(Mechanlcal Turk)', 혹은 '오즈의 마법사(Wizard of Oz)' 프로토타입

그런데, 위 글은 여전히 '우리 회사는 A/B 테스트를 하는 게 좋을까요, 아니면 정성적 리서치를 하는 게 좋을까요?'와 같은 질문에 대한 답을 주지는 못하는 것 같습니다. 혹은 '고객들을 자주 만나서 대화를 나누라고 하셨는데, 고객들의 말을 듣는다고 좋은 프로덕트를 만들 수 있을까요?'와 같은 질문에도 답을 주지 못하는 것 같습니다. 제가 컨설팅을 하면서 종종 듣는 질문이기도 하구요.

Eventbrite의 CPO인 케이시 윈터스(Casey Winters)가 쓴 글이 이런 질문에 좋은 답을 줄 수 있을 것 같아서 소개합니다.

두 가지 기준: 1) 사용자 수 2) 사용자의 Sophistication

앞에서도 설명했듯이 프로덕트를 개발하는 일은 기회비용(opportunity cost)이 큰 일입니다. 그래서 프로덕트 개발에 착수하기 전에 리스크(시간을 날려 먹을 위험)를 줄이는 작업(de-risking)이 필요합니다. 사용자 리서치, 데이터 분석, A/B 테스트 등이 de-risking 방법에 해당합니다.

그런데, 모든 프로덕트에서 똑같은 de-risking 방법을 사용하는 것은 바람직하지 않습니다. 케이시 윈터스에 따르면 우리가 어떤 방법을 사용해야 할지는 크게 두 가지 기준에 따라 판단할 수 있습니다.

1. 첫 번째 기준은 사용자 수입니다.
   • 사용자 수가 많을수록 데이터와 A/B 테스트가 유용합니다.
   • 반대로 사용자 수가 적으면 데이터와 A/B 테스트가 의미 없는 경우가 많아집니다.
2. 두 번째 기준은 사용자 Sophistication입니다.
   • Sophistication은 우리말로 번역하기가 참 어려운데, '사용자들이 프로덕트에 대해 얼마나 잘 아는가' 정도로 생각하시면 됩니다.
   • 사용자들이 프로덕트에 대해 잘 알수록 사용자 의견을 프로덕트에 반영하는 것이 도움이 됩니다.
   • 사용자들이 프로덕트에 대해 잘 모른다면, 사용자 의견을 프로덕트에 반영하는 것이 도움이 되지 않습니다.

두 기준을 축으로 해서, 우리 상황에 맞는 de-risking 방법을 고를 수 있습니다.

(1) 사용자 많음 / 사용자 Sophistication 낮음

• 많은 수의 사용자를 보유한 consumer 프로덕트가 여기에 해당됩니다.
• 사용자 수가 많기 때문에 데이터를 분석해서 사용자들의 문제를 찾아내기에 좋습니다.
• 물론 가끔 정성 리서치(심층 인터뷰 등)를 하는 것도 도움이 됩니다. 케이시 윈터스는 핀터레스트(Pinterest)에서 일할 때, 온보딩 개선을 위해 브라질, 독일, 프랑스 등 여러 국가에 방문해서 사용성 테스트를 진행했다고 합니다. (출처)
• 반면, 사용자 피드백(주로 '이런 기능 만들어 주세요' 하는 요청)은 그다지 유용하지 않습니다. 사용자들이 프로덕트에 대해 잘 모르기 때문에, 그들이 제안하는 솔루션은 좋지 않은 경우가 많습니다.
• 그래서 사용자들과 대화할 때는 그들이 제안하는 솔루션(요구하는 기능)은 무시할 필요가 있습니다. 사용자들이 원하는 것이 무엇인지 묻지 말고, 그들이 가진 문제가 무엇인지 파악하는 데 집중해야 합니다.
• 프로덕트 또는 기능을 빠르게 만들어서 A/B 테스트를 하는 것 역시 이런 프로덕트에서는 좋은 de-risking 방법이 될 수 있습니다. 사용자가 많아서 A/B 테스트에 필요한 샘플 사이즈를 비교적 빠른 시간 내에 확보하고, 의미 있는 결과를 빠르게 볼 수 있기 때문입니다.

(2) 사용자 많음 / 사용자 Sophistication 높음

• 많은 수의 사용자를 보유한 B2B 프로덕트가 여기에 해당됩니다.
• 이 경우 데이터와 정성 리서치에 더해서, 사용자 피드백까지 활용할 수 있습니다. 사용자들이 어떤 기능을 원하는지, 얼마만큼 그 기능을 필요로 하는지, 어떤 기능이 우선순위가 높은지 등에 대해 하는 말을 신뢰할 수 있기 때문입니다. (물론 기능 요청을 그대로 받아서 개발하면 된다는 뜻은 아닌 거 아시죠? 어디까지나 최종적인 판단은 프로덕트 팀이 해야 합니다)

(3) 사용자 적음 / 사용자 Sophistication 높음

• 사용자 수가 적은 B2B 프로덕트가 여기에 해당합니다.
• 사용자 수가 적기 때문에 데이터에서 문제를 발견해 내기 어렵습니다. 충분한 샘플 사이즈를 확보하기 어렵기 때문에 A/B 테스트도 유용하지 않습니다. 데이터와 A/B 테스트가 모든 프로덕트에 적합하지는 않다는 점을 기억해 주세요.
• 이런 경우에는 사용자(고객)들을 1대1로 직접 만나서 피드백을 듣는 것이 좋습니다.
• 안타깝게도 많은 스타트업이 사용자를 직접 만나고 피드백을 듣는 것을 피함으로써 de-risking 기회를 놓치고 있습니다. 그들에게 '고객들을 만나기 어려우신 이유가 무엇인가요?' 하고 질문하면, 대개 '개발 일정을 맞추어야 해서 고객들을 만날 시간이 없다'라고 답합니다. 좋은 결과를 내는 것보다 일정(하늘에서 내려온 일정도 아니고, 누군가가 임의로 정한 일정)에 맞춰 개발을 하는 것을 중요하게 생각하는 팀이 많다는 것은 안타까운 일입니다.

(4) 사용자 적음 / 사용자 Sophistication 낮음

• 사용자 수가 아직 적은 consumer 프로덕트가 여기에 해당합니다.
• 케이시 윈터스는 이런 경우 그냥 제품을 만들어서 배포하고 반응을 보라고 합니다.
• 물론 여기에는 '프로덕트 팀이 사용자들에 관한 충분한 인사이트를 갖고 있다'라는 전제가 깔려 있습니다. 그렇지 못한 팀이라면 사용자를 파악하기 위한 리서치가 필요하겠죠.

마무리: 프로덕트 매니저는 리스크 매니저

긴 글이라, 요약하면서 마무리하겠습니다. 이 글이 프로덕트를 만드는 여러분의 여정에 보탬이 되길 바랍니다!

• 프로덕트 팀은 커다란 리스크를 짊어지고 있습니다.
• 어떤 리스크냐면, 잘못된 프로덕트를 만듦으로 인해 팀의 시간을 헛되이 날려 버릴 리스크입니다.
• 이런 관점에서 보면 프로덕트 매니저(PM)는 '기능을 기획하는 사람'도 아니고, '프로젝트를 관리하는 사람'도 아닙니다. '프로덕트 리스크를 관리하는 사람'입니다.
• 프로덕트에는 크게 네 가지 리스크가 있습니다. Value risk, usability risk, feasibility risk, 그리고 business viability risk입니다.
• 네 가지 리스크 중에서도 특히 프로덕트 매니저는 value risk와 business viability risk를 줄이는 데 집중해야 합니다.
• 프로덕트 리스크를 줄이는(어떤 프로덕트/기능을 만들지 판단하는 근거를 마련하는) de-risking 방법에는 A/B 테스트, 데이터 활용하기, 정성 리서치, 고객 피드백 등이 있습니다.
• 프로덕트마다 유용한 de-risking 방법은 달라집니다.
• 데이터와 A/B 테스트가 모든 프로덕트에 적합하진 않습니다. 사용자 수의 많고 적음, 그리고 그리고 사용자들의 sophistication 정도를 고려해서 우리 프로덕트에서 어떤 de-risking 방법을 쓸지 정할 수 있습니다.

안내: 프로덕트 조직과 개인을 위한 코칭

프로덕트 조직, 혹은 개인(제품 리더, PM, PO 등)을 대상으로 한 코칭을 제공하고 있습니다. 아래 이야기들이 내 얘기로 느껴지는 분들께 도움을 드립니다. 자세한 내용은 링크된 페이지를 참고해주세요.

• 제품에서 해야 할 일들은 쏟아지는데, 어떤 기준으로 우선순위를 설정하면 좋을지 답을 내리지 못하고 있다. 명확한 방향성이 없이 그때 그때 급한 일을 쳐내는 식으로 일하고 있다.
• 지표를 개선해야 하는데, 어떤 식으로 접근해야 할지 모르겠다. 어떤 지표를 봐야 좋을지 모르겠다.
• 조직에 큰 영향을 끼칠 수 있는 의사결정을 해야 하는데, 하나를 택하면 포기해야 하는 것도 명확해서 쉽게 결정을 내리지 못하고 있다. 이로 인해 리더로서 자신감이 떨어진다.
• 제품 조직과 다른 부서 간 의견 차이와 갈등이 있다. 다른 조직의 입김 때문에 제품 조직이 꼭 필요한 일을 제대로 수행하기 어렵다.