2026 All-Day-Project (128/365)
도넛을 사는 농부의 문제 정의법
1장. 아이디어는 유혹이다 – 문제로 치환하라(이 글)
2장: 현상과 원인을 분리하는 용기
3장: 5 Why로 내려가고, JTBD로 다시 올라오기
4장: 문제를 이야기로 써라 - 문제 정의문의 서사 구조
5장: 문제를 쪼개라 - Zoom in/Zoom out
새 땅을 개간하는 농부가 있습니다. 아직 아무것도 자라지 않은 황무지.
그는 씨앗 주머니를 품에 안고 서 있습니다.
그런데 마을 사람들이 찾아와서 말합니다.
“여기에 콩을 심어주세요.”
“아니, 팥이 더 낫습니다.”
“고추는 어떤가요?”
농부가 여기서 “좋아, 콩을 심겠다”라고 답하는 순간, 그는 이미 해결바카라에 빠져버린 것입니다.
콩이 이 땅에 맞는지, 지금 계절은 어떤지, 물 빠짐은 어떤지 묻지도 않고 말이죠.
프로덕트 매니저도 마찬가지입니다. 우리는 매일 ‘아이디어’와 ‘요청’이라는 유혹 속에 살아갑니다. “구글 로그인 추가해주세요”, “다크 모드 만들어주세요”, “알림 기능 좀 넣어주세요”.
그리고 우리는 종종 이렇게 대답하죠. “좋아요, 검토해볼게요.”
하지만 진짜 농부의 첫 질문은 달라야 합니다.
“이 땅이 정말로 겪고 있는 문제는 무엇인가?”
들어온 요청 하나하나는 사실 ‘누군가가 이미 생각해낸 해결바카라’입니다.
고객은 “구글 로그인을 넣어주세요”라고 말하지만,
그 뒤에는 “나는 회원가입이 너무 번거로워서 포기하고 싶다” 는 문제가 숨어 있습니다.
만약 우리가 “구글 로그인을 넣자”부터 시작하면, 우리는 한 가지 해결바카라만 보고 달려갑니다.
하지만 문제가 진짜 ‘회원가입의 번거로움’이라면, 해결바카라은 구글 로그인 외에도 많습니다.
- 간편한 이메일 로그인
- 전화번호 인증만으로 가입
- 로그인 없이 먼저 체험하기
- 소셜 로그인 여러 개 제공
문제를 모르면, 우리는 가장 먼저 떠오른 해결바카라(그리고 그것을 요청한 사람의 목소리)에 휘둘리게 됩니다.
‘아이디어’를 받았을 때, 잠시 멈추고 다음 세 가지 질문을 스스로에게 던져보세요.
첫째: “이 요청 뒤에 숨은 진짜 문제는 무엇인가?”
“구글 로그인이 필요해요.”
→ “왜 필요하다고 생각하시나요?”
→ “사용자들이 회원가입을 중간에 포기해서요.”
→ “아, 그러면 진짜 문제는 ‘가입 절차의 이탈’이군요.”
둘째: “이 문제를 해결하면 누가, 얼마나 행복해지는가?”
구글 로그인을 넣으면 정말 이탈률이 줄어들까? 아니면, 가입 절차 자체를 없애면 더 좋을까?
문제의 ‘주인공’이 누구인지, 그 사람에게 이 문제가 얼마나 고통스러운지 생각해보는 겁니다.
고통이 작으면, 굳이 지금 해결하지 않아도 됩니다.
셋째: “이 문제를 해결하지 않으면 어떤 일이 벌어지는가?”
이 질문은 ‘기회 비용’을 깨우게 해줍니다.
구글 로그인을 넣지 않으면, 매일 500명의 신규 사용자가 이탈한다면? 그건 큰 문제입니다. 하지만 한 달에 한 번 불편한 관리자 화면의 버튼 위치라면? 지금 당장 할 일이 아닐 수 있습니다.
사례 A) “관리자 페이지에 엑셀 다운로드 기능 추가해주세요”
- 1차 질문: 왜 필요하신가요?
→ “매주 보고서를 만들어야 하는데, 일일이 복사 붙여넣기 하느라 시간이 너무 오래 걸려서요.”
- 문제 정의: “관리자가 보고서 작성에 매주 3시간씩 낭비하고 있다.”
- 다른 해결바카라: 엑셀 다운로드 외에도, 자동 이메일 발송, 대시보드에 바로 차트 표시, API 연동 등
사례 B) “앱에 다크 모드 넣어주세요”
- 1차 질문: 왜 필요하신가요? → “밤에 사용할 때 눈이 너무 아파요.”
- 문제 정의: “야간 사용자의 시각적 피로도가 높아 장시간 사용을 꺼린다.”
- 다른 해결바카라: 다크 모드 외에도, 야간 화면 밝기 자동 조절, 블루라이트 필터, 글자 크기 조정 등
사례 C) “챗봇을 도입합시다”
- 1차 질문: 왜 필요하신가요? → “고객 문의가 너무 많아서 CS 팀이 감당을 못 해요.”
- 문제 정의: “CS 문의량 대비 처리 인력이 부족하여 응답 지연이 발생한다.”
- 다른 해결바카라: 챗봇 외에도, FAQ 개선, 문의 유형별 자동 분류, 셀프 서비스 포털 강화, 예측적 안내 푸시 등.
보이시나요? 같은 ‘해결바카라 요청’도, 문제를 정의하는 순간 전혀 다른 방향이 열립니다.
오해하지 마세요. 아이디어 자체가 나쁘다는 뜻이 아닙니다. 고객이나 동료가 해결바카라을 들고 오는 것은 그들이 그 문제를 진심으로 느끼고 있다는 증거입니다. 그들의 열정과 고민을 무시하지 마세요.
다만, 그 해결바카라에 즉시 점프하지 마세요.
대신, 그 해결바카라을 문제의 단서 로 삼으세요.
“아, 당신은 이런 불편함을 겪고 있었군요. 그 문제에 대해 좀 더 이야기해주시겠어요?”
이 한 마디가, 기능 요청을 기능 명세로 전달하는 PM과, 진짜 문제를 발견하는 PM을 가릅니다.
매일 들어오는 요청(슬랙, 지라, 노션, 이메일, 카톡) 중 하나를 골라보세요.
1. 그 요청을 그대로 적습니다. (예: “구글 로그인 추가”)
2. 그 아래에 ‘진짜 문제는 무엇일까?’ 라고 적고, 3가지 가설을 써봅니다.
3. 그 가설 중 하나를 골라, 오늘 관련자에게 “왜 그렇게 생각하시나요?”라고 물어봅니다.
이 작은 습관이 쌓이면, 당신은 더 이상 ‘요청 전달자’가 아니라 ‘문제 발견자’ 로 바뀌어 있습니다.
농부가 마을 사람들의 “콩을 심으라”는 말에 휘둘리지 않고,
먼저 흙을 만져보고, 물 빠짐을 확인하고, 햇빛을 관찰하는 이유는 무엇일까요?
그는 알고 있기 때문입니다.
잘못된 씨앗을 심으면 한 철을 망치지만, 잘못된 문제를 풀면 제품 전체를 망친다는 것을.
그래서 오늘도 그는 묻습니다.
“당신이 말하는 그 아이디어 뒤에, 정말로 우리가 풀어야 할 문제는 무엇인가요?”
이것이 ‘도넛을 사는 농부’의 첫 번째 성명절기입니다.
다음 장 예고:
2장에서는 ‘현상과 원인을 분리하는 법’을 다룹니다.
왜 “개발자가 게을러서”라고 쓰면 안 되는지,
그리고 ‘사실’과 ‘해석’ 사이에서 PM이 지켜야 할 경계는 무엇인지 이야기해보겠습니다.