이 책은 <개발 함정을 탈출하라>는 프로덕트 매니지먼트에 대해 주로 이야기한다. 하지만 프로덕트 매니저만이 이 책을 읽어야 하는 건 아니다. 결국 개발 함정을 탈출하려면, 즉 프로덕트 매니지먼트 중심의 회사가 되려면 구성원, 경영진 모두 알아야 할 이야기를 하고 있기 때문에, IT 업계에서 일하는 사람들이라면 모두 읽는 게 좋다.

프로덕트 매니지먼트에 대한 이론과 더불어 ‘마케틀리’라는 가상의 회사의 이야기가 함께 어우러져 진행된다. 사실 이론 부분을 읽으면서는 새롭게 알게 되는 내용이 많으면서도 살짝 지루했는데, 마케틀리의 회사 이야기가 나올 때면 소설을 보는 것 같아서 전체적으로는 흥미롭게 읽을 수 있었다.

사실 제대로 이해하지 못한 부분도 있다. 예를 들면, 책에서 나오는 ‘프로덕트 카타’ 프레임워크가 왜 좋은 건지, 일본어인 ‘카타’는 무슨 뜻인지 모르겠다. 한글로 검색해봤을 때 아직까진 프로덕트 카타를 다룬 아티클은 없는 것 같다. 영어로 검색해서 더 파악해봐야 될 것 같다.

이 책은 도서관에서 빌려서 봤는데, 사서 주기적으로 옆에 두고 읽으며 공부하는 게 좋을 것 같다는 생각이 들었다.

이 책을 읽으면서 배웠던 내용들을 나만의 글로 최대한 해석해서 다시 적어본다.

프로덕트 ≠ 앱, 기능, 인터페이스

• 프로덕트가 곧 앱이나 기능, 인터페이스라고 생각하는 경우가 많다.
  • 프로덕트는 가치를 전달하는 수단이므로 앱, 기능, 인터페이스는 프로덕트의 일부라고 보는 게 맞다.

프로덕트 매니저가 가져야 할 태도

• 프로덕트 매니저는 겸손해야 한다. 자신이 모든 것을 알지 못한다는 걸 받아들일 때 모르는 것을 배울 수 있다. 무엇보다 자신의 아이디어만이 좋다는 생각은 버려야 한다.

지표

• “출시하는 제품의 성공을 어떻게 판단하시죠?”라고 물으면
  • 기한에 맞춰서 개발한 것, 버그 없이 잘 돌아가는 제품으로 개발한 것 등을 이야기한다.
  • 이는 아니다. 고객의 문제를 해결하여, 성공 지표에 도달해야 제품이 성공했다고 볼 수 있다.

성공 지표 설정하기

• 프로덕트 지표는 프로덕트를 포함하여 사업의 건전성을 파악하는데 도움을 준다.
  • 프로덕트의 상태가 어떤지를 계속 체크해야 어떤 행동을 할지 결정할 수 있다.
• 시간만 흐르면 계속 올라가는 ‘허영 지표’는 프로덕트를 만드는 데 도움이 되지 않는다.
  • 예를 들면, 앱 다운로드 수, 회원가입자 수, 로그인 횟수, 페이지뷰 수 등이다.
• 허영 지표를 도움이 되는 지표로 보려면 추적한 시간을 추가하여 비교해서 보면 된다.
  • 지난 달보다 이번 달 사용자 수가 늘었는가?
• 허영 지표 외에도 산출량 중심의 지표를 추적하는 경우도 프로덕트를 만드는 데 도움이 되지 않는다.
  • 예를 들면 출시한 기능 수, 완료한 스토리 포인트, 작성한 사용자 스토리 개수 등
  • 팀의 생산성과 관련이 있을지 몰라도 프로덕트 성과 분석에는 도움을 주지 않는다.

지표 프레임워크

• 해적 지표 (AARRR)
• 하트 지표 (HEART)

지행 지표 vs 선행 지표

• 지행 지표는 ‘유지율’ 같이 당장 결과가 즉시 나오지 않는 지표다.
• 선행 지표는 ‘활성화율’ 같이 당장 확인하기 어려운 지행 지표를 미리 추측할 수 있는 지표다.

문제 탐구

문제 이해하기

• 사용자들과 실제로 대화하면서 문제를 파악해야 한다.
  • 사용자 조사, 설문, CS로 접수된 고객 의견은 사용자 관점에서 문제를 바라볼 수 있게 도와준다.
