---
id: jobs-to-be-done
title: "Jobs to Be Done"
category: "10_Wiki/Topics"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["JTBD"]
duplicate_of: ""
source_trust_level: "B"
confidence_score: 0.85
created_at: 2026-06-12
updated_at: 2026-06-12
review_reason: ""
merge_history: []
tags: ["research", "Assumption Validation Loop", "Product Discovery"]
raw_sources: ["NotebookLM Synthesis"]
applied_in: ["DeepL Team/Roadmap Alignment", "Lokalise Shopify App Discovery"]
github_commit: ""
---

# [[Jobs to Be Done]]

## 🎯 한 줄 통찰 (One-line insight)
제품의 기능적 특성이 아니라, 사용자가 특정 상황에서 달성하고자 하는 본질적인 목적과 동기(Job)를 규명함으로써 시장 적합성(Product-Market Fit)의 정밀도를 극대화하는 프레임워크이다 [1, 2].

## 🧠 핵심 개념 (Core concepts)
- **과제 진술문 (Job Statement):** "특정 [상황]에서, 나는 [동기]를 원하므로, [기대 결과]를 얻을 수 있다"는 표준 형식을 통해 사용자 의도를 구조화한다 [1].
- **의도 중심 사고 (Intent over Requests):** 사용자가 표면적으로 요청하는 기능(Feature)이 아니라, 그 이면에 숨겨진 실제 수행하려는 작업과 목적에 집중한다 [1, 3].
- **다차원적 과제 (Multidimensional Jobs):** 하나의 제품 고용에는 기능적, 정서적, 사회적 층위의 목적이 동시에 존재한다 [4].
- **가설 검증의 닻 (Validation Anchor):** 제품 가설 검증 루프에서 '무엇을 만들 것인가'를 결정하기 전에 '왜 필요한가'를 정의하는 기준점이 된다 [5, 6].

## 🧩 추출된 패턴 (Extracted patterns)
- **상황적 맥락 패턴:** 사용자가 제품을 '고용'하는 시점의 구체적인 상황(Situation)을 정의하여 마케팅 및 기능 우선순위의 노이즈를 제거한다 [1, 4].
- **다층적 분석 패턴:** 보고 기능 요청 시 이를 기능적(통찰 생성), 정서적(자신감), 사회적(유능해 보임) 과제로 분해하여 솔루션의 범위를 확장한다 [4].
- **선행 단계 패턴:** 가설 검증 루프(Assumption Validation Loop)의 초기 단계(1~2주 차)에 JTBD 인터뷰를 배치하여 솔루션 브레인스토밍의 효율성을 높인다 [6].

## 📖 세부 내용 (Details)
**1. JTBD의 정의와 역할**
Jobs-to-be-Done(JTBD) 프레임워크는 제품 개발의 관점을 기능 중심에서 사용자 의도 중심으로 전환한다 [1]. 이는 사용자가 제품을 구매하는 행위를 특정 문제를 해결하기 위해 제품을 '고용'하는 것으로 간주하며, 이를 통해 제품-시장 적합성을 더 명확히 확보할 수 있게 한다 [2, 7].

**2. 과제의 3가지 범주 [4]**
- **기능적 과제 (Functional Jobs):** 사용자가 완료해야 하는 실질적이고 구체적인 작업 (예: 데이터 분석 결과 도출).
- **정서적 과제 (Emotional Jobs):** 작업을 수행하는 동안 사용자가 느끼고 싶은 감정 상태 (예: 보고서 작성 시 느끼는 안도감 및 자신감).
- **사회적 과제 (Social Jobs):** 타인에게 어떻게 비춰지기를 원하는지에 대한 욕구 (예: 팀 내에서 준비된 전문가로 인식됨).

**3. 가설 검증 루프에서의 활용**
- **문제 검증 (Problem Validation):** 사용자가 현재 겪고 있는 고통이 충분히 커서 대안을 찾고 있는지를 JTBD 관점에서 질문한다 [8, 9].
- **솔루션 도출:** 검증된 과제 진술문을 바탕으로 한 가지 핵심 가정당 최소 3~5개의 다양한 해결책을 브레인스토밍하여 최적의 MVP를 설계한다 [5].
- **Kano 모델과의 결합:** 각 과제 해결을 위한 기능들이 사용자에게 필수적인지(Must-haves), 만족을 주는지(Performance), 혹은 감동을 주는지(Delighters)를 분석하는 기초가 된다 [10, 11].

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- **표면적 요구 vs. 실제 의도:** 사용자의 "이 기능이 필요하다"는 진술은 종종 잘못된 솔루션을 지향할 수 있으며, JTBD는 이러한 발언을 그대로 믿지 말고 과거의 행동과 동기를 추적할 것을 권장한다 [2, 9].
- **미래 예측의 불확실성:** "이 제품을 사용하겠는가?"라는 질문은 신뢰도가 낮으며, JTBD 인터뷰는 철저히 과거의 구체적인 상황과 행동에 초점을 맞춘다 [12, 13].

## 🛠️ 적용 사례 (Applied in summary)
- **DeepL:** 팀 구성원 간의 정렬 및 로드맵 수립 과정에서 JTBD를 적용하여 제품의 방향성을 일치시킴 [4].
- **Lokalise:** Shopify 번역 앱의 초기 도입(Early Adoption)을 유도하기 위해 사용자 과제를 정의하고 가시성/바람직성/수익성 테스트를 수행함 [14].
- **전통적 MVP 실패 방지:** 70%에 달하는 기능 실패율을 극복하기 위해 사용자 요청을 JTBD로 재해석하여 실제 가치 중심의 기능을 선별함 [15, 16].

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual (다수의 성공 사례와 프레임워크 문서에 의해 이론적 가치가 입증됨) [4, 17].
- **출처 신뢰도:** B (공식 방법론 가이드 및 제품 관리 전문 교육 자료 기반)
- **중복 검사 결과:** 신규 생성 (New discovery)

## 📝 변경 이력 (Change history)
- 2026-06-12: Datacollector_MAC P-Reinforce 엔진을 통해 초기 초안 생성 및 핵심 소스(309, 311, 317 등) 기반 고밀도화 완료.