2.1.1 JTBD理论：从功能思维到任务思维
什么是JTBD
Jobs to be Done（待完成的任务），简称JTBD，是由哈佛商学院教授Clayton Christensen提出的产品思维框架。
核心思想：
人们不是在购买产品本身，而是在"雇佣"产品来帮助他们完成某项任务。
"雇佣"这个词用得很妙。想象一下：
- 雇佣清洁工，是为了让家里变干净
- 雇佣会计，是为了让账目清晰
- 雇佣待办清单App，是为了不遗漏重要的事
如果清洁工打扫得不干净，会被解雇。如果App没能帮助记住事情，也会被卸载。
产品被"雇佣"是因为它能完成任务，被"解雇"是因为它完成得不好。
奶昔的经典案例
这是JTBD框架最著名的案例，来自一家快餐连锁店的真实经历。
问题
这家连锁店想要提高奶昔的销量。最初的做法是：
- 调查顾客："你想要奶昔更甜还是更稠？"
- 增加口味选择：草莓、巧克力、香草……
- 优化配料组合
结果：销量几乎没有变化。
转折
研究团队换了一个问题：
"顾客在什么情况下会'雇佣'奶昔？他们要完成什么任务？"
通过观察发现： 大多数奶昔是在早上7点到9点之间卖出的，买奶昔的人通常是独自开车上班的通勤者。
洞察
这些通勤者要完成的任务不是"喝奶昔"，而是"在长时间通勤中有事可做"。
- 当前替代方案：无聊、吃东西会弄脏车、喝饮料容易洒
- 奶昔的优势：稠厚不易洒、可以慢慢喝、一只手就能操作
基于这个洞察，快餐店推出了：
- 更稠的奶昔（适合长时间通勤）
- 加入水果块（增加咀嚼的乐趣）
- 小份装（适合上班途中）
销量大幅提升。
初学者常犯的三个错误
错误一：功能堆砌症
典型表现
"帮我做一个待办清单App，要有：
任务分类、优先级标签、截止日期提醒、重复任务、
子任务拆解、标签系统、日历视图、统计报表、
多设备同步、协作共享、暗黑模式……"为什么这是错的
在列功能清单，而不是在解决问题 需求中没有提到：谁会用？在什么场景下用？要解决什么问题？
在假设用户需要这些 这些功能是想象出来的，还是真的有人需要？验证过吗？
复杂度会杀死项目 给AI一个20项功能的需求，结果通常是一团乱麻的代码，充满bug，难以调试。
真实后果
某学习者尝试让AI做这个"功能齐全"的待办清单，三个小时后：
- AI生成了超过2000行代码
- 页面加载后一片空白
- 控制台报了十几个错误
- 完全看不懂哪里出了问题
功能越多，失败概率越高。这是铁律。
错误二：解决不存在的问题
典型表现
"我要做一个可以帮助小学生练习英语口语的App"
问题在哪里
没有验证小学生是否真的需要这个，以及：
- 现在用什么方式练习英语口语？
- 现有方式的问题是什么？
- 家长是否愿意为这个付费？
实际情况
大多数家长更倾向于：
- 让孩子和真人外教练习
- 参加线下英语角
- 使用学校推荐的学习软件
错误三：目标用户过于宽泛
典型表现
"我要做一个帮助大学生管理时间的App"
问题在哪里
"大学生"这个群体太宽泛了：
- 大一新生和大四毕业生的需求完全不同
- 文科生和理科生的学习方式不同
- 勤工学生和全职学生的时间管理需求不同
正确的做法
缩小范围：
- "帮助大四理工科毕业生管理求职准备期间的时间"
- "帮助大一新生适应大学生活的时间规划"
JTBD任务描述模板
在开始分析前，记住这个模板：
当 [某类用户] 在 [某个情境] 下，
他们想要 [完成某个任务]，
以便于 [获得某种结果/感受]。
目前他们的替代方案是 [现有解决方式]，
但这个方案的问题是 [痛点]。三个层次的任务理解
大多数初学者只看到功能任务，忽略了情感和社会任务：
功能任务
用户要做的具体事情
- 例：记录待办事项
情感任务
用户想要的感受
- 例：安心、不焦虑
社会任务
用户想要的社会形象或关系
- 例：被视为靠谱的人
优秀的产品设计往往能同时满足三个层次。
举例分析
功能任务：管理每日待办事项 情感任务：不用担心遗漏重要工作，感到安心 社会任务：在同事眼中看起来有条理、靠谱
验证假设的方法
- 用户访谈：直接和目标用户对话
- 行为观察：看用户现在如何解决问题
- 替代方案分析：理解用户为什么选择现有方案
- 快速原型验证：用最小成本测试核心假设
用户访谈技巧
- 问"什么时候会用到这个"，而不是"你是否想要这个"
- 关注行为而非意见
- 了解现有解决方案的优缺点
- 探索背后的真实动机
行为观察要点
- 记录用户的具体行为
- 注意遇到的困难点
- 观察使用的工具和方法
- 了解时间、地点、情境
从功能思维到任务思维的转变
传统功能思维
我要做一个[产品类型]
它应该有[功能1]、[功能2]、[功能3]...
目标用户是[所有人]JTBD任务思维
当[某类用户]在[某种情境]时
他们想要[完成某个任务]
因为现有方案[存在什么问题]
所以我的产品要[如何帮助]转变练习
功能思维：我要做一个笔记App，支持Markdown、图片、搜索、云同步
任务思维：
- 当学生上课时，他们想要快速记录重要内容
- 因为现有笔记App要么功能复杂，要么同步慢
- 所以我的产品要提供极简界面和实时同步
核心原则总结
✓ 先问"用户要完成什么任务"，再想"产品要有什么功能"
——功能是手段，任务是目的。搞反了就会做出没人用的东西。
✓ 产品是被"雇佣"来完成任务的，完成得不好就会被"解雇"
——用户不在乎你有多少功能，只在乎能不能帮他把事办了。
✓ 理解任务的三个层次：功能任务、情感任务、社会任务
——大多数初学者只看到功能层，忽略了情感和社会层。检查清单
在进入下一节之前，确认你已经掌握：
- [ ] 能用一句话解释什么是JTBD框架
- [ ] 知道"功能视角"和"任务视角"的区别
- [ ] 能用模板写出一个完整的任务描述
- [ ] 理解为什么"简单"往往比"复杂"更好
- [ ] 完成了至少一个场景的JTBD分析练习
关键概念速查
| 概念 | 一句话解释 |
|---|---|
| JTBD | 用户"雇佣"产品来完成任务，不是购买功能 |
| 功能视角 | 问"产品要有什么功能" |
| 任务视角 | 问"用户要完成什么任务" |
| 功能任务 | 用户要做的具体事情 |
| 情感任务 | 用户想要的感受 |
| 社会任务 | 用户想要的社会形象 |
| 替代方案 | 用户现在用什么方式解决问题 |
延伸思考
思考题
- 为什么说"功能越多，失败概率越高"？
- 如何验证一个任务描述是否准确？
- 在Vibe Coding中，如何用任务思维给AI提需求？
实践应用
选择你最近想做的项目，用JTBD模板重新定义：
- 原始想法：
- JTBD重新定义：
下一步
现在你已经理解了JTBD的基础概念，接下来我们将学习：
- 2.1.1 JTBD实践应用 - 四个实际场景案例分析和练习
- 2.1.1 JTBD进阶技巧 - 深度理解和应用方法
通过理论→实践→进阶的学习路径，你将彻底掌握从功能思维到任务思维的转变。