프로젝트 시작을 위한 두 번째 기획, 문제 정의

 
 
 

 

 

프로덕트 기획은 정의한 문제에 대한 해결책을 제시하고, 제품을 통해 답안을 제시하는 과정입니다. 첫 단추가 중요하듯이, 문제를 잘 정의해야 합니다. 문제 정의를 잘못하면 팀은 시간과 방향 모두 다른 길로 가게 됩니다. 이번 글에서는 문제를 잘 찾고 정의하기 위한 과정에 대해 다룹니다.

 

 


 

 

제품 문제 정의 : (A) 행동을 (B) 이상 하는 (C) 성향의 사용자

 

 

 

 

사용자가 (A)프로젝트 목표를 못하고 있는 상황을 발견하고, 그 상황에 대한 (C)문제 원인을 정의하는 과정입니다. 문제가 회사 문제인데 사용자 문제로 잘못 정의되는 경우를 막기 위해, (B)과정을 진행합니다.

 

 

Step 01. 결론에서 시작 – 사용자가 ‘이것(Goal)’해야 하는데 못하는 문제는?

 

 

새벽 1시에 택시를 타야하는데 못타고 있어 → 최종 전환(택시 매칭+결제)
 
 
 
 

문제 정의는 결론에서 시작합니다. 사용자가 ‘이것(Goal)‘ 해야 하는데 못하고 있어, 문제가 뭘까? 문장을 완성하면 됩니다. 즉, 우리 서비스에서 사용자가 마지막으로 수행해야 하는 행동을 정의하면서 시작합니다. 또한, 프로젝트 최종 전환 지표를 정의하는 과정입니다.

 

 

Step 02. 문제 주어 찾기 – 첫 번째 정의한 문제는 ‘누구(Who)’ 문제일까?

 

 

‘사용자가’ 새벽 1시에 택시를 못타고 있어(O) / ‘우리 서비스’ 결제 전환률이 5% 떨어졌어(X)
 
 
 
 

찾아야 하는 문제는 우리(Corp)가 아니라 사용자(User) 문제입니다. 첫 번째 과정에서 찾은 문제 주어 자리에 ‘누구(Who)‘를 대입해서 우리가 정의한 문제가 사용자 문제인지, 혹은 우리 팀의 문제인지 구별할 수 있습니다. 만약 정의한 문제 주어가 우리인 경우, 그 문제가 나오게 된 사용자 문제를 다시 찾아야 합니다.

 

 

Step 03. 5 why로 진짜 문제 찾기 – ‘왜(Why)’ 문제가 발생하는 걸까?

 

 

새벽 1시 택시 매칭이 안되는 이유는 → 집에 가는 사람이 많아 → 집에 갈 수 있는 수단이 없어 → …
 
 
 
 

두 번째 과정을 통해 사용자 문제를 찾았다면, 마지막 단계는 우리가 찾은 문제의 진짜 원인을 찾는 과정입니다. 정의한 문제의 원인, 진짜 문제를 찾기 위해 ‘왜(Why)’를 반복합니다. 표면적인 문제를 진짜 문제로 착각하는 상황을 막기 위해 사용자가 경험한 진짜 문제의 원인을 찾을 때까지 지속적으로 반복하는 과정입니다.

 
 
 
 

 

 

문제 정의는 사용자가 불편한 상황을 찾고, 그에 대한 근본 원인을 찾는 과정입니다. 이 과정은 사용자가 서비스에서 달성해야 하는 결론에서 시작합니다. 그리고 우리 문제인지 사용자 문제인지 찾아내고, 정의한 문제의 진짜 근본 원인을 찾는 순서로 진행됩니다.

 

 


 

 

  • Intro. 프로덕트 기획 4단계 (바로가기)
  • 1/4. 프로덕트 기획 1단계, 메모(바로가기)
  • 2/4. 프로덕트 기획 2단계, [1]기획-사용자 정의(바로가기)
  • 2/4. 프로덕트 기획 2단계, [2]기획-문제 정의(현재 글)
 
 

해당 콘텐츠는 이재구님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.