Problem hypotheses
이번에는 Problem Hypotheses의 도출 과정을 살펴보겠습니다.
Persona의 4분면 중 좌측의 Fact+Behavior가 Customer Hypotheses를 도출하는데 활용됐다면, 우측(Goal - Pain)이 Problem Hypotheses의 도출 요소인 것을 금방 눈치챘을 것입니다. 일반적으로 Problem Solving에서 문제 정의는 As-is(현재의 상태)와 To-be(되고자 하는 상태) 간의 Gap이라고 이야기합니다. 본 Persona에서도 이 논리가 완벽하게 적용됩니다. 고객의 As-is는 Persona 상의 Pain Point이고, 고객의 To-be는 Persona 상의 Goal일 것입니다. 이 차이를 문장으로 정의하면 They want to [goals] but [Pains] 와 같은 구조가 됩니다. 예시를 통해 한 번 만들어 볼까요?
(1) 내 집에서 법적으로 허용하는 수준만큼 소음에 대한 걱정 없이 지내고 싶지만, 소음의 정도와 소음 발생 시간 및 장소를 정확하게 알 수 없다.
(2) 아래 집과 층간 소음 갈등 없이 살고 싶지만, 아래 집에서 느끼는 소음이 우리 집으로 인한 것인지 다른 곳에서 발생한 것인지 알 수 없다.
이런 식으로 가설적 Problem Hypotheses를 도출할 수 있습니다. 문장만 그대로 읽는 경우 앞의 문구와 뒤의 문구 간에 논리적으로 자연스럽게 이어지는 느낌이 들도록, 토론하면서 언급되었던 내용을 보완할 수도 있습니다.
Problem Hypotheses는 앞서 Persona 작성에서 가이드 했던 One Goal – One Pain의 구조를 따르기 때문에, 단순 Data point 들간의 조합을 모두 따질 필요가 없습니다. 그래서 보통 Customer Hypotheses보다 개수가 적습니다. 그러나 새로운 기회를 탐색하는 입장에서 One Goal - One Pain이 완벽하게 짝지어진 것이라고 볼 수 없는 단계이므로, 의도적으로 다양한 조합을 고민하고 Problem Hypotheses를 도출하는 것을 추천합니다.
다음 장에서는 Customer/Problem Hypotheses가 잘 정의되었는지 검토하기 위한 고객 Pain point 분석에 대해 살펴보도록 하겠습니다.
- Learning and Growth 파트너, Rocky -
<Persona 작성 관련 글>
https://brunch.co.kr/@seigniter/295
<전체 내용 외 유용한 tip까지 보고 싶다면?>
