marsloting 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 模式：
## 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 输出）
# 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 首发。