# Jtbd Framework

> Apply Jobs-to-be-Done framework + Persona + Empathy map when uncovering what users actually want vs what they say they want. Use whenever 用户 says "用户到底想要什么" / "我们解决的是什么问题" / "persona 怎么定义" / "用户研究" / "JTBD" / "user need" / "为什么用户用我们" / "为什么不用". Forces functional + emotional + social job dimensions, distinguishes user-stated wants from underlying jobs, generates job statement in "When __ I want to __ so I can __" format, builds empathy map (Says/Thinks/Does/Feels) to triangulate. Stops feature-thinking, forces job-thinking. Self-contained methodology — no external docs required.

- Skill: `marsloting/jtbd-framework` (Agent Skill)
- Install (CLI): `npx skillmds@latest add marsloting/jtbd-framework`
- Raw SKILL.md: https://api.skillmd.com/api/skills/marsloting/jtbd-framework/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: marsloting (https://skillmd.com/u/marsloting)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/marsloting/jtbd-framework

---


# Jobs-to-be-Done + Persona + Empathy

## 何时触发

- "用户到底想要什么"
- 决定要不要做一个 feature 时（先问"它解决什么 job"）
- 看到用户反馈但没看出底层需求
- "我们的 USP 是什么"
- 竞品分析时（先对齐 job 才有可比性）
- onboarding 重设计前（先确认 job 顺序）
- 定 persona 之前

## 何时不触发

- 已经明确 job 了，要拆功能 → 用 `story-splitting`
- 已经明确多个 job 了，要排优先级 → 用 `rice-prioritization`
- 用户已经在用产品了，看体验流程 → 用 `journey-mapping`

## 核心理念（Christensen）

> "People don't buy a quarter-inch drill, they buy a quarter-inch hole."

用户买的不是产品（drill），是**完成一项工作的能力**（在墙上钻洞）。

更深一层："为什么要钻洞？" → 挂相框 → 让家变温馨 → 满足情感 + 社交需求。

**功能 job ≠ 全部**。还有 **情感 job** + **社交 job** 三层。

## JTBD 三层

| 层 | 含义 | 例子（"挂相框"） |
|---|---|---|
| **Functional job** | 任务本身要完成什么 | 在墙上钻一个 1/4 英寸的洞 |
| **Emotional job** | 完成这个任务时的内在感受 | 我能搞定我家装修，我有掌控感 |
| **Social job** | 别人怎么看我 / 我怎么呈现给别人 | 朋友来家里看到这面照片墙觉得我有品位 |

**红线**：只识别 functional job 的 JTBD 是不完整的。Emotional + Social 解释了"为什么用户在功能等价情况下选 A 不选 B"。

## Job Statement（标准格式）

```
When <情境>, I want to <动机>, so I can <结果 / 价值>.
```

### 例子

❌ 弱：用户想要一个收藏夹功能
✅ 强：**When** 我看到一篇感兴趣的文章但没空看，**I want to** 把它存起来稍后能找到，**so I can** 不用记在脑里也不会丢。

❌ 弱：用户想要更多的支付方式
✅ 强：**When** 我准备结账但发现要的支付方式没有，**I want to** 切换到 PayPal 或微信支付，**so I can** 不用退出去重新开始。

### 写法注意

- "When X" 是触发情境（具体场景），不是用户类型
- "I want to" 是动机（用户视角），不是 feature 描述
- "so I can" 是用户得到的价值 / 结果，不是产品功能

## 5 步流程

### Step 1：识别触发情境

用户在什么具体场景下需要这个 job？时间 / 地点 / 心情 / 紧迫度 / 设备。具体到一个画面，不是抽象描述。

### Step 2：写 functional job statement

```
When <触发情境>, I want to <做什么>, so I can <得到什么具体结果>.
```

### Step 3：挖 emotional job

完成这个 functional job 时用户**自我感觉**应该是什么？

- 自信 / 安心 / 掌控 / 高效
- 轻松 / 不被打扰 / 不出错

### Step 4：挖 social job

用户希望别人**怎么看**他？

- 专业 / 有品位 / 紧跟潮流 / 可靠
- 不被嘲笑 / 不显落伍 / 显得能干

### Step 5：竞品对照

针对同一个 job，用户**当前用什么完成**（不一定是软件——可能是手写 / 找朋友 / Excel / 第三方工具）？

- 当前方案的痛点（job 哪里没满足）
- 当前方案的好处（为什么没切换）

## Persona（基于 JTBD 不基于人口统计学）

旧 persona 模式：38 岁 / 北京 / 中产 / 喜欢咖啡 / 已婚 → 几乎没用。

