2nd/10_Wiki/Topics/Topic_Agent/Jobs-to-Be-Done.md

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	Jobs-to-Be-Done	10_Wiki/Topics	draft	conceptual		JTBD		B	0.85	2026-06-12	2026-06-12			research Assumption Validation Loop Product Discovery	NotebookLM Synthesis	DeepL B2B SaaS Invoice Management

Jobs-to-Be-Done

🎯 한 줄 통찰 (One-line insight)

사용자가 표면적으로 요청하는 기능이 아니라, 특정 상황에서 그들이 달성하고자 하는 근본적인 동기와 기대 결과에 집중하여 제품의 시장 적합성을 확보하는 프레임워크 [1, 2].

🧠 핵심 개념 (Core concepts)

• 사용자 의도 중심(Focus on Intent): 사용자가 무엇을 원하는지(What they say)가 아니라, 무엇을 성취하려고 하는지(What they are trying to accomplish)에 초점을 맞춤 [2, 3].
• 잡 스테이트먼트(Job Statement): "특정 [상황]일 때, 나는 [동기]를 원하며, 이를 통해 [기대 결과]를 얻고 싶다"는 형식으로 사용자의 요구를 구조화함 [1].
• 다차원적 요구(Dimensions of Jobs): 사용자에게는 실용적인 **기능적 잡(Functional Jobs)**뿐만 아니라, 정서적 잡(Emotional Jobs)(느끼고 싶은 감정)과 사회적 잡(Social Jobs)(타인에게 보이고 싶은 모습)이 공존함 [2, 4].
• 문제-솔루션 적합성(Problem-Solution Fit): 제품의 가치 제안이 고객의 가장 중요한 3가지 이상의 JTBD와 일치할 때 진정한 적합성이 달성됨 [5].

🧩 추출된 패턴 (Extracted patterns)

• 과거 행동 기반 검증: 미래에 무엇을 할 것인지 묻지 말고, 마지막으로 그 문제를 해결하기 위해 돈이나 시간을 쓴 '과거의 행동'을 추적하여 JTBD를 확인해야 함 [6-8].
• 기능(Feature)에서 과업(Job)으로의 전환: 단순한 '리포팅 기능' 요청을 분석할 때, 그것이 '데이터 발표 시의 자신감(정서적)'이나 '팀 내에서의 유능함(사회적)'을 위한 것인지 파악하여 우선순위를 결정함 [4].
• 상황적 맥락(Contextual Motivation): 사용자는 단순히 제품을 구매하는 것이 아니라, 특정 문제를 해결하기 위해 제품을 '고용(Hire)'한다는 관점을 가짐 [2].

📖 세부 내용 (Details)

• 전략적 중요성: 70%의 기능이 실패하는 이유는 검증되지 않은 가설에 기반하기 때문이며, JTBD는 표면적 요청 아래의 진정한 필요를 드러내어 개발 리소스 낭비를 방지함 [9-11].
• 가치 제안 캔버스(VPC)와의 연계: VPC의 고객 프로필 섹션에서 고객의 잡(Jobs), 고통(Pains), 이득(Gains)을 정의할 때 JTBD 프레임워크가 핵심 도구로 사용됨 [5].
• 실험 설계의 기초: Assumption Validation Loop에서 가장 위험한 가설(Riskiest Assumptions)을 식별할 때, 사용자가 해당 '잡'을 해결하기 위해 기꺼이 행동을 바꿀 의지가 있는지 확인하는 것이 첫 번째 단계임 [12, 13].
• 학습 목표 설정: 린 실험(Lean Experiment)을 설계할 때 "고객이 공급업체를 바꿀 만큼 이 과업을 중요하게 생각하는가?"와 같은 구체적인 학습 목표를 설정하는 근거가 됨 [14, 15].

⚖️ 모순 및 업데이트 (Contradictions & updates)

• 기능 중심 vs 가치 중심: 전통적인 로드맵은 기능(Features) 목록에 집중하지만, 최신 Lean Product Management는 측정 가능한 '결과(Outcomes)'와 '사용자 과업(Jobs)' 중심의 로드맵을 강조함 [1, 16, 17].
• 단순 미니멀리즘의 한계: MVP(최소 기능 제품)가 단순히 기능이 적은 제품을 의미하는 것으로 오해받기 쉬우나, JTBD 관점에서는 핵심 과업을 하나라도 완벽히 해결하여 'Aha Moment'를 제공하는 것이 중요함 [18, 19].

