제품 실패의 근본적 원인 - Marty Cagan

이 글은 Marty Cagan의 The Root Cause of Product Failure 영상을 정리한 내용입니다.

최악의 제품 생성 프로세스

아이디어 → 비즈니스 케이스 → 로드맵 → 요구사항 → 디자인 → 빌드 → 테스트 → 배포

우리는 용병팀이 아닌 선교사 팀이 필요하다. - John doar

• 이 프로세스는 용병 팀(외주를 의미한 것 같음)의 프로세스이다.
• 대다수의 회사의 일하는 방식이나, 대부분의 노력이 실패로 이어질 확률이 높다.
• 세부사항에 대해 전혀 유연하게 대처할 수 없다.
• 고객 확인(Customer Validation)이 너무 늦다.

 

1. 아이디어

엔지니어 : 가장 사용자와 가까운 레벨에서 요구사항과 문제점을 식별할 기회가 많음

데이터 : 사용자는 그들이 원하는 것을 알지 못하고, 비즈니스적 시각을 고려하지 않음

→ 아이디에이션 Step에서 엔지니어와 많은 이야기를 나누어야 한다.

 

2. 비즈니스 케이스

기술 제품에서 가장 중요한 것은 알 수 없는 것을 아는 것이다.

돈을 얼마나 벌 수 있는가? 

작은 테스트를 하기 전까지 얼마나 좋은 제품일지 알 수 있는 근거가 없다. 

돈을 얼마나 써야 하는가?

그 기능 추가가 어떠한 긍정적인 결과를 가져올 것이라는 기대를 하지 말라.

 

3. 로드맵

비전에는 고집을 부리되 세부 사항에는 유연해야 한다. - Jeff Bezos

• 실제 개발에 들어가면 로드맵보다 훨씬 복잡할 것이다.
• 로드맵 아이템의 반절 이상은 실패할 것이다.
• 나머지는 성공할 ‘가능성’이 있는 것이며, 3~4의 이터레이션을 통해 성공할 수 있다.
• 하지만 스타트업에겐 이 이터레이션을 돌릴 시간과 돈이 없다.

 

4. 요구사항

• 프로덕트 매니저의 일은 단순 이해관계자/사용자의 요구사항을 모으는 것이 아니다
  → 디자인부터 배포까지를 관리하는 프로젝트 매니저의 일이다.

 

5. 디자인

• PM이 와이어프레임과 인터렉션 디자인을 하는 것은 잘못되었다.

 

6. 엔지니어링 + 테스트

• 엔지니어가 코드’만’ 짠다면 이는 엔지니어의 절반의 가치만 활용하는 것이다.
• 위 최악의 제품 생성 모델에서 엔지니어는 충분한 문맥과 상황을 이해하지 못하고 있다.

 

 

Agile

• 집중해야할 것은 산출(Output)이 아닌 결과(Outcome)이다.
  → 만약 사용자 온보딩이 30일이 걸리는 경우, 30분 이하로 줄이는 목표를 갖고, 수 십 번 해결을 시도 해라.
• Lean-Startup은 가장 싸고 빠른 아이디어로 검증하는 것이다.

 

 

The best team

아이디어 → 발견(Discovery)
                  → 전달(Delivery)

• 무수한 아이디어들이 존재하며, 좋은 팀은 많은 아이디어들을 시도한다.(주에 10~20개)
  • 100개의 아이디어를 전달하기위해 최소 500개의 아이디어를 발견해야한다.
  • OKR은 Roadmap의 좋은 대안이다.
• 제품은 가치 있고(Valuable), 유용하며(Usable), 실현가능(Feasible)해야한다.
  • 가치있는 것은 사용자가 구매하고, 선택하는 것이다.
  • 유용한 것은 사용자가 사용할 수 있는 것이다.
  • 실현 가능한 것은 우리가 만들 수 있고, 이해관계자를 설득할 수 있는 것이다.
• 발견(Discovery)
  • MVP Test를 진행한다.
  • 모든 구성원 제품을 만드는 일 (린스타트업, 고객 발견, 개발, QA 등)
  • PM+Designer+Engineer등 모두가 협업해야한다.
• 전달(Delivery)
  • PMF을 찾는다.
• MVP는 제품이 아니다
  • 제품은 비즈니스 스케일을 키우고 운영할 수 있는 것이다.
  • MVP는 실험이다.