id, title, category, status, verification_status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, created_at, updated_at, review_reason, merge_history, tags, raw_sources, applied_in, github_commit
| id |
title |
category |
status |
verification_status |
canonical_id |
aliases |
duplicate_of |
source_trust_level |
confidence_score |
created_at |
updated_at |
review_reason |
merge_history |
tags |
raw_sources |
applied_in |
github_commit |
| jobs-to-be-done-(jtbd) |
Jobs to Be Done (JTBD) |
10_Wiki/Topics |
draft |
conceptual |
|
|
|
B |
0.90 |
2026-06-12 |
2026-06-12 |
|
|
| research |
| Assumption Validation Loop |
| Product Discovery |
|
|
|
|
🎯 한 줄 통찰 (One-line insight)
사용자가 제품을 '고용'하여 달성하고자 하는 근본적인 의도와 동기에 집중함으로써, 표면적인 기능 요청을 넘어 실제 해결해야 할 과제를 정의하는 프레임워크다. [1, 2]
🧠 핵심 개념 (Core concepts)
- 과업 문장 (Job Statement): "어떤 [상황]에서, 나는 [동기]를 원하며, 이를 통해 [기대하는 결과]를 얻고 싶다"는 형식으로 사용자 니즈를 명확히 구조화한다. [1]
- 다차원적 과업 (Multidimensional Jobs): 단순한 기능적 수행을 넘어 사용자의 정서적 상태와 사회적 관계를 포함하여 니즈를 분석한다. [3, 4]
- 의도 중심 설계 (Intent-centric Design): 사용자가 무엇을 원하는지(What)가 아니라, 왜 그것을 하려는지(Why)에 집중하여 제품-시장 적합성(PMF)을 높인다. [1-3]
- 검증의 기초 (Foundation for Validation): 가설 검증 루프에서 고객 그룹을 정의하거나 문제 가설을 세울 때 핵심적인 기준점이 된다. [5, 6]
- 가치 제안 매핑 (Value Proposition Mapping): 사용자의 3대 주요 과업(JTBD)에 제품의 통증 완화제(Pain Relievers)를 직접 연결하여 가설의 검증 갭을 식별한다. [7]
- 인구통계학적 정의의 대체: 린 실험 설계 시 단순히 연령이나 지역이 아닌, 해결해야 할 '치명적인 과업(Critical JTBD)'을 가진 집단으로 실험 대상을 구체화한다. [6]
- 비편향 인터뷰 (Unbiased Interviewing): 미래의 행동을 묻는 대신 과거에 해당 과업을 해결하기 위해 어떤 노력을 했는지(JTBD 인터뷰)에 집중하여 'Mom Test'를 준수한다. [5, 8]
📖 세부 내용 (Details)
- 프레임워크의 목적: JTBD는 제품 관리자가 표면적인 기능 요청에서 벗어나 사용자의 근본적인 동기와 원하는 결과에 집중하도록 사고를 전환시킨다. [1, 2]
- 과업의 세부 범주: [3, 4]
- 기능적 과업 (Functional Jobs): 사용자가 완료해야 하는 실질적이고 실용적인 작업. (예: 데이터 분석 결과 도출)
- 정서적 과업 (Emotional Jobs): 작업을 수행하는 동안 사용자가 느끼고 싶은 감정적 상태. (예: 데이터의 정확성에 대해 안심하고 싶음)
- 사회적 과업 (Social Jobs): 사용자가 타인에게 어떻게 인식되고 싶은지에 대한 욕구. (예: 팀 내에서 유능한 분석가로 보이고 싶음)
- 검증 프로세스와의 결합: [4, 9]
- 제품 팀은 가정 매핑(Assumption Mapping)을 통해 식별된 고위험 가설을 JTBD 인터뷰와 결합하여 검증한다.
- 보통 1~2주 차에 JTBD 인터뷰를 수행하여 문제 공간을 확정한 후, 이를 바탕으로 MVP를 설계한다.
- 실제 사례 분석: '보고서 기능'을 개선해달라는 요청을 JTBD로 분석하면, 기능적으로는 '이해관계자 회의를 위한 통찰 생성'이며, 정서적으로는 '발표 시의 자신감', 사회적으로는 '팀에 준비된 모습을 보여주는 것'이 핵심 과업일 수 있다. [4]
⚖️ 모순 및 업데이트 (Contradictions & updates)
- 기능 vs 과업: 소스에 따르면 70%의 기능이 실패하는 이유는 사용자가 요청한 '기능' 자체에 매몰되어 '과업'을 간과했기 때문이며, 성공적인 팀은 기능을 빌딩하기 전에 과업을 먼저 검증해야 한다고 강조한다. [1, 10]
🛠️ 적용 사례 (Applied in summary)
- DeepL: 팀원 간의 정렬과 로드맵 수립을 위해 JTBD 프레임워크를 실제로 적용하여 내부 의사결정 체계를 구축함. [4]
- VPC (Value Proposition Canvas): 비즈니스 모델 검증 과정에서 고객의 과업, 고통(Pains), 이득(Gains)을 정의할 때 핵심 요소로 사용됨. [7]
✅ 검증 상태 및 신뢰도
- 상태: draft
- 검증 단계: conceptual (실제 기업 사례에서 도구로서의 효용성 확인됨)
- 출처 신뢰도: B (전문 아티클 및 전략 가이드 기반)
- 중복 검사 결과: 신규 생성
🔗 관련 문서 링크 (Related document links)
상위/유사 개념
[전략 및 프레임워크]
[실행 도구]
심층 후속 질문 (Deeper Research Questions)
- 사용자의 사회적/정서적 과업이 기능적 과업보다 구매 결정에 더 큰 영향을 미치는가?
- JTBD를 기반으로 정의된 고객 세그먼트가 인구통계학적 세그먼트보다 전환율이 높은가?
- 여러 개의 JTBD가 충돌할 때, 우선순위를 정하는 정량적 기준은 무엇인가?
- 기존 시장 점유율이 높은 경쟁자가 있는 경우, 새로운 JTBD를 발굴하는 것이 유일한 돌파구인가?
- B2B 환경에서 개인의 JTBD와 조직의 JTBD는 어떻게 조화되는가?
실무 적용 맥락 (Practical Application Contexts)
- Implementation: 기능 명세서를 쓰기 전 'Job Story'를 먼저 작성하여 개발팀에 맥락 공유. [1, 4]
- System Design: 사용자가 목표 결과를 달성하는 경로(Time-to-Value)를 최단화하도록 설계. [12]
- Operation / Maintenance: 고객 불만 제기 시, 그것이 어떤 과업(Job)의 실패인지를 분석하여 근본 원인 해결. [13]
- Learning Path: 인구통계 분석 → 고객 여정 맵 → JTBD 인터뷰 → 가치 제안 매핑 순으로 학습 확장. [14, 15]
인접 주변 주제 (Adjacent Topics)
- Kano Model
- 확장 방향: 특정 JTBD를 해결하는 기능이 '기본 기대'인지 '만족 촉발자'인지 구분하는 데 사용. [16, 17]
📝 변경 이력 (Change history)
- 2026-06-12: Initial draft generated via Datacollector_MAC P-Reinforce engine based on provided 25 sources. [Synthesis]
Antigravity Agent