jobs-to-be-done

目的

系统地探索客户想要完成的事情（功能性、社交性和情感性任务）、他们遇到的痛点，以及他们追求的收益。运用这一框架发现未满足的需求、验证产品创意，并确保你的解决方案回应真实动机，而不只是表面上的功能需求。

这不是一份调查问卷，而是一个结构化视角，帮助理解客户为何“雇用”你的产品，以及什么会让他们“解雇”它。

输入

最适合提供： 你要分析的客户群体（或其客户所使用的产品）。 也很有帮助： 可用于挖掘任务、痛点和收益的访谈笔记、支持工单或研究资料；以及你关注的情境或触发因素。

在调用时一并提供的任何内容——技能名称后面的文本、粘贴的上下文，或附加的 ARGUMENTS: 行——都视为已给出的答案。使用这些内容，并跳过其中已经涵盖的问题；不要再次询问。

空手而来也没关系。 在构建 JTBD 分析之前，这项技能会先询问客户是谁，以及他们想要取得什么进展。

调用示例： Run JTBD for freelance designers using our invoicing tool — here are 6 interview summaries.

核心概念

待完成任务框架

JTBD 受 Clayton Christensen 和价值主张画布（Osterwalder）的影响，将客户需求分为三类：

1. 客户任务：

• 功能性任务： 客户需要完成的任务（例如，“发送发票”）
• 社交性任务： 客户希望给人留下的印象（例如，“在客户面前显得专业”）
• 情感性任务： 客户想要获得或避免的情绪状态（例如，“对自己的工作有信心”）

2. 痛点：

• 挑战： 客户面临的障碍
• 成本负担： 在时间、金钱或精力方面过于昂贵的事情
• 常见错误： 客户会犯且本可避免的错误
• 未解决的问题： 现有解决方案中的缺口

3. 收益：

• 期望： 超越现有解决方案的体验
• 节省： 令人满意的时间、金钱或精力节省
• 采用因素： 提高客户转换可能性的因素
• 改善生活： 解决方案如何让生活更轻松或更愉快

这种结构为何有效

• 将任务与解决方案区分开： “与我的团队沟通”（任务）≠“电子邮件”（解决方案）
• 揭示深层动机： 功能性任务可能是“跟踪开支”，但情感性任务是“感觉自己掌控着财务状况”
• 发现未曾察觉的竞争对手： 客户会“雇用”一些不那么显眼的替代方案（纸笔、电子表格、变通方法）
• 按强度确定优先级： 痛点并非都同等重要——优先关注最迫切的痛点

反模式（这不是什么）

• 不是功能愿望清单： “我想要 AI、自动化和仪表板”不是任务
• 不是人口统计特征： “千禧一代想要移动优先”是用户画像特征，不是任务
• 不是泛泛而谈： “提升工作效率”过于模糊——深入探究具体是哪些任务，以及原因
• 不是单一维度： 只关注功能性任务会忽略社交和情感动机

适用场景

• 早期探索（尚未确定解决方案之前）
• 验证产品与市场的契合度（你的解决方案是否回应了正确的任务？）
• 确定路线图优先级（哪些任务最痛苦、最重要？）
• 竞争分析（客户为何“雇用”竞争对手？）
• 营销信息传达（围绕任务沟通，而非功能）

不适用场景

• 产品已经开发完成之后（此时进行探索为时已晚）
• 无关紧要的功能（不要过度分析小改动）
• 作为定量验证的替代品（JTBD 帮助提出假设，数据负责验证假设）

---

应用

使用 template.md 查看完整的填写结构。

步骤 1：定义背景

在探索 JTBD 之前，请先明确：

• 目标客户细分群体： 你正在研究谁？（参考 skills/proto-persona/SKILL.md）
• 情境： 工作在什么情境下出现？（例如：“在管理项目截止日期时……”）
• 当前解决方案： 他们现在使用什么？（竞争对手、变通方法，或什么都不做）

如果缺少背景信息： 开展客户访谈、情境调查或“转换访谈”（了解他们为什么从之前的解决方案转向其他方案）。

---

步骤 2：探索客户工作

功能性工作

询问：“你想完成哪些任务？”

