jobs-to-be-done

jobs-to-be-done 技能概览

jobs-to-be-done 技能可以帮你把一个模糊的客户问题，整理成结构化的 JTBD 分析：功能性工作、社交性工作、情感性工作、痛点和收益。它最适合 Product Management、信息传达、访谈式探索，以及产品重新定位等场景，尤其是在你需要理解客户为什么选择一款产品，而不只是他们表面上说想要什么的时候。

如果你想要的不是一个通用 prompt，那么这项技能很值得安装。它提供了一套可重复使用的分析视角，帮助你把表层的功能诉求和背后的真实动机分开来看；在路线图争论、流失分析或新产品探索卡在“各说各话”时，这一点特别有用。

jobs-to-be-done 技能能做什么

它会把客户背景信息整理成一个可复用的实用模板，适用于不同产品或不同细分人群。它的核心价值在于清晰：帮你定义“任务”，识别摩擦点，并看清用户眼中的“更好”到底意味着什么。

谁应该使用它

如果你是 PM、创始人、市场人员、UX researcher 或分析师，想提升产品探索质量，或把客户语言转化为可执行洞察，就适合使用 jobs-to-be-done 技能。尤其是在团队已经收集到反馈，但还没有形成清晰解读时，它会特别有帮助。

什么情况下它最适合

当你的目标是理解未被满足的需求、验证一个想法、打磨定位，或者把现有方案和客户真正要完成的任务做对比时，选它最合适。如果你只是需要快速写文案，或者只想不带客户证据地做一个高层次头脑风暴，它的价值就没那么高。

如何使用 jobs-to-be-done 技能

安装后，把它对准一个真实问题

先通过技能管理器走 jobs-to-be-done install 流程，然后在 repo 路径 skills/jobs-to-be-done 下展开工作。上游技能本身很轻量，而且是基于文件组织的，所以最值得先读的是 SKILL.md，然后是 template.md 和 examples/sample.md。

提供具体的客户上下文

这个技能在你的 prompt 明确写出受众、场景和决策时效果最好。差的输入是：“分析我们的产品。” 更好的输入是：“针对 Product Management，使用 jobs-to-be-done 分析一款面向自由职业者的订阅制发票工具；这些用户因为漏收款而从表格迁移过来。”

把模糊目标转成可用 prompt

一条好的 jobs-to-be-done 使用提示，应该包含：

• 目标用户群
• 触发需求的事件
• 当前替代方案或竞争对手
• 你希望改善的结果
• 你已经掌握的证据，例如访谈笔记或客服工单

示例：“为需要在项目交付后更快开票的小型代理机构老板，创建一份 JTBD 分析。重点关注 job、pains 和 gains，并标出人工跟进在哪里制造了摩擦。”

写之前先看模板

template.md 展示了这个技能期待的结构，examples/sample.md 则展示了什么样的细节密度才会让输出真正有用。如果你的输入太薄，输出通常也会很薄；先看模板，能帮助你在让模型补全之前，先发现自己缺了哪些信息。

jobs-to-be-done 技能常见问题

jobs-to-be-done 比普通 prompt 更好吗？

是的，尤其是在你需要一致性的时候。普通 prompt 可能某一次也能用，但 jobs-to-be-done 技能提供了一套可复用结构，能减少不同分析之间的漂移，也让不同细分人群之间的对比更容易。

这个 jobs-to-be-done 技能适合新手吗？

适合，只要你能描述用户和场景就行。你不需要先掌握很深的 JTBD 理论，但你确实需要足够的上下文，才能避免输出变得空泛。如果你已经了解产品领域，只是想要更锋利的切入方式，这个技能会特别强。

它在哪些方面做得不够好？

它不能替代访谈、行为数据或市场研究。如果输入只有内部观点，分析可能看起来很合理，但还是会错过真实的客户任务。它也不是纯技术文档或功能规格说明的最佳选择。

它对 Product Management 有用吗？

有。用于 Product Management 的 jobs-to-be-done 技能非常适合做探索、定位、优先级排序和信息测试，因为它会先逼你用客户语言把问题定义清楚，再去谈解决方案。

如何改进 jobs-to-be-done 技能

提供更丰富的原始材料

质量提升最大的来源，就是更好的输入：访谈原话、客服主题、流失原因、销售电话记录，或者用户在使用你的产品之前尝试过什么。上下文越具体，技能需要自行推断的部分就越少。

说清楚任务，而不只是功能

如果你只问“怎么优化 onboarding”，得到的可能只是泛泛建议。若你问的是“如何帮助首次使用者在不联系支持的情况下完成第一张发票”，jobs-to-be-done 的输出就会具体得多，因为这个任务是可以被验证的。

注意常见失误模式

最常见的失误，是过度聚焦功能，却没有把用户所处的情境说清楚。另一个问题是把多个细分人群混在一份分析里。如果第一版感觉太宽泛，就用一个细分人群、一个触发点和一个期望结果，重新跑一遍 jobs-to-be-done 指南。

利用缺口和矛盾继续迭代

拿到第一版输出后，可以继续追问哪些地方还缺信息：哪些 pains 的代价最高？哪些 gains 是必须的，哪些只是锦上添花？哪些社交性或情感性工作，正在推动用户采纳？第二轮通常会产出最适合 Product Management 决策和信息传达工作的材料。