**JTBD-based persona** 模式：

```markdown
## Persona: <名字>

### 触发情境（不是人口学）
- 通常在什么场景下出现 X 需求

### 三层 job
- Functional: ...
- Emotional: ...
- Social: ...

### 当前的解决方案
- 在用 X / Y / Z 完成这个 job

### 切换阻力
- 时间 / 钱 / 习惯 / 技能 / 朋友圈

### 切换驱力
- 当前痛点 / 新需求出现 / 触发事件
```

## Empathy Map（4 象限）

挖完 JTBD 后做 empathy map 三角验证。

```
┌─────────────────────┬─────────────────────┐
│      SAYS           │      THINKS         │
│   （他说什么）        │   （他心里怎么想）   │
│   - 直接引述         │   - 推测的内心想法    │
│   - 用户访谈原话      │   - 不会大声说的       │
├─────────────────────┼─────────────────────┤
│      DOES           │      FEELS          │
│   （他做什么）        │   （他感觉如何）     │
│   - 观察到的行为      │   - 情绪 / 状态       │
│   - 用产品的方式       │   - 焦虑 / 兴奋 / 沮丧 │
└─────────────────────┴─────────────────────┘
```

**关键**：四个象限**互相对照**。如果 SAYS 和 DOES 不一致 → 用户言行不一 → 真实 job 在 DOES 里不在 SAYS 里。

## 模板（完整 JTBD 输出）

```markdown
# JTBD Analysis: <场景名>

## 触发情境
<具体到一个画面：时间 / 地点 / 设备 / 心情>

## Job Statements（三层）

### Functional
**When** <情境>, **I want to** <动机>, **so I can** <结果>.

### Emotional
用户希望感觉：<自信 / 掌控 / 轻松 / ...>
不希望感觉：<焦虑 / 出错 / 被嘲笑 / ...>

### Social
用户希望别人看他：<专业 / 跟潮流 / 可靠 / ...>
不希望别人看他：<落伍 / 笨拙 / ...>

## 当前解决方案 vs 我们方案

| 维度 | 当前方案 | 我们方案 | 是否解决 job 更优 |
|---|---|---|---|
| Functional | ... | ... | ✅/❌ |
| Emotional | ... | ... | ✅/❌ |
| Social | ... | ... | ✅/❌ |

## 切换阻力 / 驱力分析

阻力（用户为什么不切换）：
- ...

驱力（什么会促使切换）：
- ...

## Persona 触达
- 触发情境出现频率：高 / 中 / 低
- 当前用户群规模估算：...

## Empathy Map

| SAYS | THINKS |
|---|---|
| 用户访谈原话 1 | 推测内心想法 1 |

| DOES | FEELS |
|---|---|
| 观察到的行为 1 | 情绪 1 |

## 决策建议
- 这个 job 值得做吗？（输入 rice-prioritization）
- Functional / Emotional / Social 哪一层是差异化重点？
```

## Anti-Rationalization

| 逃逸路径 | 为什么不行 |
|---|---|
| "用户说想要 X 我们就做 X" | 用户说的是表层需求，job 是底层动机。需求工程史上经典翻车："用户说想要更快的马"（Ford） |
| "只挖 functional job 够了" | 缺 emotional + social → 解释不了为什么用户在功能等价时选竞品。差异化通常发生在 emotional / social 层 |
| "Persona 用人口学就行了" | 38 岁北京中产男 = 一群人 job 完全不同。基于 JTBD 的 persona 才有解释力 |
| "Empathy map 四象限太多了" | 关键不是写满，是看 SAYS vs DOES 一致性。不一致 = job 在 DOES 里。少一个象限就漏关键信号 |
| "JTBD 太学术，直接做 feature" | "直接做 feature"是没有 job 锚点的赌博。30% feature 上线后没人用就是没 job |
| "我们已经知道用户想要什么了" | "已经知道" = 假设没验证。JTBD 是把假设显式化的工具，不是补全工具。已经知道也要走一遍验证 |
| "竞品对照太麻烦不做" | 不做 = 不知道用户当前用什么完成 job = 不知道切换阻力 = 设计的 onboarding 失效 |

## 关联

- 挖完 job 后 → 进 `story-splitting` 拆 feature
- 多个 job 排优先级 → `rice-prioritization`
- 全流程体验设计 → `journey-mapping`
- 写 spec 时引用 → `product-management:write-spec`
- 用研合成已有访谈数据 → `product-management:synthesize-research`

## Status

v1.0 — 2026-05-08 product-thinking plugin v0.1.0 首发。