### Functional Jobs:
- [Task 1 customer needs to perform]
- [Task 2 customer needs to perform]
- [Task 3 customer needs to perform]

示例：

• “核对月度开支，以便报税”
• “在 2 小时内完成新团队成员的入职引导”
• “在不造成停机的情况下将代码部署到生产环境”

质量检查：

• 以动词为导向： 工作应是行动（“发送”“分析”“协调”）
• 不依赖特定解决方案： 不要说“使用电子邮件进行沟通”，而应说“与远程队友沟通”
• 具体明确： “管理财务”过于宽泛；“跟踪可用于税务抵扣的业务开支”则具体明确

---

社交性工作

询问：“你希望别人如何看待你？”

### Social Jobs:
- [Way customer wants to be perceived socially 1]
- [Way customer wants to be perceived socially 2]
- [Way customer wants to be perceived socially 3]

示例：

• “让高管团队认为我是一个有战略思维的人”
• “在客户眼中显得响应及时、值得信赖”
• “让年轻同事觉得我精通技术”

质量检查：

• 明确受众： 客户想给谁留下好印象？（老板、客户、同事等）
• 情感分量： 与功能性工作相比，社交性工作往往更能推动用户采用

---

情感性工作

询问：“你想达到或避免什么情绪状态？”

### Emotional Jobs:
- [Emotional state customer seeks or avoids 1]
- [Emotional state customer seeks or avoids 2]
- [Emotional state customer seeks or avoids 3]

示例：

• “确信自己没有遗漏重要细节”
• “避免手动录入数据出错带来的焦虑”
• “在一天结束时感到有所成就”

质量检查：

• 兼顾正面和负面： 同时包括他们追求的感受（“感到一切尽在掌控”）和想要避免的感受（“避免尴尬”）
• 以研究为依据： 不要凭空编造情绪，应使用客户原话

---

步骤 3：识别痛点

挑战

询问：“哪些障碍阻碍你完成这项工作？”

### Challenges:
- [Obstacle customer faces 1]
- [Obstacle customer faces 2]
- [Obstacle customer faces 3]

示例：

• “工具之间无法集成，导致必须手动录入数据”
• “无法了解队友正在做什么”
• “审批流程需要 3 天以上，阻碍工作推进”

---

成本

询问：“哪些事情耗费了过多时间、金钱或精力？”

