트리니들은 Consumer Science 기반의 product develop 을 추구합니다. Consumer Science는 현재의 상태를 관찰하여 문제를 정의하고 그 문제를 해결하기 위한 가설을 세워 이를 증명해 나가는 프로세스로 아래와 같은 과정을 통해 진행됩니다.
목차
1.
Observation : 현재 상황을 관찰하여 문제 요소를 찾아냅니다.
2.
Define Customer Problem : 관찰 요소를 기반으로 해결해야 할 다양한 문제를 정의합니다.
3.
Form Hypothesis : 문제를 해결하기 위한 여러 가지 가설을 설계합니다.
4.
Validate : 가설들을 실제로 테스트 해보며 어떤 방법이 최선인지 검증합니다.
5.
Iterate : 위 과정을 반복합니다.
문제의 발견 | Observation
문제를 정의하기 위해서는 먼저 현재 상태를 정확하게 파악해야 합니다. Observation은 관찰을 통해 필요한 정보를 얻는 과정이며, 고객 리뷰, 외부 분석 자료 등 다양한 데이터를 활용할 수 있습니다. 원하는 데이터가 없다면 User Test나 Survey를 통해 직접 데이터를 수집하기도 합니다.
구분 | 설명 | 예시 |
사용자 행동 데이터 | Product 내에서 사용자의 행동에 의해 발생하는 데이터 | Funnel data |
내부 데이터 | 회사 내부에서 관리되는 데이터 | VOC, Log data |
외부 데이터 | 외부 컨설팅/평가 기관 또는 공공기관 자료 | |
사용자 테스트 | product 기획, 디자인에 대한 아이디어를 얻거나, 새로운 문제를 발견,수집하기 위한 조사 방법 | Interview, Focus group usability test |
서베이 | 설문등을 사용하여 데이터를 수집하고 분석하는 방법 | |
Intuition | 경험에서 우러나오는 느낌적인 느낌 | |
Benchmark | 출시된 경쟁사의 Product를 관찰, 분석 |
Observation 예. User Behavior Data : Pirate Metrics (해적 지표) AARRR
문제 정의 | Define Customer Problem
Product 관찰(observation)을 통해 상태를 파악했다면, 이제 문제를 명시적으로 정의해야 합니다. 좋은 문제 정의에서 좋은 솔루션이 나옵니다. 좋은 문제를 정의하려면 문제의 ‘본질’에 접근해야 합니다.
사람들은 생각보다 많은 편견이 있습니다. 학습과 경험은 선택의 순간에 판단의 기순이 될 수 있지만 때로 그로인한 지나친 편견은 중요한 요소를 인지하는데 방해가 됩니다. 객관적으로 문제를 정의하기 위해서는 편견을 지우고 오로지 현상에만 집중해야 합니다. 대표적인 편견에는 아래와 같은 것들이 있습니다. 후광 효과 : 어떤 대상이 가지고 있는 대표적인 특성이 그 대상을 평가하는데 과도하게 영향을 미치는 효과
인과의 오류 : 두 현상 사이의 상관관계를 인과 관계로 오인하는 현상. 이 둘이 헷갈리는 이유는 인과 관계 속에 상관관계가 존재하기 때문
기준점 편향 : 현상에 대해 접하는 첫번째 정보(기준점)에 치우친 판단을 하게 되는 경향. 다른 요소들을 과대 혹은 과소 평가하게 되는 편향
확증 편향 : 자신의 가설에 부합하는 정보만을 수용하고 그렇지 않은 정보는 무시하여 자신의 가설에 대한 믿음이 점점 커지는 편향
매몰 비용의 오류 : 어떤 일을 하는 데 이미 투자한 비용에 집착하여 효용이 없는 일을 멈추지 못하는 오류
가용성 편향 : 자신의 과거 경험을 기준으로 현재 상황을 이해하려는 편향. 상황을 객관적으로 이해하는데 방해가 되는 요소
가설 설정 | Form Hypothesis
문제(Problem)를 정의 했다면 문제를 해결하기 위한 가설(Hypothesis)를 설정해야 합니다. 문제를 어떻게 하면 해결할 수 있을지를 구상하는 과정입니다.
•
(변경)을 하면 (예상 행동)을 할 것이고 그리하면 (측정 가능한 기대 효과)를 할 것이다” 의 형태로 작성하는 것이 좋습니다.•
고객 행동 데이터 분석 등 리서치를 통하여 가설을 도출할 수 있는 정보를 수집하여 그를 바탕으로 가설을 도출합니다.
•
ex. facebook 예시
◦
고객 인터뷰와 데이터 분석을 통해 댓글이 달린 사람과 친구를 추가한 사람들이 더 많이 방문 하는 것을 알게 됨
◦
가설 1. (친구 추가를 유도)하면, (친구와 소통하기) 위해 (더욱 자주 방문) 할 것이다.
◦
가설 2. (글을 작성하도록 유도)하면, (댓글을 확인하기) 위해 (더욱 자주 방문) 할 것이다.
◦
위 가설을 통해 지금의 Facebook이 탄생하였다는 유우명한 이야기
•
가설을 설정할 때는 문제 별견 과정에서의 데이터를 활용할 수 있습니다.
•
비슷한 문제를 고민하는 다른 서비스의 사례를 벤치마킹하여 설정하는 것도 좋은 방법입니다.
•
가설들은 여러 가지를 설정해도 됩니다. 우선 순위를 나눠서 진행하면 됩니다.
가설 검증 | Validate Hypothesis
문제를 통해 가설들을 설정했다면 이제는 무엇을 먼저 실행할 것인지 결정하고 검증할 수 있는 방법을 생각해야 합니다. 최종 가설이 결정되면 이를 실행하는 데에 전사적인 리소스가 투입되기 때문에 합리적인 근거를 통해 최종 가설을 설정하여 실행하는 것은 매우 중요합니다. 최종 가설 설정은 사업 중요도, 영향력, 투입 자원, 일정 등 다양한 요인들을 고려해야 하기 때문에 이를 고려하여 판단 기준을 정립하고 최종 방안을 선택하는 것이 좋습니다.
•
우선 순위 정립
우선 순위 정립은 Product에 대한 수 많은 가설 또는 backlog 중 우선순위를 두고 실행해야할 것은 무엇인지 결정하는 과정입니다. 다양한 우선 순위 설정 방법이 있습니다.
BRICE scoring
Cost of Delay (CoD)
CoD와 BRICE중 어떤 방법론을 사용하는 것이 효과적일까?•
테스트 방법 설계
가설 수립을 완료했다면 그 가설을 증명하기 위한 테스트를 설계해야 합니다. 이 과정을 A/B Test라고 하는데요. 단어 그대로 A안과 B안을 각각 설계하여 테스트 해 보고 그 효과를 분석하여 최종적으로 실행할 방안을 선택합니다.
A/B Test
이제 여태까지 수행한 작업을 바탕으로 유관 부서에 협조를 구해야 합니다. 실제 개발이 필요한 내용이 있을 수 있으므로 project 그룹 내에 개발인력이 없다면 개발팀에 내용을 공유해야 합니다. 이 때, 효율적인 방법이 1-pager입니다. 1-pager를 통해 고민한 내용의 핵심만 간추려서 what, why, how에 대해서 설명을 하고 필요하다면 팀내 검증을 거쳐 개발에 들어가면 좋습니다.
1-Pager
이제 1 pager를 작성할 준비가 되어있습니다. 1 Pager는 Product 개선을 위한 프로젝트 스펙 문서를 의미합니다. Product에 관련된 모든 사람들은 1 Pager 문서를 보고 Product에 대해 이해하고 목적에 공감할 수 있어야 합니다.
구분 | 주요 내용 |
Observation | Problem을 보여주는 Data 변화, User Test 결과, VOC, 인터뷰 등 |
Problem Statement | Observation 기반으로 문제 정의 |
Benchmark | 다른 곳에서는 동일한 문제를 어떻게 해결했는지 분석 (Good/Bad/Interesting/Take away 등의 항목으로 정리) |
Hypothesis | ‘A라는 변화를 주면 B와 같이 변경될 것이다’ 의 형식으로 가설 설정 |
A/B Test | 가설을 기반으로 A(기존)/B(변경) 테스트 계획 설계 |
Metrics | Input : A/B Test 진행 시 즉각적으로 변화하는 요소 (ex. 사용빈도)
Output : 최종적으로 변화해야 하는 요소 (ex. 취소율, 매출)
Monitoring Metrics : Input도, Output도 아니지만 주의 깊게 지켜봐야 하는 지표 |
Trade-offs & Tension | 변화의 댓가 : 결정에 따라 잃는 것들
A/B Test 방안 및 수준에 따라 어떤 Trade-off가 발생하는지, 또 이를 어떤 수준까지 수용할 수 있을 것인지에 대한 판단하기 위한 테스트 필요 |
Andon | A/B Test이후에 문제가 있다는 걸 어떻게 인지할 것인지에 대한 판단하는 기준 |
1-pager 설명
다양한 1-pager 양식
참고자료
Futureplay Night sprint 1기 PO 강좌
카카오워크 캘린더팀
