제품 발견

실패하는 이유

• 프로젝트 관리만 하기 때문
• 프로젝트의 요구 사항을 제품을 잘 모르는 사람으로부터 수집하기 때문
• 검증을 마지막 단계로 넘기면서 큰 기회비용을 유발함

제품 개발에 관한 잘못된 전제들

• 소프트웨어 제품을 만드는 일이 간단하여 개발자가 아닌 사람들이 주도할 수 있다는 착각

소프트웨어 제품의 특징

• 제품을 잘 모르는 사람들은 좋은 솔루션 아이디어를 내놓치 못함
• 소프트웨어는 예측이 어려움

방법

프로덕트 디스커버리

• 어떤 것을 만들지 결정하기
• 어떤 식으로 해결할지, 어떻게 잘 활용할지 찾는 과정
  가치있고 사용성있고 구현가능하고, 사업에 도움되는 솔루션 만드는 것에 집중하자

프로덕트 딜리버리

• 시장의 유저와 고객들에게 제품 전달하기
• 안정적, 확장 가능성, 성능, 유지보수 부분에서 퀄리티 있는 제품을 만들어서 시장에 내놓는 것

이터레이션 방식으로 프로젝트 진행하기

실험과 가설 검증 제대로 알기

Assumption

Value (Desirability) Assumptions

• 가치 관련 Assumptions이 틀릴 수 있는 리스크
• 현실에 부합하지 않으면 제품 조직의 시간과 자원이 낭비됨

Usability Assumption

• 사용성
• 유저이해성
• 기능발견성

Feasibility Assumptions

• 기술적 구현 가능성
• 존재하는 기술 및 가능한 것
• 기술적 숙련도

Viability Assumptions

• 사업적 타당성 : 비용과 수익, 법과 규제, 운영 등의 다양한 측면 고려

함정

• A/B테스트 주의
• 전형적인 방법론 복붙하듯 사용하지 말기 : Key Assumptions을 정의하고 검증하기

Assumption 검증하기

Value Assumtption

• 문제 검증이 중요
• 심층 인터뷰 이용
• 간단한 설문 조사도 방법이 될 수 있음
• 시제품 반응보기
• 유저 행동 데이터 파악

Usability Assumption

• 사용성 테스트

Feasibility Assumptions

• 엔지니어의 역할이 큼!
• PM은 우려되는 부분에 대해 엔지니어와 협의
• 엔지니어가 의도를 정확하게 이해할 수 있도록 커뮤니케이션하기

Viability Assumptions

• 법, 규제 관련 타당성을 법률 전문가에게 문의하기
• 고객들의 지불의사를 검증하기 위해 - 심층 인터뷰를 적극 활용
• 사전판매 등으로 Commitment를 활용!

검증하기 어려운 Assumption

• 지표 개선

Risk와 Evidence 기준으로 바로 실행할지 검증 먼저 할지 결정하기

제대로 된 전략

ICE Score 활용

전략의 역할

• 뭘 하지 않을 것인가를 정하는 것
• 우리가 뭘 하지 않을지를 결정해야 의사결정의 복잡성을 낮출 수 있다.
• 의사 결정의 판단 기준을 가지고 전략을 정한다. - 제대로 된 전략과 집중할 영역을 구체적으로 할 수 있음.

개념적 지도 그리기 - 기회 솔루션 트리

목표 성과 정의하기

기본 전제

• 니즈, 페인 포인트, 욕구를 분석하여 성과 달성을 위한 기회로 삼기
• 고객 중심으로 성과를 내고자 하는 접근법

기회를 찾는 방법

• 기회를 찾기 위해 고객에 대한 깊이 있는 이해를 해야한다.
• 제품의 기회들을 리스트 형태로 나열하면 이해하기가 좀 어려워서 트리 구조를 통해 시각적으로 파악

기회 맵핑

• 여러 기회를 하나의 상위 기회 밑에 그룹핑하기

그룹핑 방법

• User Journey(사용자 여정)에 따라 그룹핑 할 수 있음.
• 사용자가 처음 제품에 들어왔을 때
• 온보딩을 하면서 제품을 익힐 때
• 제품에 익숙해지고 깊이 이용하게 될 때

집중할 기회 영역 정하기

• 상위 기회에서 하위 기회로 내려가기

기회의 판단 기준

• 사람들에게 미치는 영향력의 크기 (인원 수)
• 사람들에게 미치는 영향의 빈도
• 사람들에게 미치는 영향력의 정도 (중요도)
• 회사의 전략과 방향성이 잘 맞는지
• 강점과 약점을 비교하였을 때 낼 수 있는 임팩트

기회와 솔루션 다양하게 탐색하기

• 처음 떠오르는 아이디어는 제일 안 좋은 아이디어!
• 다각도로 여러가지 관점에서 솔루션 아이디에이션하기
• 다양한 관점에서 Assumption을 점검하고 제일 유력한 솔루션을 검증하고 실행하기
• 근거가 낮은 assumption은 테스트, 근거가 높은 assumption은 실행

정리

• 주관적인 판단이 필요함
• 객관적인 정답을 찾을 수 없음
• 기회와 솔루션을 구조화, 맵핑할 수 있는 거만으로도 큰 의미가 있음!

단계

1. 하나의 목표 성과 설정하기
2. 기회(니즈, 욕구, 페인포인트) 발굴하기
3. 기회 맵핑하기: 그룹핑, 세분화 등
4. 집중할 기회 정하기
5. opportunity space 탐색한 뒤에 솔루션 아이디에이션하기
6. 솔루션 assumptions 검증 및 실행하기

개념적 지도 그리기 North Star Framework

North Star Metric

• 제품 조직이 영향을 끼칠 수 있다고 믿어지는 레벨의 지표
• 중장기적 사업 성과 처럼 너무 높은 레벨의 지표는 부적합
• 지표가 개선되었을 때 중장기적 사업성과에 큰 도움이 될거라고 믿어지는 지표
• 이미 지표가 충분히 높은 경우 리텐션율을 높이기 위한 것도 부적합

Bet

책임 있는 의사결정권자들이 이해하는 것

• 불확실성 속에서 결단을 내리고 실행해야한다.
• 데이터를 모아도 100% 확신할 수 없다.
• 인과관계를 파악하기 위해 실행을 해봐야한다.
• 사전 검증은 맞지만, 어느 순간에는 최선을 다해 수립한다.

input > opportunity > intervention

주기적으로 확인하기

• 6개월 ~ 1년마다 점검하기
• 필요하면 지표 바꾸기
• 사업의 방향성 잘 생각하기
• 중장기업 사업 성과에 큰 영향을 미치는 다른 지표를 생각하기

인풋 지표

• NSM이 바뀌면 input 지표도 바뀌어야함
• NSM이 유지되더라도 새로운 인풋 지표 아이디어를 생각해내야함

기회, 솔루션

• 리서치를 하면서 유저 행동에 영향을 끼칠만한 방법들을 찾아보고 계속해서 업데이트하기

공통점

• 성과내기라는 ill- structured problem에 구조 부여
• Opportunity space와 Solution Space를 충분히 탐색하기
• 의사결정에 도움을 주는 개념적인 지도