해당 글은 Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group) by Marty Cagan을 읽고 요약한 글입니다.
구린 제품을 만들기에 우리의 삶은 너무 짧다.
Life is too short for bad products.
1. 고객에게 전달할 해결방안이 어떤 요소를 갖춰야할지 자세하게 조사하는 것
- 해결방안을 만들 만큼 충분한 고객이 있는(=수요) 시장일 것
- 고객뿐만 아니라, 회사의 사업성에도 부합할 것
2. 고객가치를 지닌 해결방안을 확실하고(robust), 확장 가능한 방향(scalable)으로 실행하는 것
- 자신감을 가지고 해결책을 출시할 수 있어야 함
- 특정 누구에게만이 아닌, 많은 고객들에게 확장할 수 있는 제품일 것
⇒ 이 두 가지의 핵심은 ‘자신감 있게 출시할 수 있을 만큼, 빠르고 비용이 적은 있는 학습 방법’(= 제품 발견)이 필요하다는 것
1. 시장에 내놓을 만한 제품인지에 대한 증거를 모으는 것
2. 빠른 학습을 통해 잘못된 제품을 만드는 것을 방지하고 불필요한 자원 사용을 막는 것
3. 제품에 관한 주요 위험을 밝혀낼 수 있을 것
- 가치 위험 (value risk): 고객들이 기꺼이 사용할 것인가?
- 사용성 위험 (usability risk): 사용자들이 사용 방법을 터득할 수 있는가?
- 실현 가능성 위험 (feasibility risk): 만들 수 있는 제품인가?
- 사업성 위험 (business viability risk): 이 제품은 우리의 사업에 부합하는가?
1. 고객(혹은 이해관계자)이 제품이나 기능 아이디어를 알려주길 바라지 말 것
- 고객의 대부분은 기술적으로 어떤 것이 가능한지 아는 경우가 드물며, 안다고 할지라도 정말로 원하는 것이 무엇인지 모름
- 피상적으로 무엇을 원하는지 파악하는 것이 아니라, 기저에 깔린 핵심 문제를 파악하고 거기에 맞는 해결책을 만드는 것이 우리의 임무
2. 가장 중요한 것은 매력적인 가치를 만드는 것
-고객들이 구매/사용할 만큼의 필요한 가치를 만들어 내는 것이 가장 어려운 부분이자 핵심적인 것
- 제품 발견 과정의 대부분의 시간은 바로 이것을 알아내는 데에 투입
3. 개발뿐만 아니라, 좋은 UX를 만들어 내는 것도 성공에 매우 중요한 부분
- 제품이나 기능들이 사용자 경험에 최적화된 방식으로 사용될 수 있도록 연구할 것
4. 기능, 디자인, 개발은 깊게 상호 연관이 되어있다는 것
-과거 워터폴 모델: 시장이 기능(=요구사항, req uirements)을 이끌어내고, 기능은 디자인을 이끌어 내며, 디자인은 개발과 실행을 이끌어 내는 구조
-현재: 기능과 기술, 기능과 디자인, 기술과 디자인은 서로간 영향을 미치며, 굉장히 밀접한 관계(interwined)를 지님
5. 우리가 생각한 절대 다수의 아이디어들은 틀릴 것이라는 것을 인식해야 하며, 어느 정도 가치가 있는 아이디어라고 판단이 되어도 반복 검증이 필요함을 인식할 것
가장 중요한 것은 우리가 알 수 없는 것을 아는 것이다.
The most important thing is to know what you can’t know, Marc Andreessen
- 대다수의 아이디어들이 실패할 것이라는 것을 인식하며, 제품 발견의 주요 목적은 빠르게 학습하는 것이지, 검증하려는 것이 주요 목적이 아님을 인지할 것
- 핵심 문제를 해결할 수 있는 다양한 방법들에 대해서도 개방적일 것
가치가 있다고 보이는 아이디어도 반복 검증을 통해 확신할 수 있어야 함
6. 아이디어 검증 시에는 반드시 실제 사용자 및 고객을 대상으로 할 것
- 우리의 제품은 시장의 고객들에게 사용되는 것이기 때문에, 직접 고객을 대상으로 빠르게 아이디어에 대한 검증을 하여 의미있는 제품을 만들 수 있도록 해야 함
7. 제품 발견의 과정을 가능한 한 빠르고, 값쌀 것
- 제품 발견의 핵심은 ‘속도전’ → 수많은 상황에서 고객에 대해 학습할 수 있는 적합한 방법을 사용할 것
8. 실현 가능성은 제품 발견 과정에서 검증할 것
- 많은 팀들이 아이디어를 제품 발견 이후에 다른 팀에게 공유하는 경향을 가짐 → 하지만, 엔지니어가 스프린트 플래닝에서 제품팀의 아이디어를 처음 본다면 제품 발견 과정을 실패한 것
- 제품 발견의 내용을 지속적으로 업데이트 하면서, 실현 가능성을 빠르게 확인하고 시간을 절약할 수 있을 것
9. 사업성 또한 제품 발견 과정에서 검증할 것
- 실제로 제품을 만들기 전에, 사업의 핵심 관계자들을 만나 제품의 사업성에 대해 논의하고 합의할 것
- 사업성은 재무, 마케팅, 영업, 법률, 사업 개발 등 다양한 영역을 포괄하는 개념
- 프로덕트 매니저가 사업성에 부합하지 않는 제품을 만드는 것 만큼 회사 구성원의 사기를 꺾는 것이 없음 → 제품 발견 과정에서 다양한 부서 사람들에게 공유하며 제품 아이디어의 사업성을 논의해야 함
10. 제품 발견은 공유 학습 그 자체인 것
- 용병이 아닌, 선교사와 같은 팀 분위기를 만드는 것의 핵심은 함께 학습하고, 함께 발전하는 것
Product Discovery = All about fast / cheap / shared learning