← 全部文章
2 / 5
bobqiushao
← 返回文章列表
第 2 篇 · 共 5 篇

第六篇 · JTBD 任务理论——它讲清了什么,又在哪些品类里水土不服

⚠️ 本文中出现的任何数据、案例、品牌、人名均为示意性虚构,用于说明方法论,与任何真实项目无关。

第五篇里我提了一句“理论介绍会在后续逐步深挖”。这就是第一篇。

JTBD 是最容易被乙方拿来当通用模板的理论之一——它语感好、可移植性强、画起来像有结构。但也正因为它太好用,它被用在了大量不适合用它的地方。这篇文章要做的事是把 JTBD 的真正贡献和它的失效边界拆清楚——它能给你的判断它做不到的事情它该出现在哪个研究阶段、以及错配的具体代价


一、JTBD 到底讲了什么

JTBD(Jobs-to-be-Done,任务理论)的核心命题只有一句话:

用户不是在买你的产品,他们是雇佣你的产品来完成某个任务(job)。

这句话听起来朴素得像废话,但它的解释力在一个具体场景里能立刻显现。

克里斯坦森(已经死翘翘的哈佛商学院教授)讲过一个被引用了几千遍的奶昔案例。某快餐连锁想提升奶昔销量,做了大量市场细分研究——按年龄、性别、收入切分用户,问“你希望奶昔更甜一点还是更稀一点”,改了几版配方,销量纹丝不动。后来研究员换了个方法,只问一个问题:“你买奶昔的时候,是想用它干什么?”

答案出乎意料。早高峰买奶昔的中年男性,他们雇佣奶昔做的“任务”不是“喝一杯好喝的甜品”,而是“在 30 分钟的单调通勤里,用一只手就能持续打发时间,且不会撒到衣服上、不会饿肚子到中午”。竞争对手不是其他奶昔,是甜甜圈(掉渣)、香蕉(吃太快)、咖啡(没饱腹感)。

一旦把任务定义清楚,产品优化方向立刻不一样了——奶昔应该更稠(吸的时间更长)、加水果颗粒(增加打发时间的有趣性)、用更高的纸杯(放进汽车杯架不晃)。

这就是 JTBD 的真正贡献——它把你从“产品属性的优化”拉到“任务完成度的优化”。前者是无穷无尽的细节战(甜度、温度、价格、包装),后者是一个能让所有决策对齐的北极星。

JTBD 的完整表述通常是这样的语法结构:

When [情境] , I want to [任务] , so I can [更深层的目的] 。

继续用奶昔例子:When 我在早高峰开车通勤,I want to 用一只手就能持续打发时间且不饿肚子,so I can 把这段无聊又疲惫的通勤变得不那么难熬。

这个结构有三个被低估的设计:

第一,“When”把场景钉死了。同一个用户在不同场景下雇佣不同产品做不同任务。早高峰他雇佣奶昔,下午陪小孩他可能雇佣一份冰淇淋圣代——同一个奶昔产品,在这个场景下竞品完全不同(他陪小孩的时候奶昔是不合适的,因为小孩坐不住吸十分钟)。

第二,“so I can”把功能层翻到了情感层。“打发时间”是功能,“让通勤不那么难熬”是情感。功能层容易被竞品复制,情感层是你的真正护城河。

第三,它强迫你用用户的语言而不是产品的语言。“奶昔是高蛋白早餐饮品”是产品语言,“我需要一个不会撒、有饱腹感的早高峰陪伴”是用户语言。前者是营销词,后者是 JTBD。

JTBD 的三层语法结构 展示 JTBD 的 When 情境层、I want to 任务层、so I can 目的层如何形成完整的用户任务描述 WHEN · 情境 我在早高峰开车通勤 I WANT TO · 任务 用一只手就能持续打发时间,且不会饿肚子到中午 SO I CAN · 目的 把这段无聊又疲惫的通勤变得不那么难熬 场景 功能 情感 三层合起来才是完整的 JTBD · 少了任何一层都是片面的

二、JTBD 能给你的几个具体判断

理论是骨架,要看它在真实决策里能给你什么。

第一,重新定义竞品边界。

按品类定义,奶昔的竞品是其他奶昔。按 JTBD 定义,奶昔的竞品是甜甜圈、香蕉、咖啡、抖音短视频——任何能在早高峰单调通勤里被一只手雇佣的东西。