• 사용자 조사 시, ‘왜’ 그런 행동을 하는지에 집중해서 문제를 파악해야 한다.
  • IT 업계 사람이 아니더라도 보통 사람들은 해결 방안을 내는 걸 좋아한다.
  • 고객이 사용 방안을 제시할 때 ‘왜’ 그런 생각을 했는지를 계속 물어보면서 문제를 파악하자.
• 고객이 하라는 대로, 제시하는 대로 기능을 만들어서는 안 된다.
  • 문제를 해결하는 건 프로덕트 매니저의 업무이다.

해결책 탐구

• 경쟁사가 출시하는 기능을 그대로 똑같이 영혼없이 베껴와서는 안 된다. 제대로 쓰이고 있는지에 대한 평가를 외부에서는 알 수 없다. 충분한 차별화 전략 없이 모방해서는 안 된다.
• 문제에 대한 깊은 탐구 없이 해결 방안을 모색하는 단계로 바로 뛰어드는 경우가 많다. 모든 해결 방안은 개인이나 조직의 편견에 좌우되기 마련이다. 그러므로 편견 없이 좋은 제품을 만들려면 사용자로부터 배우고 실험하는 수밖에 없다.
• 편견에 갇혀 특정 해결 방안을 중심으로 실험하려고 할 때 자포스의 UX 책임자 출신인 브라이언 칼마의 말을 기억하자.
  • “가치 제안의 핵심이 아닌 문제에 대해 특별하고 혁신적인 해결 방안을 만드느라 너무 공들여 시간을 쓰지 마세요. 누군가 이미 그 문제를 해결했다면 모범 실무를 보고 배워 그 방안을 도입하고, 데이터를 수집해 자신의 상황에서도 효과적일지 여부를 판단하세요. 그 과정을 반복하는 거죠. 가치 제안의 성패를 좌우할 핵심 요소를 위해 시간과 힘을 아껴야 합니다.”

실험

• 실험을 성과를 내기 위한 게 아니라 학습하기 위한 것이다.
• 실험을 하면 해결책이 가치 있는지를 판단하여 시간을 절약할 수 있다. 잘못된 제품 개발에 드는 기회비용은 너무 높다.
• 실험은 단기적이어야 하며, 신속하게 진행하여 가설을 검증해야 한다.
• 실험 결과가 나오면 개발했던 것, 즉 mvp를 전부 폐기하고, 안정적이고 탄탄한 확장 가능한 형태로 다시 구상해야 한다.

학습을 위한 실험 방법 3가지

대행

• 제품 대신 수동으로 결과물을 만들어 사용자에게 제공하며, 사용자도 이를 인지하고 있다.
  • 예를 들면, 표지를 직접 제작해서 만들어주는 서비스가 있을 수 있다.
• 지속하기 어려우므로, 성과가 있을 때는 확장 가능한 해결책을 찾아야 한다.

오즈의 마법사

• 대행 실험과 달리 오즈의 마법사는 결과물은 만드는 건 수동으로 하되, 진짜 출시된 제품처럼 보이는 실험이다.

콘셉트 실험

• 문제를 파악하기 위한 생성적 연구의 성격을 띈다.
• 사용자에게 콘셉트를 보여주어 반응을 체크한다.
• 확고한 통과, 탈락의 기준이 있어 사용자가 평가할 수 있게 해야 한다.

완료의 진짜 정의

• 개발이 완료되었다고 볼 수 있는 시점은 출시 전에 세워둔 성공 기준에 도달했을 때이다.
  • 개발해놓고 사용자의 반응을, 성과를 측정하지 않고 다음으로 넘어가는 경우가 많다.
  • 도달하지 못하고 있다면 계속 개선을 반복하여야 한다.

예산 책정

• 프로덕트 개발의 예산 집행은 미리 집행해 놓지 않고, 스타트업 투자처럼 진행하는 게 훨씬 현명하다.

프로덕트 중심 기업인지를 판단하기 위한 6가지 질문

1. 최근 개발한 기능이나 프로덕트 관련 아이디어는 누가 냈는가?
2. 최근 무산시킨 프로덕트는 무엇이었는가?
3. 마지막으로 고객과 대화한 것은 언제였는가?
4. 무엇이 목표인가?
5. 현재 무슨 일을 하고 있는가?
6. 사내 프로덕트 매니저들은 어떤가?