5 Why로 내려가고,
JTBD로 올라오기

2026 All-Day-Project (130/365)

byJamin

도넛을 사는 농부의 문제 정의법

서론: 농부가 씨앗을 고르는 법

1장. 아이디어는 유혹이다 – 문제로 치환하라

2장: 현상과 원인을 분리하는 용기

3장: 5 Why로 내려가고, JTBD로 다시 올라오기 (이 글)

4장: 문제를 이야기로 써라 - 문제 정의문의 서사 구조

5장: 문제를 쪼개라 - Zoom in/Zoom out



프롤로그: 뿌리와 캐노피 사이


농부가 밭에 서 있습니다. 한 그루의 나무가 이상합니다. 잎은 시들고, 열매는 잘 열리지 않습니다.


어떤 농부는 땅을 파내려갑니다. 아래로.

“뿌리에 문제가 있나? 영양분은 충분한가? 해충은 없는가?”


어떤 농부는 하늘을 올려다봅니다. 위로.

“이 나무가 원래 자라야 할 숲의 모습은 어떤가? 충분한 햇빛을 받고 있는가? 주변 나무들과의 관계는?”


둘 다 중요합니다.

뿌리만 보면 나무의 전체적인 조화를 놓치고, 숲만 보면 구체적인 문제를 해결할 수 없습니다.


PM도 마찬가지입니다.


우리는 문제를 파고들어 근본 원인 을 찾아야 하고(아래로),

동시에 사용자가 진짜 원하는 진행 중인 작업(Job) 을 이해하기 위해 위로 올라가야 합니다.


이 장에서는 이 두 가지 움직임을 어떻게 조화시킬지 이야기하겠습니다.




1장 복습: 우리는 지금 어디쯤 와 있는가?


지금까지 우리는:

- 1장 에서 들어온 아이디어를 ‘문제’로 치환하는 법을 배웠습니다. (구글 로그인 → 가입 이탈 문제)

- 2장 에서 현상과 원인을 분리하고, 성급한 결론을 피하는 법을 배웠습니다. (잎이 노랗다 ≠ 영양 부족)


이제 우리는 문제라고 생각되는 것을 손에 쥐었습니다.

그런데 이 문제가 ‘진짜 근본 문제’일까요? 아니면 더 깊은 곳에 다른 문제가 숨어 있을까요?





2. 아래로: 5 Why로 근본 원인을 향해 내려가기


5 Why는 도요타 생산방식에서 유래한 기법입니다.

문제의 표면적 원인에서 시작해, ‘왜?’를 다섯 번 반복하면서 근본 원인에 도달하는 방식이죠.


우리의 구글 로그인 예시를 다시 가져와 봅시다.


표면적 문제: “신규 사용자 가입 전환율이 낮다.”


1. 왜? → 회원가입 과정에서 사용자들이 이탈한다.

2. 왜? → 회원가입 폼이 너무 길고 복잡하다.

3. 왜? → 보안과 법적 규제를 만족시키기 위해 많은 정보를 요구해야 한다.

4. 왜? → 우리 서비스의 특성상 개인정보 보호법과 결제 관련 규정을 따라야 한다.

5. 왜? → (여기서 멈춥니다. 규제는 우리가 바꿀 수 없는 외부 조건이니까요.)


이렇게 내려오면, 우리가 풀 수 있는 문제의 범위가 명확해집니다.

“규제를 없애자”는 불가능하지만, “규제를 만족시키면서도 사용자 경험을 덜 해치는 방법”은 가능합니다.


5 Why의 함정


하지만 주의할 점이 있습니다.


함정 1: 너무 깊이 가면 철학이 된다

“왜? → 왜? → 왜?”를 계속하다 보면 “왜 우리는 존재하는가?” 같은 질문에 도달할 수 있습니다. 실무에서는 3~5번이면 충분합니다. ‘액션 가능한 원인’이 나오는 선에서 멈춥니다.


함정 2: 원인을 ‘사람 탓’으로 돌리면 막힌다

