agentsclimarketplace

Jtbd framework

Skill marsloting/product-thinking-pack/skills/jtbd-framework

7 self-contained product-thinking skills that make an AI agent reason like a sharp PM before it acts. MIT.

Install
npx -y skills add marsloting/product-thinking-pack --skill jtbd-framework

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.md

8.2 KB, as published. Nobody here has run it

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 首发。

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.