Jobs to be Done（待完成的任务），简称JTBD，是由哈佛商学院教授Clayton Christensen提出的产品思维框架。
核心思想：
人们不是在购买产品本身，而是在"雇佣"产品来帮助他们完成某项任务。
"雇佣"这个词用得很妙。想象一下：
如果清洁工打扫得不干净，会被解雇。如果App没能帮助记住事情，也会被卸载。
产品被"雇佣"是因为它能完成任务，被"解雇"是因为它完成得不好。
这是JTBD框架最著名的案例，来自一家快餐连锁店的真实经历。
这家连锁店想要提高奶昔的销量。最初的做法是：
结果：销量几乎没有变化。
研究团队换了一个问题：
"顾客在什么情况下会'雇佣'奶昔？他们要完成什么任务？"
通过观察发现：
大多数奶昔是在早上7点到9点之间卖出的，买奶昔的人通常是独自开车上班的通勤者。
这些通勤者要完成的任务不是"喝奶昔"，而是"在长时间通勤中有事可做"。
基于这个洞察，快餐店推出了：
销量大幅提升。
"帮我做一个待办清单App，要有：
任务分类、优先级标签、截止日期提醒、重复任务、
子任务拆解、标签系统、日历视图、统计报表、
多设备同步、协作共享、暗黑模式……"在列功能清单，而不是在解决问题
需求中没有提到：谁会用？在什么场景下用？要解决什么问题？
在假设用户需要这些
这些功能是想象出来的，还是真的有人需要？验证过吗？
复杂度会杀死项目
给AI一个20项功能的需求，结果通常是一团乱麻的代码，充满bug，难以调试。
某学习者尝试让AI做这个"功能齐全"的待办清单，三个小时后：
功能越多，失败概率越高。这是铁律。
"我要做一个可以帮助小学生练习英语口语的App"
没有验证小学生是否真的需要这个，以及：
大多数家长更倾向于：
"我要做一个帮助大学生管理时间的App"
"大学生"这个群体太宽泛了：
缩小范围：
在开始分析前，记住这个模板：
当 [某类用户] 在 [某个情境] 下，
他们想要 [完成某个任务]，
以便于 [获得某种结果/感受]。
目前他们的替代方案是 [现有解决方式]，
但这个方案的问题是 [痛点]。大多数初学者只看到功能任务，忽略了情感和社会任务：
用户要做的具体事情
用户想要的感受
用户想要的社会形象或关系
优秀的产品设计往往能同时满足三个层次。
功能任务：管理每日待办事项
情感任务：不用担心遗漏重要工作，感到安心
社会任务：在同事眼中看起来有条理、靠谱
我要做一个[产品类型]
它应该有[功能1]、[功能2]、[功能3]...
目标用户是[所有人]当[某类用户]在[某种情境]时
他们想要[完成某个任务]
因为现有方案[存在什么问题]
所以我的产品要[如何帮助]功能思维：我要做一个笔记App，支持Markdown、图片、搜索、云同步
任务思维：
✓ 先问"用户要完成什么任务"，再想"产品要有什么功能"
——功能是手段，任务是目的。搞反了就会做出没人用的东西。
✓ 产品是被"雇佣"来完成任务的，完成得不好就会被"解雇"
——用户不在乎你有多少功能，只在乎能不能帮他把事办了。
✓ 理解任务的三个层次：功能任务、情感任务、社会任务
——大多数初学者只看到功能层，忽略了情感和社会层。在进入下一节之前，确认你已经掌握：
能用一句话解释什么是JTBD框架
知道"功能视角"和"任务视角"的区别
能用模板写出一个完整的任务描述
理解为什么"简单"往往比"复杂"更好
完成了至少一个场景的JTBD分析练习
| 概念 | 一句话解释 |
|---|---|
| JTBD | 用户"雇佣"产品来完成任务，不是购买功能 |
| 功能视角 | 问"产品要有什么功能" |
| 任务视角 | 问"用户要完成什么任务" |
| 功能任务 | 用户要做的具体事情 |
| 情感任务 | 用户想要的感受 |
| 社会任务 | 用户想要的社会形象 |
| 替代方案 | 用户现在用什么方式解决问题 |
选择你最近想做的项目，用JTBD模板重新定义：
现在你已经理解了JTBD的基础概念，接下来我们将学习：
通过理论→实践→进阶的学习路径，你将彻底掌握从功能思维到任务思维的转变。