这件事对老板的决策影响是直接的。你以为你在和星巴克竞争,实际上你在和“用户掏出手机刷短视频”竞争——这两种竞争对手需要完全不同的产品策略和投放策略。

第二,识别“高满意度但低增长”的陷阱。

很多产品有这样一个吊诡的状态:用户满意度调研得分很高(NPS 50+),但销售增长停滞。传统市场细分会建议你“投入更多到现有用户的复购上”,JTBD 会让你问一个不一样的问题:“用户雇佣你完成的任务,是不是已经被另一种方式更好地完成了?”

一个虚构例子:某传统纸质日历(假设是 2020 年前后),用户对它评价很高——“印刷精美”“有手感”“有仪式感”。但它的真正任务是“帮我记日程”,而这个任务已经被手机日历完成得更好(自动同步、提醒、跨设备)。用户的“满意度”是对产品属性的满意,但他们正在用更少的频率雇佣这个产品。

JTBD 让你看见这种“被悄悄替代”的过程,而不是被高满意度数据麻痹。

第三,给产品决策一个可被检验的框架。

老板的产品决策经常会陷入“加什么不加什么”的争吵——加这个功能客户会用吗?加那个会不会增加复杂度?JTBD 提供的检验标准是:这个功能是不是在帮助用户更好地完成他雇佣这个产品要做的那个任务?

任何一个加进来的功能,如果回答不了这个问题,就有可能是产品经理的自我表达,不是用户需要。


三、它做不到的事情

JTBD 是一个工具,不是一种世界观。它有它擅长的地方,也有它结构性的盲点。这一节比上一节更重要——因为讲到这一步,JTBD 看起来已经像万能钥匙了,而万能钥匙在用户研究里都是最危险的东西。

做不到的一:它默认“任务是单一的、可被语言化的”——但现实里大量任务是多重叠加且无法被语言化的。

JTBD 的语法结构假设用户买一个产品是为了完成“一个”任务。但很多消费决策同时承担着多重任务,而且这些任务之间互相矛盾。

举个虚构例子。某人买一辆中等价位 SUV,他声称的 job 是“接送小孩上下学比较安全”,但实际驱动他选择某个具体车型的可能还有“开出去不能显得太寒酸”(社交任务)、“老婆喜欢这个颜色”(家庭关系任务)、“我哥们也买的这款”(身份认同任务)。如果你只用 JTBD 框架问他,他给你的答案大概率是第一条——因为这是“合理化”过的、能被说出口的、不会显得肤浅的版本。

后面三个任务他自己未必意识到,即使意识到也不太愿意说。JTBD 的语法本身在引导用户给出“听起来合理”的答案,而不是“真实驱动决策”的答案。

这件事在做 To C 大件消费品研究的时候特别严重。研究员拿着 JTBD 提纲去访谈,问“您当时购买这款车的时候,主要是想完成什么任务”——你能拿到的回答 90% 是表层的、合理化过的、不会让自己显得肤浅的答案。真正驱动决策的情感和社交因素,JTBD 的访谈语法接不住。

做不到的二:在情感+一次性消费+强社交的品类里,“job”的定义本身有歧义。

JTBD 在 SaaS 类产品上验证得非常好。原因是 SaaS 产品的任务通常清晰、可重复、有客观完成度(发票开出来了 / 客户记录被存下来了 / 报告生成了)。

但在一些品类里,“job”这个概念本身就是模糊的:

  • 婚礼策划。 用户雇佣婚礼策划公司做的“任务”是什么?是“办一场婚礼”吗?——但这场婚礼的成功标准是什么?是新郎新娘开心,还是双方父母满意,还是宾客觉得有面子,还是朋友圈发出来好看?这四个标准互相冲突,任何一个 job 描述都覆盖不了全部。
  • 奢侈品。 用户买一个 LV 包,他完成的 job 是“装东西”?这显然是笑话。是“显示身份”?但你直接问他他不会承认。是“奖励自己最近的辛苦”?这个说法他更愿意接受,但它是事后合理化,不是事前的真实驱动。
  • 婚介服务。 用户购买婚介服务,job 是“找到结婚对象”?但很多用户购买后并不真的接受任何介绍——他购买的可能是“让自己看起来在努力”“让父母不再催”“有一个可以告诉别人我在认真考虑的事情”。这些不是 job,这些是身份性消费。