“왜? → 개발자가 실수를 해서”라는 답변은 더 이상 파고들기 어렵습니다.

사람 탓으로 돌리는 순간, ‘시스템’이나 ‘프로세스’를 개선할 기회를 놓칩니다.

대신 “왜 개발자가 실수할 수밖에 없는 환경이었을까?”로 질문을 돌려보세요.


함정 3: 원인과 해결바카라을 함께 생각하지 않는다

5 Why를 하면서도 머릿속에서는 “그럼 이렇게 고치면 되겠네”라는 해결바카라이 따라붙기 마련입니다.

괜찮습니다. 하지만 일단 해결바카라은 접어두고, 원인을 찾는 데 집중하는 연습이 필요합니다.




3. 위로: JTBD로 사용자가 진짜 원하는 것 올라가기


5 Why로 땅속 깊이 내려갔다면, 이제 다시 위로 올라갈 시간입니다. Jobs to be Done(JTBD) 은 사용자가 제품을 ‘고용’해서 달성하려는 근본적인 과업을 이해하는 프레임워크입니다.


클레이튼 크리스텐슨의 유명한 예시가 있죠.

사람들은 ‘지름 5mm 드릴’을 사는 것이 아니라, ‘지름 5mm 구멍’ 을 사는 것입니다.

더 나아가, 그 구멍을 뚫어서 ‘바카라장을 벽에 고정한다’ 는 과업을 완수하려는 것입니다.


우리의 구글 로그인 예시로 다시 올라가 봅시다.


표면적 요청 : “구글 로그인을 넣어주세요.”

문제 정의: “회원가입 절차가 복잡해서 사용자들이 이탈한다.”

JTBD 질문 : 사용자가 진짜로 ‘고용’하려는 것은 무엇인가?


- 빠른 로그인? (그것도 하나의 수단입니다)

- 그보다는: “최소한의 노력으로 서비스의 핵심 가치를 경험하고 싶다”

- 더 근본적으로: “이 서비스가 나에게 정말 필요한지, 투자할 가치가 있는지 빠르게 확인하고 싶다”


이 시점에서 문제 정의가 완전히 달라집니다.


- 5 Why만 했을 때의 문제 정의

“복잡한 회원가입 폼이 사용자 이탈을 유발한다.

해결바카라: 폼을 줄이거나 소셜 로그인을 넣는다.”


- JTBD를 함께 했을 때의 문제 정의:

“사용자는 서비스 가치를 확인하기 전에 가입이라는 장벽에 부딪힌다.

해결바카라: 가입 없이 체험할 수 있는 기능, 혹은 1분 안에 가치를 전달하는 온보딩.”


해결바카라의 범위가 훨씬 넓어졌습니다.




4. 나선형: 아래와 위를 오가며 문제를 정의하라


중요한 것은, 5 Why와 JTBD를 순차적으로 하는 것이 아니라 나선형으로 오가는 것입니다.


나선형 질문의 예시


1. (아래로) “왜 사용자가 이탈할까?”

→ 가입 폼이 복잡해서

2. (위로) “사용자가 가입 폼을 채우는 진짜 목적은?”

→ 서비스 가치를 경험하기 위해

3. (아래로) “그렇다면, ‘가치 경험’을 방해하는 진짜 장벽은 무엇일까?”

→ 가입 전에 아무것도 못 하게 막는 구조

4. (위로) “만약 가입 없이도 가치의 일부를 경험할 수 있다면, 사용자는 어떻게 행동할까?”

→ 신뢰도가 올라가고, 가입 의향이 높아질 것

5. (아래로) “그런 경험을 제공하기 위해 지금 우리 시스템에서 바꿔야 할 것은?”

→ 게스트 모드, 샌드박스, 또는 1클릭 체험 계정


이렇게 오가다 보면, 처음에는 보이지 않던 해결의 실마리가 드러납니다.


사례: ‘느린 고객 응대’ 문제