### Costliness:
- [What's too costly in time, money, or effort 1]
- [What's too costly in time, money, or effort 2]

示例：

• “生成月度报告需要 8 小时的手动工作”
• “聘请专家要花 1 万美元，我们负担不起”
• “学习当前工具需要 20 小时以上的培训”

---

常见错误

询问：“你经常犯哪些本可避免的错误？”

### Common Mistakes:
- [Frequent error 1]
- [Frequent error 2]

示例：

• “忘记在重要邮件中抄送相关人员”
• “因缺少收据而算错税务抵扣额”
• “在共享文件中意外覆盖他人的工作”

---

未解决的问题

询问：“当前解决方案有哪些问题未能解决？”

### Unresolved Problems:
- [Problem not solved by current solutions 1]
- [Problem not solved by current solutions 2]

示例：

• “当前的 CRM 不会跟踪客户健康度评分”
• “有人在邮件会话中途加入时，电子邮件无法保留对话上下文”
• “现有工具需要我们不具备的专业技术知识”

---

步骤 4：发现收益

预期

询问：“什么样的解决方案会让你爱不释手？”

### Expectations:
- [What could exceed expectations 1]
- [What could exceed expectations 2]

示例：

• “无需手动添加标签，就能自动对开支进行分类”
• “根据项目状态建议下一步行动”
• “与我们现有的工具无缝集成”

---

节省

询问：“节省多少时间、金钱或精力会让你感到惊喜？”

### Savings:
- [Way of saving time, money, or effort 1]
- [Way of saving time, money, or effort 2]

示例：

• “将报告生成时间从 8 小时缩短到 10 分钟”
• “不再需要全职行政人员”
• “将入职引导时间从 2 周缩短到 2 天”

---

采用因素

询问：“什么会促使你从当前解决方案转向其他方案？”

### Adoption Factors:
- [Factor increasing likelihood of adoption 1]
- [Factor increasing likelihood of adoption 2]

示例：

• “无需提供信用卡的免费试用”
• “提供迁移支持，以导入现有数据”
• “与我们类似的公司提供的推荐评价”

---

生活改善

提问：“如果这项工作变得更轻松，你的生活会有什么改善？”

### Life Improvement:
- [How solution makes life easier or more enjoyable 1]
- [How solution makes life easier or more enjoyable 2]

示例：

• “我可以准时下班，而不用为了完成报告加班”
• “我不会再那么担心错过重要的截止期限”
• “我可以专注于战略性工作，而不是琐碎事务”

---

步骤 5：确定优先级并验证

• 按痛点强度排序： 哪些痛点很严重，哪些只是轻微的不便？
• 区分必备收益与锦上添花的收益： 哪些会推动用户采用，哪些只是额外好处？
• 与用户画像交叉参照： 不同的用户画像是否有不同的任务、痛点和收益？（参见 skills/proto-persona/SKILL.md）
• 用数据验证： 调查更广泛的受众，以确认访谈中得到的 JTBD 见解

---

示例

完整的 JTBD 示例请参见 examples/sample.md。

简短示例摘录：

**Functional Jobs:** Coordinate tasks across a distributed team
**Pains - Challenges:** Team members use different tools, creating silos
**Gains - Savings:** Reduce status reporting time from 3 hours to 15 minutes

---

常见陷阱

陷阱 1：将任务与解决方案混为一谈

症状：“我需要使用 Slack”或“我需要 AI 驱动的分析”

**后果：**你关注的是解决方案，而非背后的任务。

**解决方法：**连续问 5 次“为什么？”。“我需要 Slack”→“为什么？”→“为了和团队沟通”→“为什么？”→“为了快速获得答复”→“为什么？”→“为了避免项目延误。”

---

陷阱 2：任务过于笼统

症状：“提高效率”或“节省时间”

**后果：**过于模糊，无法为产品决策提供依据。

**解决方法：**具体描述。“节省时间”→“将生成月度报告所花的时间从 8 小时缩短到 1 小时。”

---

陷阱 3：忽视社交和情感任务

**症状：**只记录功能性任务

**后果：**你会错过强大的驱动力。人们购买产品往往出于情感或社交需求，而不只是功能需求。

**解决方法：**在访谈中明确询问他人的看法和情绪。“解决这个问题会让你有什么感受？”“如果你解决了这个问题，谁会注意到？”

---

陷阱 4：未经研究就编造 JTBD

**症状：**根据假设填写模板

**后果：**你是在猜测。只有以真实的客户见解为依据，JTBD 分析才有价值。

**解决方法：**开展“转换访谈”（询问用户为何从之前的解决方案转向其他方案）、情境调查或问题验证访谈。

---

陷阱 5：将所有痛点一视同仁

**症状：**列出 20 个痛点，却不确定优先级

**后果：**不清楚应该先解决什么。

**解决方法：**按强度对痛点排序（严重或轻微）。提问：“如果我们只能解决一个痛点，哪一个会带来最大的影响？”

---

参考资料

相关技能

• skills/proto-persona/SKILL.md — 定义谁有这些任务、痛点和收益
• skills/problem-statement/SKILL.md — JTBD 为“试图”和“但是”部分提供依据
• skills/positioning-statement/SKILL.md — JTBD 为“需要……”陈述提供依据

外部框架

• Clayton Christensen，Competing Against Luck（2016）— “待完成任务”理论的起源
• Tony Ulwick，Outcome-Driven Innovation（2016）— 量化任务和成果
• Alexander Osterwalder，Value Proposition Canvas（2014）— 客户任务、痛点和收益框架

Dean 的作品

• [如适用，添加 Dean Peters 的 Substack 相关文章链接]

来源

• 改编自 https://github.com/deanpeters/product-manager-prompts 仓库中的 prompts/jobs-to-be-done.md。

---

**技能类型：**组件 建议文件名：jobs-to-be-done.md 建议存放位置：/skills/components/ **依赖项：**引用 skills/proto-persona/SKILL.md 使用方：skills/positioning-statement/SKILL.md、skills/problem-statement/SKILL.md、skills/epic-hypothesis/SKILL.md