Files

T

Antigravity Agent 9a135bd19d docs(10_Wiki): Topic_Business/General/Graphic/Programming을 Topics/ 하위로 이동

최상위 10_Wiki/Topic_*였던 4개 카테고리 폴더를 10_Wiki/Topics/Topic_* 로 재배치.
콘텐츠 변경 없음(순수 폴더 이동) — Topics/ 하위 나머지 폴더는 이미 지난 커밋에서
전부 정리된 상태(잔존 항목은 에이전트 운영 상태 및 사용자가 보존을 요청한
업데이트0615/무제 3.canvas 뿐).

2026-07-05 00:44:01 +09:00

6.8 KiB

Raw Blame History

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

title

Jobs to Be Done (JTBD)

🎯 한 줄 통찰 (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]

🧩 추출된 패턴 (Extracted patterns)

가치 제안 매핑 (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 (전문 아티클 및 전략 가이드 기반)
중복 검사 결과: 신규 생성

상위/유사 개념

[전략 및 프레임워크]

Assumption Validation Loop
- 연결 이유: JTBD는 검증 루프의 입력값인 '문제 가설'을 정의하는 데 필수적임. [4, 5]
Value Proposition Canvas
- 연결 이유: 고객 프로필 섹션이 JTBD 구조(Jobs, Pains, Gains)를 따름. [7]

[실행 도구]

Minimum Viable Product (MVP)
- 연결 이유: MVP는 특정 JTBD를 해결하기 위한 가장 작은 실험체여야 함. [2, 11]
Customer Discovery
- 연결 이유: 인터뷰 단계에서 실질적인 통찰을 얻기 위한 기법으로 JTBD가 활용됨. [5, 8]

심층 후속 질문 (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]

6.8 KiB Raw Blame History