상황: 고객 CS 응대 시간이 평균 24시간. 팀에서는 “챗봇을 도입하자”는 의견이 나옴.


5 Why (아래로)

1. 왜 느린가? → 문의량이 많아서

2. 왜 문의량이 많은가? → 제품 사용법이 명확하지 않아서

3. 왜 사용법이 명확하지 않은가? → 온보딩 가이드가 부실해서

4. 왜 부실한가? → 개발 일정에 밀려서 온보딩을 소홀히 함

5. 왜 밀렸나? → 온보딩을 ‘부가 기능’으로 분류했기 때문


JTBD (위로)

사용자가 CS에 문의하는 진짜 이유는?

→ “스스로 해결할 수 없어서”

사용자가 진짜 원하는 것은?

→ “내가 원하는 기능을 즉시, 스스로 찾아서 해결하는 것”


나선형 재정의

문제:

사용자가 스스로 해결할 수 없어서 CS 문의가 폭증한다.

근본 원인은 온보딩 가이드가 부실하고, 제품의 자가 해결 가능성이 낮다는 데 있다.


해결바카라 후보:

챗봇(1차 대응) + 온보딩 개선(근본) + 인앱 힌트(예방) + 지식 베이스 강화(자가 해결)


챗봇 하나만 고려할 때와 비교할 수 없을 정도로 풍부해졌습니다.




5. 오늘부터 할 수 있는 작은 실천


실천 1: 하나의 문제를 골라 5 Why 3단계 + JTBD 1단계 써보기


종이 한 장을 반으로 접습니다.

- 왼쪽에 5 Why로 아래로 내려갑니다. (최소 3단계, 최대 5단계)

- 오른쪽에 JTBD로 위로 올라갑니다. “사용자가 진짜 이루려는 것은 무엇인가?”


실천 2: ‘그래서 어쩌라고?’ 질문 금지


팀 회의에서 누군가가 5 Why를 이야기할 때, “그래서 우리가 뭘 어쩌라고?”라는 질문은 잠시 보류하세요.

원인을 다 찾고, JTBD를 올려본 다음에 해결바카라을 논의하겠다는 룰을 만듭니다.


실천 3: 오늘의 문제를 ‘뿌리’와 ‘캐노피’로 그려보기


화이트보드에 나무를 그립니다.

- 뿌리 쪽: 5 Why로 찾은 근본 원인들

- 캐노피(가지와 잎) 쪽: JTBD로 발견한 사용자의 진짜 과업들

이 그림을 팀과 공유하면, 모두가 문제의 깊이와 넓이를 동시에 볼 수 있습니다.





에필로그: 농부가 뿌리와 캐노피를 함께 보는 법


농부는 나무를 치료할 때, 뿌리만 보지도 않고 가지들만 보지도 않습니다.

그는 흙을 파고, 영양분을 확인하고, 해충을 찾습니다.

동시에, 나무가 자라는 전체적인 환경(햇빛, 바람, 주변 나무와의 거리)을 봅니다.


왜냐하면, 뿌리의 문제가 캐노피의 문제를 낳고, 캐노피의 문제가 다시 뿌리에 영향을 주기 때문입니다.


PM도 마찬가지입니다.

5 Why로 근본 원인을 찾아내는 것은 ‘뿌리’를 보는 것이고, JTBD로 사용자의 진짜 과업을 이해하는 것은

‘캐노피’를 보는 것입니다. 둘 중 하나만 보면, 나무를 절반만 보는 셈입니다.


진짜 농부는 말합니다.

“땅을 파내려가면서도, 하늘을 올려다보는 눈을 잃지 마라.”


이것이 ‘도넛을 사는 농부’의 세 번째 성명절기입니다.




다음 장 예고:

4장에서는 ‘문제를 이야기로 써라 – 문제 정의문의 서사 구조’를 다룹니다.

건조한 사실의 나열이 아니라, 누군가의 마음을 움직이는 문제 정의문을 쓰는 법을 이야기해보겠습니다.


카지노 게임의 이전글현상과 원인을 분리하는 용기