문제를 먼저 정의하는 기획자
처음 기획 업무를 맡으면 대부분 '기능을 어떻게 구성해야 하지?', '화면은 어떻게 설계하지?' 같은 생각부터 시작합니다.
실제로 많은 주니어 PM·기획자가 기능 목록부터 정리하려고 합니다. 그런데 이 방식은 기획이 흔들리는 가장 흔한 출발입니다.
이유는 간단합니다. 문제가 명확하지 않으면 어떤 기능도 설득력을 가지기 어렵기 때문입니다.
대부분의 기능 요청은 사실 '문제 해결 방안'이지 '문제 자체'가 아닙니다.
예를 들어, 사용자나 내부 팀이 “찜하기 기능이 있었으면 좋겠다”, “Q&A 실시간 기능이 필요하다”라고 말하는 경우가 있습니다.
언뜻 보면 기능 제안 같지만, 사실 그 말 뒤에는 더 깊은 원인이 숨어 있습니다.
- “다시 찾기 어렵다”
- “지금 바로 구매 결정이 어렵다”
- “질문을 나중에 하기 번거롭다”
- “다른 사람의 질문 흐름을 알고 싶다”
즉, 사용자들은 문제를 ‘그대로’ 말하지 않습니다. 자기 생각대로 정리된 '해결책 형태'로 전달합니다.
좋은 기획자는 이 지점에서 움직임이 다릅니다.
요구사항을 그대로 기능으로 옮기지 않고, '왜 이 기능이 필요하다고 느낄까?'를 먼저 탐색합니다.
이 차이가 기획의 퀄리티를 완전히 갈라놓습니다.
문제 중심 접근을 하면 얻는 장점은 명확합니다.
- 기능 범위가 불필요하게 커지지 않습니다.
- 팀 전체가 “왜 이 작업을 하는가”에 명확히 합의할 수 있습니다.
- 우선순위 판단이 쉬워집니다.
- 기능이 아니라 “가치”를 만드는 방향으로 기획이 흐릅니다.
기획의 본질은 기능이 아니라
'어떤 문제를 해결하고, 그 문제를 왜 지금 풀어야 하는가'
이 두 가지를 정확히 설명하는 데 있습니다.
문제 정의는 ‘문제의 구조를 드러내는 과정’
많은 PM이 기획이 어려운 이유를 '아이디어가 부족해서'라고 생각합니다.
하지만 실제 현장에서 기획이 막히는 근본 이유는 아이디어 부족이 아니라 문제가 구조화되지 않았기 때문입니다.
문제 정의가 흐릿하면 어떤 해결책도 설득력을 갖기 어렵습니다.
문제를 정의한다는 것은 단순히 '무엇이 불편하다'를 적는 일이 아닙니다.
문제 정의는 다음 세 가지 요소가 모두 들어가야 합니다.
누가
문제는 특정 사용자 군에게만 나타날 수 있습니다. 따라서 '전체 사용자'가 아니라
- 초보 사용자?
- 고빈도 사용자?
- 특정 기능을 자주 사용하는 그룹?
- 고객 문의를 자주 남기는 사람들?
이렇게 ‘문제가 발생하는 대상’을 정확히 좁혀야 합니다.
어떤 상황에서
문제는 맥락에 따라 형태가 달라집니다.
예시로 :
- 상품을 탐색하는 도중
- 결제를 시도하는 단계에서
- 첫 가입 과정에서
- 특정 오류 메시지를 본 이후에
- 이런 상황이 정해져야만 해결책이 연결됩니다.
어떤 문제를 겪고 있는가
여기서는 기술적 현상이 아니라 사용자 경험 관점의 문제를 정의해야 합니다.
예를 들어,
'정보 입력 과정이 길다'는 현상이고 '입력 과정 때문에 구매를 포기한다'가 문제입니다.
문제 정의란 결국 이 세 요소를 한 문장으로 압축하는 것입니다.
이 문장이 명확하면 기획의 60%는 이미 해결된 셈입니다.
문제 정의가 명확하지 않으면 기능은 계속 늘어나고,
팀은 '왜 이걸 만들지?'를 반복해서 묻게 됩니다.
반대로 문제 정의가 명확하면 기획 과정은 짧아지고 의사결정은 훨씬 빠르고 합리적으로 이뤄집니다.
기획의 힘은 화려한 문서가 아니라 '문제를 얼마나 정확하게 구조화했는가'에서 나옵니다.
좋은 기획
많은 기획 문서가 실패하는 이유는 '무엇을 만들 것인가'를 너무 빨리 설명하기 때문입니다.
좋은 기획은 기능을 설명하는 문서가 아니라 기능이 등장해야 하는 논리적 이유를 설명하는 문서여야 합니다.
좋은 기획서의 구성은 이렇게 흘러야 합니다.
문제 정의
누가 → 어떤 상황에서 → 어떤 문제를 겪고 있는가.
문제는 사용자 관점에서 서술해야 하고, 데이터·정성 자료·내부 관찰 등이 함께 뒷받침되어야 합니다.
문제 해결의 목표
단순히 해결이 아니라 “어떤 개선이 발생해야 성공인지”가 명확해야 합니다.
- 재방문율
- 이탈률
- 전환률
- CS 감소
- 작업 효율 증가
- 이런 지표가 명확해야 기능 설계와 우선순위가 논리적으로 정리됩니다.
문제와 해결책을 잇는 가설
여기서 중요한 건 '우리의 해결책이 왜 효과가 있는가'입니다.
즉, 해결책은 문제의 본질을 겨냥해야 합니다.
예를 들어,
- 사용자가 상품을 다시 찾기 어려워한다 → 찜하기 기능
- 사용자가 질문을 제출할 타이밍을 놓친다 → 사전 질문 시스템
- 매번 개인정보를 입력하기 번거롭다 → 결제 수단 저장 기능
이처럼 '문제 → 이유 → 해결책'이 직선으로 이어지는 구조가 필요합니다.
이 구조가 갖춰져 있으면 기능이 아니라 '이 기능이 꼭 필요한 이유'를 설명할 수 있고
팀 전체를 설득하는 데 훨씬 강력한 힘을 가집니다.
기획의 품질을 결정하는 것은 기능이 아니라 이유입니다.
정리
- 기능보다 문제를 먼저 정의해야 기획이 흔들리지 않습니다.
- 문제 정의는 '누가–어떤 상황–어떤 문제'라는 구조적 문장으로 정리되어야 합니다.
- 기획의 핵심은 '무엇을 만들지'가 아니라 '왜 이 기능을 만들어야 하는가'입니다.
- 문제 중심 기획을 하면 우선순위·설득·효율·결과의 품질이 모두 올라갑니다.