Framework Deep Dive

任务
驱动

用户不是在买你的产品,而是在雇佣它完成一件事。找到那件事,才找到了真正的竞争对手。

提出者Clayton Christensen · Bob Moesta
来源1990 年代哈佛研究 · 2016《Competing Against Luck》
适合阶段产品定义期 · 转型期 · 竞品分析
使用时长深度访谈 1–2 周 · 分析 1–2 天
下载 Skill

什么时候该用它?

JTBD 最适合需要重新审视「谁是我们的竞争对手」和「为什么用户选择我们」的场景。当按用户属性细分无法解释增长或流失时,改用「任务」视角往往能带来意想不到的洞察。

🔍
发现非预期竞争对手
用任务视角重新定义竞争格局,发现「不做」或「用其他方式做」才是真正的对手。
📉
停滞增长分析
当 DAU 和收入停滞不前,JTBD 访谈能揭示用户「雇佣」你的产品完成的真实任务是否已改变。
🌏
新市场进入
进入新地区或新客户群前,识别当地用户正在用什么方式完成同样的任务,找到切入点。
💰
定价策略
理解用户把你的产品和什么放在一起对比,才能制定出用户愿意接受的价格锚点。
⚖️
功能取舍判断
当 Roadmap 争议激烈时,回到「哪些功能服务于核心任务」这一问题,帮助做出取舍。
✍️
营销文案优化
用任务语言而非产品特性语言写文案,让用户立刻感受到「这个产品是为我准备的」。

一个核心任务,五个维度

JTBD 框架的核心是识别用户要完成的「Job」——围绕这个核心任务,延伸出功能性、情感性、社交性三类任务维度,以及制约完成任务的阻力因素和衡量任务完成的成功指标。

用户要完成的
Job
功能性任务
Functional
情感性任务
Emotional
阻力因素
Constraints
成功指标
Success Metrics
社交性任务
Social
对比维度
传统视角
JTBD 视角
产品描述
功能特性清单(更快、更便宜)
用户能完成什么任务,情境是什么
竞争对手定义
同品类产品(同类 App)
所有能完成同一任务的方式(含「不做」)
用户细分方式
人口属性(年龄、性别、地域)
任务场景与情境(什么时候、为什么雇佣)
创新方向
改进现有功能,基于竞品对比
帮助用户更好地完成任务,发现未被满足的任务

从哈佛研究到硅谷主流方法论

JTBD 理论诞生于 Clayton Christensen 的创新研究,经过 Bob Moesta 的实践完善,最终通过《Competing Against Luck》走向全球产品界。奶昔研究是其最广为人知的经典案例。

1990s
Christensen 哈佛研究萌芽
Clayton Christensen 在哈佛商学院研究颠覆式创新时,逐渐发现传统产品-市场细分无法解释创新为何成功或失败,开始探索「用户任务」作为分析框架。
2003
《创新者的解答》深化理论
Christensen 与 Michael Raynor 合著出版,书中进一步发展了「雇佣产品完成任务」的概念,首次系统提出 Jobs-to-be-Done 的分析框架。
2007
Bob Moesta 奶昔研究经典案例
Bob Moesta 与 Christensen 合作研究麦当劳奶昔销量问题。通过 JTBD 访谈发现:消费者在早晨「雇佣」奶昔完成的任务是「在无聊的通勤中有件事情可以做」,而非「满足甜食需求」。这一案例成为 JTBD 最广泛引用的示范。
2016
《Competing Against Luck》出版
Christensen 等人正式出版 JTBD 理论专著,系统阐述理论框架与实践方法,迅速成为产品经理和创业者必读书目,JTBD 正式进入主流产品方法论体系。
2020
成为硅谷产品方法论主流
JTBD 被 Intercom、Basecamp、Amplitude 等顶级产品公司广泛采用,成为产品面试、PRD 写作、用户研究的标准框架之一。Bob Moesta 创立 The ReWired Group 专注 JTBD 咨询实践。

Intercom 重新定义「客服软件」的竞争边界

Intercom 早期被定位为「实时聊天软件」,增长陷入瓶颈。联合创始人 Des Traynor 运用 JTBD 框架,重新审视用户「雇佣」Intercom 完成的真正任务,发现了一个颠覆性洞察:真正的竞争对手不是 Zendesk,而是用户自己写的 Python 脚本。

Intercom
客户沟通平台 · JTBD 框架驱动的竞争重定位
2016
核心任务陈述 · Job Statement
我们的用户增长到需要管理客户关系时
我想要 在正确的时机向正确的用户发送精准消息
这样我就能 减少客户流失,提升用户价值
推力 Push — 驱动用户寻找解决方案
手动发邮件效率极低,无法个性化
用户行为数据散落在各处无法利用
工程师要为每个通知需求单独写脚本
拉力 Pull — 新解决方案的吸引力
基于用户行为触发自动消息
无需工程师介入,产品/运营可自助
数据与消息在同一平台,闭环分析
阻力 Anxiety — 切换顾虑
迁移现有客服历史记录
团队学习新工具的成本
担心自动消息变成「骚扰」
用户「雇佣」的替代方案分布 · Competing Solutions Map
自写 Python 脚本
45%
Mailchimp 批量邮件
28%
Zendesk 手动客服
18%
无解决方案
9%
关键洞察 · Key Insight
Intercom 发现自己最强劲的竞争对手是用户自己写的代码——这意味着用户愿意付出极高成本完成这个任务,也意味着真正的 WTP(支付意愿)远高于市场定价。重新定位后,Intercom 将定价提高 3 倍,增长反而加速。

五步识别真实任务

JTBD 研究的核心是访谈,而且是特殊的「切换访谈」——重点询问用户最近一次开始用或停止用某个产品时发生了什么,从行为变化的情境中发现真实任务。

01
识别用户情境
问「在什么情况下你开始使用/停止使用我们的产品?」找到促发行为改变的情境触发点。
02
发现驱动动机
追问「是什么让你在那个时候决定做改变?」找到推动(Push)和拉动(Pull)力量。
03
明确期望结果
询问用户「你期望通过这个产品达到什么?」区分功能性、情感性和社交性三类任务目标。
04
找出阻碍因素
问「是什么让你犹豫或曾经阻止你?」识别阻力(Anxiety)和习惯(Habit)这两种反力。
05
定义成功标准
询问「你怎么知道这个任务完成得好?」建立用户视角的成功指标,指导产品功能设计。
✓ 这样做
聚焦用户的行为转变时刻,用「切换访谈」挖掘真实动机
区分功能性、情感性、社交性三类任务,不要只看功能层
用任务语言重新描述产品定位和竞争格局
和团队共同做「任务画布」,让洞察变成共同语言
✗ 避免这些
把 JTBD 简单理解为「用户需求分析」,忽视情境和动机
只访谈现有用户,错过流失用户和从未使用者的洞察
用问卷替代深度访谈,任务驱动需要叙事性对话
以功能特性描述 Job 而非以结果和情境描述 Job

与这些工具搭配效果更好