89. 기획서보다 먼저, 문제부터 정의하자

기획서는 PM에게 있어 기본 중의 기본이죠. 하지만 정말 실무에선, 기획서보다 먼저 챙겨야 할 게 있습니다.
 
바로 ‘문제 정의’입니다.
 
아무리 기획서가 잘 짜여 있어도, 문제를 잘못 정의했다면 결국 잘못된 방향으로 리소스를 쓰게 돼요. 시간도, 비용도, 협업자의 노력도 엉뚱한 곳에 쓰이죠.

 
 

기획서보다 중요한 ‘문제 정의’

많은 PM들이 실무에서 기능을 먼저 설계하려고 합니다. “뭘 만들까?”에 초점을 맞추죠.
하지만 ‘왜 만들까?’, 이게 불분명하면 팀 전체가 흔들립니다.
 
기획서의 시작점은 기능이 아니라 문제여야 합니다. 문제가 명확해야, 그걸 해결하기 위한 설계가 명확해지고,
개발자와 디자이너, 운영자 모두 같은 방향을 바라볼 수 있어요.
 

문제 정의가 잘못되면 생기는 일

• 각자 다른 문제를 가정하고 설계함
• 우선순위가 엉켜, 중요하지 않은 기능에 집중함
• 릴리즈 후에도 전혀 개선 효과를 못 봄
• 심지어 유저에게 혼란을 주기도 함

이게 정말 실무에서 자주 겪는 일입니다.
 

문제 정의를 잘하기 위한 방법

1.  5 Whys 기법

 
“왜 그 문제가 생겼는지”를 다섯 번 묻는 방식입니다. 겉으로 드러난 증상 말고, 본질을 추적할 수 있어요.
 
예시:

“회원가입 이탈률이 높아요”
→ 왜?
→ 비밀번호 설정에서 이탈
→ 왜?
→ 조건이 너무 까다롭고, 에러 메시지가 불친절함

 
결국 문제는 UI가 아니라 조건 자체와 피드백 설계였다는 걸 알게 되죠.
 

2.  Pain Point 맵핑

사용자의 행동 흐름을 따라가면서 어디서 불편을 느끼는지, 어디서 이탈하는지를 정리합니다.
마우스 클릭 수, 이동 경로, 에러 빈도 등을 체크해보세요.
 

실전에서의 문제 정의 사례

“우리 회원가입률이 낮아요. 가입 절차를 줄일까요?”

 
이건 너무 흔한 대답이에요. 하지만 데이터를 보면 ‘가입 절차’가 문제가 아닐 수 있어요.
예: 약관 동의 단계에서 스크롤이 너무 길고, 체크박스가 눈에 안 띔
그럼 절차가 아니라 UX 이슈가 핵심이 되는 거죠.
 

정리하며

문제 정의는 감이 아니라 구조적으로 접근해야 하는 PM의 핵심 역량입니다.
 
기획서 쓰기 전에,
 “내가 지금 정확한 문제를 정의하고 있나?”
“팀원과 이 문제에 대해 같은 그림을 그리고 있나?”
이 두 가지를 꼭 체크하세요. 이게 안 되면 아무리 잘 만든 기획서도, 팀을 반대로 이끄는 문서가 될 수 있어요.