这一类品类的共同特征是:强情感、强社交、一次性或低频、消费动机里有大量无法被语言化的部分。JTBD 在这类品类里仍然可以用作辅助框架,但如果你只用它,你拿到的大概率是用户的“对外说法”,不是“真实驱动”。

做不到的三:JTBD 假设用户知道自己要完成什么任务——但很多任务用户自己也没意识到。

回到第二篇文章的“四类隐性知识”概念。用户的真实任务里,有相当一部分用户自己说不清——他知道自己买了某个东西之后心里舒服了,但他说不清为什么舒服;他知道自己拒绝了某个方案,但他说不清拒绝的真正理由。

JTBD 的访谈语法默认“用户能说出自己的任务”,但这件事经常不成立。一个有经验的研究员能从用户的犹豫、停顿、说错又改口里识别出“真任务”,但这种识别能力不在 JTBD 框架里——它在研究员对人性的敏感度里。

做不到的四:它给你一个“完成度的优化方向”,但不告诉你“市场容量”。

JTBD 能让你看清“用户在雇佣什么”、“竞品边界在哪”,但它不能告诉你“这个任务的总市场有多大”、“愿意为这个任务付费的人有多少”。后面这些是定量研究的事——你用 JTBD 找到了正确的方向,但具体投入多少资源还是需要画像层面的数据支撑。

这又回到第五篇的核心判断:画像和人设是两件事,JTBD 是 persona 层的工具,不是画像层的工具。把它当画像用,会发现它“看起来洞察很深但没法做投流人群包”。


四、JTBD 该出现在哪个研究阶段

按第五篇的四阶段模型(H0 假设生成 / Sprint 0 探索期 / Phase 1 主流程 / Phase 2-3 深化期),JTBD 的最佳位置是这样的:

JTBD 在四阶段研究模型中的位置 展示 JTBD 方法在 H0 假设、Sprint 0、Phase 1、Phase 2-3 四个阶段的使用强度和角色变化 时间 H0 假设生成 主力工具 Sprint 0 探索 访谈骨架 Phase 1 主流程 分析框架 Phase 2-3 深化 Persona 字段 强度高 强度低 JTBD 的使用强度随阶段变化 H0 和 Sprint 0 是主力期 · Phase 1 后退到辅助 JTBD 使用强度 研究阶段

H0 假设生成阶段。 JTBD 是这一阶段的主力工具之一。研究员基于行业经验和品类常识,先用 JTBD 的语法草拟出“用户可能在雇佣这个产品完成的几个候选任务”,作为后续访谈和数据采集的探针。这一阶段的 JTBD 是“待证伪的假设”,不是结论。

Sprint 0 探索期。 JTBD 用作访谈提纲的骨架——但要注意它的失效边界。在 SaaS、工具型产品里,JTBD 提纲可以贯穿大部分访谈;在情感型、一次性消费、强社交品类里,JTBD 只能用作一部分提纲,必须搭配其他工具(决策三角拆解、心理学模型、场景化提问)。

Phase 1 主流程数据采集阶段。 JTBD 退到辅助位置。这一阶段的主力是一手访谈 + 内部数据 + 定量问卷。JTBD 在这个阶段的作用是“分析框架”——拿到大量原始访谈记录后,用 JTBD 的 When / I want to / so I can 结构把数据归类。

Phase 2-3 深化与人设成形阶段。 JTBD 作为 persona 的核心字段之一被写进交付物。每个 persona 都应该有 1-3 个核心 JTBD 描述——但不要超过 3 个,否则就是研究员在堆砌细节。

最常见的错配:把 JTBD 当成贯穿全程的方法论,从 H0 用到交付。 这种错配的代价是——你拿到的所有数据都是被 JTBD 语法过滤过的,失去了那些不在“任务-语法”里的真实驱动(情感、社交、身份)。研究员会觉得自己框架很自洽,但老板拿着报告做决策时,会发现“这里面的用户不像活人”。


五、错配的具体代价

错配 JTBD 的具体代价,按品类不同,长得不一样。

