用户为什么要“雇佣”你的产品？

导读

JTBD 全称是 Jobs To Be Done，待办任务理论。它主张用户不是买产品，是“雇佣”产品，在某个场景下帮自己完成一件事（Job）。它补上苏格拉底提问不关心的问题——为什么要做：用一句 Job Story 把触发场景、动机、现状和成功标准收成一个任务，AI 才知道什么才算做成。

严格来讲，JTBD 这一章的内容是苏格拉底提问法的补丁。

举个例子：

买钻头的人要的是墙上的洞。与此同时，40 元的小锤和 80 元的大锤同样可以在墙上留下一个洞。

苏格拉底提问的追问方向是技术实现和边界条件，它不天然会追问「你为什么要做」。 所以，当你把「需求」描述成功能时，苏格拉底提问不会纠正你。

就像前面「开洞」的例子，苏格拉底追问的方向是：如何才能给你推荐一个口径尽可能大的钻头——它甚至会一脸认真地跟你比较不同型号盾构机的差异。

这个模型你不需要全都了解，我们只需要提炼它的三个角度。

视角切换

用户要的不是产品本身，而是完成任务。

苏格拉底提问法的交付物，是产品应该具备的规格，它并不代表这个产品能解决你现在面临的问题。

Job Story 句式

把模糊需求收敛成一句可执行描述。

人类的思维惯性是：「作为一个【角色】，我想要【功能】，以便【价值】」，但「角色」不如「场景」有指导意义。

例如，同一个人，在「月底给老板汇报」和「日常自己看数据」两个情境下，要完成的任务完全不同：

当月底要给老板汇报项目进展时，我想要快速汇总关键数据，以便不用截图和复制粘贴就能生成一页报告。

这句话里已经有触发条件、动机、期望结果。AI 可以基于它写需求文档，也可以判断哪些功能必要。如果「导出 Excel」不能帮助这个 Job，它就不是第一优先级。

现状追问

在这个「产品」没有发明出来之前，你是怎么做的？

用户不会凭空选择新方案，用户是在推和拉、焦虑和习惯之间做权衡：

• 推力是现状哪里痛；
• 拉力是新方案哪里好；
• 焦虑是换方案的风险；
• 习惯是旧做法的惯性。

现状追问挖的是推力和替代方案。

你要问：你现在怎么解决？多久一次？哪一步最烦？如果明天没有这个产品，你会怎么办？如果现状不痛，用户不会改变；如果现有替代方案够好，新功能就没有必要。只有理解「凑合」，才知道你要替代什么。

三个角度可以浓缩成一句话（请记下来）

当 __________ 的时候，我想要 __________，以便于 __________。
现在我只能通过 __________ 来勉强完成这件事。

项目会的例子：

当我开完一场信息量很大的项目会时，我想要快速得到一份带待办、责任人和截止时间的纪要，以便于我能马上同步团队并推进执行。现在我只能靠自己回忆、翻聊天记录和手工整理来勉强完成。

打卡的例子也可以写成：

当每天到了论坛签到时间、我又怕断签时，我想要确保连续签到不中断，以便保留连续打卡记录/权益。现在我只能每天手动打开网页、登录、找签到按钮来勉强完成。

这时 AI 才知道，「不能中断」才是任务的成功标准，脚本不能是跑完就拉倒，还需要有一个确认是否成功的反馈和基于反馈的应对机制。所以 AI 在完成 8 行代码、实现打卡这个动作之后，又补了 33 行代码，完成反馈和基于反馈的应对机制。

它和苏格拉底提问是什么关系

这里要理清楚，否则你会以为又多了一套方法。

它们不是并列关系。它们是接力：

• 苏格拉底提问负责「挖实现条件」：通过连续追问，把技术路径、边界、风险、成功标准挖出来。它容易顺着「怎么做」往下走，不主动停在「为什么要做」。
• JTBD 负责「补目的并收任务」：把场景、动机、现状和成功标准，收成一句 AI 能直接执行的任务。

苏格拉底问完，你手里可能有一堆回答，但那些回答还是散的。JTBD 把它们收成一句 Job Story，AI 才知道你要它做什么。

所以它不需要独立 Skill，也不需要另起一套完整提示词。它只是在苏格拉底提示词里，补一条规则。

参考资料

• 你真的知道自己要什么吗？