문제 정의 워크숍(Problem Statement Workshop)

제품에서 가장 비싼 실수는 틀린 문제를 푸는 것이다

2010년 Google은 Wave를 출시했습니다. 기술적으로는 대단한 제품이었습니다. 실시간 협업, 스레드형 대화, 임베디드 미디어까지 갖췄습니다. 엔지니어링만 보면 Google 최고의 작업 중 하나였습니다. 그런데 1년도 못 가 종료됐습니다. 실행이 나빴기 때문이 아니라, 아무도 그것이 무슨 문제를 푸는지 설명하지 못했기 때문입니다.

이 이야기는 계속 반복됩니다. 팀은 솔루션을 먼저 사랑하고, 그 뒤에 문제를 억지로 끼워 맞춥니다. 솔루션을 건드리기 전에 *문제*를 제대로 맞추는 문제 정의 역량은 제품 관리에서 가장 과소평가된 기술 중 하나입니다.

왜 팀은 문제 정의를 건너뛰는가

비생산적으로 느껴지기 때문입니다. 회의실 안에 모두가 아이디어를 가지고 있고, 누군가가 "잠깐 멈추고 문제부터 정의하죠"라고 말하면 눈이 굴러갑니다. "문제는 알잖아요. 사용자가 churn하고 있잖아요." 그런데 정말 그런가요? 그들이 churn하는 이유는 onboarding이 혼란스러워서일까요, 핵심 가치에 도달하기까지 너무 오래 걸려서일까요, 경쟁사가 free tier를 내서일까요, 아니면 당신의 billing email이 스팸처럼 보여서일까요?

Harvard Business Review 연구에 따르면 조사 대상 경영진의 85%는 자신의 조직이 문제 진단을 잘 못한다고 답했고, 87%는 그 결함이 상당한 비용을 만든다고 답했습니다. 또 문제 정의에 20% 더 많은 시간을 쓴 팀은 실제 해결책에 도달하는 속도가 35% 더 빨랐습니다. 처음부터 잘못된 것을 만들어 다시 돌아가는 rework loop를 피했기 때문입니다.

"How Might We" 프레임워크와 5 Whys 기법이 존재하는 이유도 여기에 있습니다. "사용자가 churn하고 있다"는 말은 "paid ads로 유입된 사용자가 organic 사용자보다 첫 14일 안에 3배 더 빨리 churn한다"로 바뀌어야 합니다. 전자는 막연한 불안이고, 후자는 실제로 풀 수 있는 문제입니다.

이 프롬프트가 돕는 방식

이 프롬프트는 problem statement 워크숍을 진행합니다. 초기 문제 영역에서 출발해 5 Whys로 root cause를 파고들고, 이를 "How Might We" 질문으로 재구성하며, 현재 설명하고 있는 것이 symptom인지 cause인지 계속 스트레스 테스트합니다. 끝나면 솔루션을 평가할 수 있을 만큼 충분히 구체적인 problem statement가 남습니다.

구조화된 결과물에는 누가 영향을 받는지, 얼마나 심각한지, 문제의 존재를 뒷받침하는 증거가 무엇인지도 함께 담깁니다. 이것이 중요한 이유는 "phantom problem"을 막기 위해서입니다. 팀이 문제라고 *가정*하지만 실제로는 검증해본 적 없는 것 말입니다.

언제 꺼내 쓸까

• 새 initiative를 시작하는데 팀이 이미 solution brainstorming부터 하고 있을 때
• discovery interview에서 여러 문제가 나왔고, 그중 무엇에 집중할지 더 날카롭게 좁혀야 할 때
• 팀이 무언가를 만들었지만 metric이 움직이지 않았고, 아예 틀린 문제를 푼 것 같을 때
• 이해관계자가 "X를 만드세요"라는 solution을 던졌고, 대안을 평가하기 위해 그 아래 문제를 다시 풀어내야 할 때
• design sprint를 돌리며 Day 1을 붙잡아줄 잘 정의된 문제축이 필요할 때

좋은 결과물의 모습

좋은 problem statement는 구체적인 사용자 세그먼트, 문제가 되는 구체적 행동 또는 결과, 측정 가능한 영향, 그리고 그 근거가 되는 증거 출처를 함께 말합니다. "Users"는 "Team 플랜의 첫 사용 B2B 사용자"로 바뀌고, "나쁜 경험"은 "7일 안에 두 번째 팀원을 초대하지 못해 Day-30 churn이 62%에 이른다"로 바뀌어야 합니다. 그래야 팀이 하나로 모일 수 있는 문제 정의가 됩니다.

참고 자료

• Are You Solving the Right Problems? — Harvard Business Review
• Continuous Discovery Habits — Teresa Torres