🛠️ 적용 사례 (Applied in summary)

• DeepL: 팀 구성원과 로드맵의 방향을 일치시키기 위해 JTBD 프레임워크를 내부적으로 적용함 [4].
• B2B SaaS 송장 관리: 단순한 송장 연결 기능이 아니라, 소규모 비즈니스와 엔터프라이즈 고객이 각각 해당 과업에서 느끼는 가치의 차이를 분석하여 세그먼트별 전략을 수립함 [20].
• 고객 그룹 정의: 린 실험 설계 시 참여자를 단순히 인구통계학적으로 나누지 않고, "해당 과업을 수행하는 데 있어 충족되지 못한 요구를 가진 그룹"으로 정의하는 데 적용됨 [21, 22].

✅ 검증 상태 및 신뢰도

• 상태: draft
• 검증 단계: conceptual (실제 프로젝트 적용 사례 및 프레임워크 가이드 확인됨)
• 출처 신뢰도: B (전문 프로덕트 매니지먼트 가이드 및 방법론 소스 기반)
• 중복 검사 결과: 신규 생성

🔗 관련 문서 링크 (Related document links)

상위/유사 개념

[발견 및 전략 프레임워크]

• Value Proposition Canvas
  • 연결 이유: JTBD를 통해 고객의 잡, 고통, 이득을 정의하는 핵심 입력 도구임 [5].
• Lean Startup
  • 연결 이유: 구축-측정-학습 루프의 시작점인 '가설'을 수립할 때 사용자 과업 기반의 사고가 필수적임 [23, 24].

[검증 프로세스]

• Assumption Validation Loop
  • 연결 이유: 사용자의 잡에 대한 가설은 검증 루프에서 가장 먼저 다뤄져야 할 핵심 가설임 [25].
• Customer Discovery Interviews
  • 연결 이유: JTBD를 파악하기 위해 'The Mom Test'와 같은 편향 없는 인터뷰 기법이 사용됨 [7, 26].

심층 후속 질문 (Deeper Research Questions)

• 사용자가 명시적으로 요청하지 않은 '잠재적 잡(Latent Jobs)'을 과거 행동 데이터를 통해 어떻게 체계적으로 추출할 수 있는가? [2, 6]
• 기능적 잡은 해결하지만 정서적/사회적 잡을 충족하지 못하는 제품이 시장에서 실패하는 상관관계는 어떠한가? [4, 18]
• Kano Model의 '매력적 품질(Delighters)' 요소와 JTBD의 정서적 잡 사이의 교차점은 무엇인가? [27, 28]
• B2B 환경에서 개인의 JTBD(사회적 인정 등)와 조직의 JTBD(비용 절감 등)가 충돌할 때 어떤 우선순위를 가져야 하는가? [20, 29]
• Minimum Lovable Product를 설계할 때 JTBD 프레임워크가 정서적 차별화를 위해 어떻게 기여하는가? [30, 31]

실무 적용 맥락 (Practical Application Contexts)

• Implementation: 새로운 기능을 개발하기 전, 해당 기능이 사용자의 잡 스테이트먼트 중 어느 부분(상황, 동기, 결과)을 강화하는지 명시함 [1].
• System Design: 사용자의 워크플로우를 설계할 때, 작업 완료 시간(기능적)뿐만 아니라 사용자가 느끼는 통제감이나 숙련도(정서적)를 UI/UX에 반영함 [4, 27].
• Operation / Maintenance: 기존 기능의 유지보수 시, 해당 기능이 해결하던 원래의 잡이 시장 변화로 인해 여전히 유효한지 지속적으로 확인(Continuous Discovery)함 [32, 33].
• Learning Path: 고객 인터뷰 기술인 'The Mom Test'를 익힌 후, 이를 JTBD 인터뷰 스크립트와 결합하여 실제 고객 환경에서 연습함 [26, 34].

인접 주변 주제 (Adjacent Topics)

• The Mom Test
  • 확장 방향: JTBD를 파악하기 위해 유도 질문을 피하고 사실 기반의 통찰을 얻는 방법론 [26].
• Kano Model
  • 확장 방향: 파악된 잡을 해결하는 기능들이 사용자 만족도에 미치는 영향을 분류하는 모델 [27, 35].

📝 변경 이력 (Change history)

• 2026-06-12: Initial draft generated via Datacollector_MAC P-Reinforce engine.