SaaS 产品(JTBD 的舒适区)——错配概率低,但仍然存在。最常见的错配是把 JTBD 当成功能优先级的唯一裁判,忽略了 B2B 决策里的“采购者 vs 使用者”分离。一个使用者的 job 是“我能更快做出报表”,但采购者(可能是 CTO)的 job 是“我能给老板交差并证明 IT 部门的价值”。两个 job 都真实,但产品决策必须同时回应。错配代价:产品做得使用者爱用,但采购者不愿意买单。

To C 大件消费品(车、家装、定制等)——错配概率中高。常见错配是用 JTBD 提纲做主流程访谈,忽略了“决策三角”(决策者 / 付款人 / 使用者)的分离。一个家装项目,妻子的 job 是“我每天回家心情好”,丈夫的 job 是“装修后我老婆少抱怨我”,老人的 job 是“小孩有地方玩”。三个 job 互相纠缠,JTBD 框架本身无法处理这种纠缠。错配代价:交付的 persona 是“全能型 persona”——一个虚构人物身上挂着三个互相冲突的 job,老板拿到说“这看起来不像一个真人,像三个人的合成”。

情感型一次性消费(婚礼、葬礼、毕业典礼相关服务等)——错配概率高。这一类品类里,JTBD 的语法本身就接不住真实驱动。错配代价是最直接的:研究员交付了一份“看起来逻辑自洽”的 JTBD 报告,但报告里的所有“任务”都是用户的对外说法,真实驱动一个也没识别出来。老板按报告做的产品决策,在市场上彻底失灵——他做的不是“用户雇佣他要做的事”,而是“用户能说出口的那个说法”。

奢侈品 / 身份性消费——错配概率最高。这一类品类里 JTBD 几乎是个误导。错配代价是研究员花了大半年时间研究“用户为什么买 LV 包”,最后给出的结论是“用户希望有一个能搭配多种场合、品质有保障、设计经典的包”——这套结论拿去给任何品牌都成立,因为它把“身份性消费”的真实驱动彻底过滤掉了。老板拿这份报告会觉得“全是正确的废话”。


六、从业务动作倒推——什么时候该用 JTBD

第五篇的核心判断是“从业务动作倒推研究方法”。具体到 JTBD,匹配关系大致是这样的:

  • 产品功能优先级排序 → JTBD 是合适的主力工具,特别是在 SaaS、工具类产品。
  • 新功能立项 / 砍掉无效功能 → JTBD 能给你一个清晰的判断标准,问“这个功能是不是在帮助用户更好地完成核心 job”。
  • 重新定义竞品 → JTBD 是几乎不可替代的工具,它能让你看见“被悄悄替代”。
  • 品牌定位 / 营销文案 → JTBD 能给你“用户语言”作为文案素材,但不能给你“情感诉求”——后者需要心理学模型(下下篇会写)。
  • 投流买量人群包 → JTBD 不适合,这是画像层的工作。
  • 奢侈品 / 身份性消费的市场策略 → JTBD 几乎不适合,需要换用其他理论。

最实操的判断方式: 在决定用 JTBD 之前,先问自己一个问题——“我的用户在购买这个产品时,他能不能用一两句话说出他想完成的任务,而且他说的那句话基本就是真实驱动?” 如果能,JTBD 是好工具。如果不能,JTBD 只能用作辅助。


七、收尾——JTBD 是望远镜,不是望远镜里的星星

第五篇里有一句话:“理论是望远镜,不是望远镜里的星星。”JTBD 在所有理论里最容易被错当成“星星”——因为它的结构太漂亮、它给的答案太干脆、它让研究员看起来很有方法。

但真正决定用户决策的那些东西——情感、身份、关系、模糊的恐惧、说不出口的渴望——大部分不在 JTBD 的语法里。JTBD 帮你看一部分世界,但它看不到的那部分世界,需要其他理论(Kano、旅程图、心理学模型)来补——这就是接下来三篇要讲的事。

最后说一件务实的事:如果你是甲方,乙方给你的方案里 JTBD 出现得特别多、所有用户洞察都是 When / I want to / so I can 句式——你要警惕。 这种方案大概率是研究员在用框架掩盖对你具体业务的不熟悉。一个真正懂的乙方,会告诉你 JTBD 在你这个品类里的失效边界在哪、要用什么补——而不是把 JTBD 当万能钥匙端给你。


下一篇:Kano 模型——为什么“魅力型需求”是研究员最容易自我感动的陷阱。