先问一个很实在的问题你上次给产品加新功能到底是用户真的想要还是你觉得“有了这个功能用户就会觉得专业”这两者之间的差别往往就是产品活一年还是活五年的差别。而“待办任务”理论Jobs-to-be-done, JTBD解决的就是这件事——它逼你放弃对产品特性的自嗨式想象换位到“用户雇你的产品来干什么活”的视角重新理解市场。我第一次真正弄懂JTBD不是看论文是被一个乙方客户“教育”的。那时候我们给一款记账App做改版调研问卷回收了上千份用户写得最多的需求是“增加信用卡账单导入功能”。我们咬牙接了几家银行的接口上线后次留居然没涨。后来做了几组深访才发现用户真正的“工作”不是“导入账单”而是“每周花十分钟搞清楚自己这个月到底有没有超支”——他们要的是“确定性”和“安全感”不是“自动化”。那一刻我才意识到我们一直在做“更好的产品特性”却根本没理解用户雇佣产品的目的。这活儿从一开始就拧了。这篇文章我想把JTBD这套思考模型彻底拆开。从底层逻辑开始讲清楚它为什么会成为现代产品研究和品牌定位的重要工具再配合具体案例、访谈话术、任务陈述的写法以及我们在实操中踩过的坑尽量做到既能当入门科普也能当团队内部分享的素材用。1. 内容整体设计与思路拆解1.1 JTBD解决的是产品定义的根本性问题说句直白的市面上大多数产品方法论都在解决同一个问题——“怎么做”而JTBD是少数专门盯着“做什么”和“为什么做”的方法。它的出发点是一句话消费者购买产品或服务的真正动机不是想要产品本身而是想让生活发生某种变化完成某个“工作”。举个例子用户买电钻他不是想要一个钻头他是想要墙上有一个孔。买4寸的芝士蛋糕不是因为嘴馋是要在闺蜜面前扮演一个“会照顾人”的朋友。买跑步机不是热爱跑步是要在朋友圈建立“自律人设”的同时弥补白天久坐的愧疚感。产品只是完成这些“工作”的一个工具、一种手段。这套逻辑的关键在于它改变了产品竞争的边界。如果你认为自己是“卖电钻的”你会跟另一个卖电钻的比转速、比噪音、比价格。但如果你知道自己是被雇佣来“在墙上打孔”的你的竞争对手就不只是别的电钻还有挂钩、免打孔置物架、双面胶甚至直接喊物业来帮忙。这个视角的转换会让你的市场空间突然变大也会让你避免陷入同质化内卷。更重要的是JTBD要求你从“用户这个人”转向“用户所处的场景”。同一款产品在不同场景下被“雇佣”的理由可能完全不同。可口可乐在工地是“解渴提神”在烤肉店是“解油腻”在电影院是“看电影的仪式感搭档”。如果你只盯着“口感好”这一条特性做文章就会丢掉大半的市场机会。1.2 为什么传统用户画像撑不起高质量决策聊JTBD之前必须先聊聊它经常拿来对比的“用户画像”Persona。很多产品团队在立项时先起一个年龄、城市、收入、兴趣标签的虚拟人设比如“28岁的一线城市女白领月入两万喜欢健身和咖啡”。看着很具体但落到决策层面你会发现它给不了你任何方向的指引。问题出在哪儿呢用户画像回答的是“用户是谁”而不是“用户要完成什么工作”。同样一个28岁的女白领早上上班路上需要一杯咖啡提神晚上下班可能在考虑要不要去健身房周末可能在纠结怎么拒绝相亲对象。她的行为完全由不同的“任务”驱动而不是由一个人设驱动。用画像做决策很容易得出“年轻人就是喜欢简约风”这种标签化结论最后做出来的东西平庸无奇。JTBD把分析单元从“人”换成了“情境任务”这是一个根本性的升维。你不再问“我们的用户是谁”而是问“在什么情况下用户会产生需要被完成的工作”。所以JTBD的访谈对象经常是跨人群的只要情境相同一个程序员和一个开餐馆的老板娘可能在“给朋友推荐午饭吃什么”这件事上有着高度一致的行为逻辑。这种跨人群的一致性恰恰是规模化产品设计最需要的东西。1.3 JTBD框架下“功能需求”的重新定位如果你习惯了写需求文档一定有这种经历用户反馈“想要一个深色模式”产品经理就把它排进迭代设计师做一版暗色UI开发忙活两周上线。但JTBD会逼你追问一句“深色模式”帮助用户完成了什么工作真实答案可能是“半夜失眠时刷手机不想被亮光刺激得更加清醒”。那这时候你该做的也许不是做深色模式而是做一个“夜间安眠模式”把蓝光、推送频率、动态效果全部联动调整。这不是咬文嚼字而是在提示一个核心方法将用户表述的“解决方案需求”翻译为“背后想完成的工作”。用户的表达是表层的他们的目标才是深层的。JTBD教你听“需求”更要听“动机”。我在实际工作中养成的一个习惯是需求评审时每个功能必须能回答“用户雇佣它完成什么工作”。如果答不上来这个需求的优先级就应该被降级。逻辑很简单如果一个功能不能被明确归因到某个任务上它就极可能是在解决我们自己想象中的问题而不是真实世界里的问题。2. 核心细节解析与实操要点2.1 理解JTBD的四个关键层次JTBD不是一个单一概念而是一套可以拆解成多个层次的分析框架。如果只是停留在“用户想完成什么工作”这个口号上很难落到实操。我通常会从四个层次去理解和应用。第一个层次是“核心任务”Core Job也就是用户真正想达成的功能性结果。比如“把客厅墙壁上的画挂好”是核心任务。它是中立的、去情感化的描述不涉及用户用的是什么产品。第二个层次是“情感任务”Emotional Job指用户在完成核心任务时希望感受到的情绪状态。挂画这个动作用户可能希望之后拥有“家里很温馨”的满足感如果挂完发现有气泡还会产生“自己动手能力不行”的挫败感。产品设计如果能照顾到这些情绪就找到了建立情感连接的切入点。第三个层次是“消费链任务”指完成任务背后的一系列关联工作。挂画这件事往前推要先量墙面尺寸、选画框、买钉子往后推要定期擦拭、换季时可能还要换画。每一个关联步骤都可能产生新的产品机会。第四个层次是“消费时刻”Consumption Chain Moments指用户在任务的各个时间节点上与产品、服务、场景发生的具体触点。这些触点既可以是痛点也可以是情绪放大器它们往往是创新机会最密集的区域。这四个层次合在一起才能完整回答“用户雇佣产品做什么”这个问题。只谈核心任务容易把JTBD做成干巴巴的功能清单只谈情绪又会失去务实感。2.2 JTBD经典句式任务陈述的标准化写法市面上有几种不同的JTBD任务陈述句式我在实操中觉得最稳妥、最不容易跑偏的是下面这种结构当情境我想动机以便预期结果。拆开来看就是三个组成部分的特点明确情境触发点、行动动机或动作、期望达成的结果。比如“当我下班回家瘫在沙发上不想动时我想通过手机App点一份很快能送到且有惊喜感的晚饭以便我既满足口腹之欲又不用决策。”这个句式里最有价值的部分是“以便”后面的内容它揭示的是用户内心的预期结果这个结果通常不只是功能上的还包含社交、情绪、身份层面的诉求。写任务陈述的过程中如果发现“以便”后面写不出来或者写出来很空洞说明你对用户任务的理解还不到位需要回头补访谈。另一种对照写法是“从X到Y”句式。比如“从面对一堆食材不知道怎么下手到轻松做出一桌招待朋友的晚餐”。这种写法的优势是动态、有张力能让你看到转变前后的状态对比非常适合用来做价值主张的沟通展示但并不适合直接作为内部任务陈述参考。两种写法可以结合使用前者做分析后者做表达。2.3 从“需求”到“任务”的翻译练习很多第一次接触JTBD的人最大的障碍不是听不懂而是在实际工作中不会用。从用户原话到任务陈述中间需要经过一次“翻译”。我举一个自己实操过的例子——当时团队在打磨一款面向自由职业者的记账工具。用户反馈的原始需求是“希望开发票更方便”这在当时看来就是个很明确的功能需求。我们用JTBD走了一遍后重新定义为“当我月底要催客户付款时我需要快速生成一张看起来专业的发票以便让客户觉得我是个正规团队从而尽快打款到账。”这么一改整个产品的重心就变了。用户要的不是“开发票更快”而是“让催款这件事不尴尬且高效”。“看起来专业”可能是模板样式、页脚信息合规度、批量生成能力“尽快打款”可能需要在开发票的同时附带账单周期提醒和催款措辞辅助。你看一个任务定义的变化直接影响了产品功能的优先级排序。做这种翻译练习时有一个判断标准任务陈述里的“以便”部分必须是用户真实在意、真实感受到的收益而不是产品团队拍脑袋赋予的。谨慎的做法是每次写完任务陈述都拿去给真实用户验证问一句“这个描述像不像你当时的情况”如果用户点头说明你翻译对了如果不点头就回去重来。3. 实操过程与核心环节实现3.1 上一堂JTBD用户访谈课5个核心问题就够了市面上的JTBD访谈指南往往又长又复杂不是所有人都能背下来。我实战多年后的结论是只要围绕着“过去某次具体经历”来问基础问题控制在5个之内就能挖到极高质量的信息。回忆时刻“上一次你意识到需要【完成某个任务】是什么时候当时发生了什么”探索尝试“你当时怎么解决这个问题的试过哪些产品、方法”挖掘动机“为什么你会选择用这个方法而不是其他方法你最担心的是什么”使用过程细节“从头到尾跟我讲讲你当时是怎么用它完成的中间有没有卡住的地方”复盘感受“用完之后你感觉怎么样有没有达到你心里的预期”这5个问题里最容易丢掉的是第一个。但恰恰是它决定了访谈的成败。很多人一上来就问“你想要什么样的记账App”这等于把用户从具体场景拽回抽象评价得到的答案全是“方便、好用、不卡”这种水词。先让用户回到具体的时间、地点、事件里之后的追问才有根。做一个友好提醒访谈过程中要忍住“给建议”的冲动。用户说“我找了好几个软件都不好用”不要立刻接“那你需要什么功能”。这里的关键是追问“不好用的时候你心情怎么样”“那你最后是怎么解决的”这几个问题能帮你看清竞争替代方案和情绪卡点。3.2 访谈后如何把原始记录提炼为任务清单访谈结束以后最考验功力的不是说用户说了什么而是从成堆的原始记录里提炼出有指导意义的任务清单。我自己的步骤通常是三步。第一步把重点信息记录在“用户原话场景复述”的卡片上一张卡片只记一个完整的任务故事。记录时尽量保留口语原文因为后面的分析需要回到原话里去验证判断而不是看加工过的总结。第二步找出故事里的标准结构元素情境、动机、障碍、策略、结果。这个阶段不需要给任何评价做完表格你会发现不同用户之间的相似度远比想象中高很多障碍在不同故事里反复出现。第三步开始压缩和归类。把相似的任务合并成一个上位任务用前面提到的“当…我想…以便…”句式重写。重写以后需要验证一下合并后的任务是否保持了对用户行为的解释力如果合并后的任务解释不了某个用户的行为选择说明它拆得还不够细。做完这三步你会得到一份任务清单。这个清单的用途是产品决策的基础工具而不是让团队自我感动的工作报告。每次排优先级时都应该拿出来对照看这个新功能到底在服务清单里的哪个任务。3.3 用JTBD做竞品分析别再罗列功能开始拆解任务传统的竞品分析一直有个毛病就是把竞品的功能列表横向摆开比谁的功能多、谁的颜色好看、谁的价格低。在JTBD视角下这种分析基本没有参考价值。因为用户不关心你有多少功能他们只关心自己的任务有没有被完成得更好。用JTBD做竞品分析建议走三个步骤第一步各挑一个核心任务场景。比如做外卖App的分析可以选“一个人加班到晚上9点想快速吃顿热饭”这个场景。第二步把竞品在这个场景下完成任务的全流程拆解出来。不是拆功能是拆用户的操作路径、等待时间、情绪变化、决策成本。记录用户在什么节点犹豫了、什么节点放弃了、什么节点骂了一句“什么破玩意”。第三步比较每个竞品在“完成任务”这件事上的效率、稳定性和体验。这个分析做完你很容易发现竞争的关键差异点在哪里。有的产品赢在“快”有的赢在“可预期”有的赢在“没得选时也能用”。这个分析的产出往往很出人意料。我曾经在分析两款招聘App时发现用户最在意的根本不是职位匹配准确率而是“投完简历之后能不能让我心里有底”。一款产品因为多了“简历被查看提醒”在这个任务上完爆对方尽管它的匹配算法明显弱一些。3.4 从任务洞察到产品决策的落地路径拿到任务清单以后怎么把它转化成产品决策是JTBD从“认知工具”走向“决策工具”的关键一跃。我把这个转化过程拆成五步每一步都有明确输出物。第一步是任务优先级排序与团队共识达成。不是所有任务都同等重要选择标准是任务出现的频率、强度以及用户对现状的不满程度。这个排序必须让核心团队坐在一起讨论保证每个人的心智模型是同一张图。第二步是把任务拆解为“必须做好的功能要素”。每个任务背后都有一串“必须至少做到什么”的底线需求这些需求不一定是最高级的功能但一旦缺失用户就会觉得产品不好用。比如完成“快速决策午饭吃什么”这个任务“菜品图片清楚”“送达时间可预期”可能就比“能定制辣度”更重要。第三步是判断现有产品在完成任务上的优势与缺口。把现有产品放回每个任务的全流程里走一遍标记出哪个环节表现优秀、哪个环节会让任务中断。这一步通常会产生一个“机会清单”每个机会都要对应到具体的任务、具体的事件。第四步是定义本阶段产品要支持的核心任务组合。不要试图服务所有任务那是资源陷阱要选择一个或两个任务组合做到极致。比如滴滴专注“尽快打到车”的任务组合时它的核心指标是应答率和接驾时长而专注“安全地到目的地”时就围绕行程分享、紧急联系人、录音保护做了功能。第五步是建立任务完成度的衡量指标。这一步最容易被忽视。每个任务都要设置可以被度量的结果指标比如任务完成率、任务所需时间、用户自报告任务达成满意度。没有指标的任务洞察只是文字游戏有了指标才能形成“洞察-决策-验证”的闭环。4. 常见问题与排查技巧实录4.1 别把“用户说的”当“用户要的”——访谈中的陷阱JTBD访谈里最常见的坑是用户说的内容天然带“解决方案导向”。你问用户“你解决这个问题最头疼的是什么”他大概率会告诉你“我想要一个能自动同步的软件”而不是“我需要跨设备无缝切换别让我在工作和手机之间反复折腾”。前者是方案后者才是任务。如果调研人员没有追问“自动同步之后你能得到什么”就会带着一个伪需求回团队。另一个坑是过度依赖口碑最佳的“超级用户”。超级用户对你的产品很熟悉他们的反馈往往高度细节化但这些细节充满了既有产品的使用惯性不一定能代表新用户或非用户的真实任务。做JTBD访谈时要刻意混入“尝试过但放弃的用户”和“竞争者产品用户”因为他们对“任务完成得不好”有更切身的体验。还有一个很隐蔽的陷阱是访谈者自身对任务有了预设判断之后会不自觉地引导用户顺着自己的假设说。比如你已经觉得用户需要“更快的配送”你就会问“配送慢的时候你是不是很着急”用户顺着说是的但这个“着急”可能远不如“餐到了发现洒了”那么刺骨。保持开放的关键技巧是用“你当时是怎么做的”来代替“你是不是觉得”让用户回忆行为而非评价态度。4.2 任务定义过大或过小的取舍标准任务定义得太大会失去指导意义比如“我的任务是让用户生活更美好”。这种话放在价值观宣传上没问题放在产品决策上等于没说。任务定义得太小又会被具体实现方式锁死比如“我想打一个直径8毫米的孔”就明显窄了它把“挂画”这个结果弄丢了。我自己用来校准任务定义颗粒度的标准有三个。第一是“是否稳定”好的任务在一段时间内不会过时挂画的需求一百年前和一百年后都在而“买一盒图钉”“用电动螺丝刀”则会很快过时。第二是“能否解释行为”任务陈述要能解释“为什么用户选择了A产品而不是B产品”如果解释不了说明定义得不够本质。第三是“能否指导决策”任务陈述拆出的功能优先级必须和用户真实行为一致。如果拿捏不好大小可以试着用“结果轮”来校准从核心结果出发向外写出用户关注的各个维度比如功能结果、情绪结果、社交结果、成本结果。任务陈述至少要覆盖到三个维度的结果才算是完整的任务而不是一个功能的翻版。4.3 团队内部对JTBD应用的抱怨与缓解“JTBD就是访谈一下用户然后写一句话听完等于没听”是团队培训后最常见的抱怨。这不能怪方法没用而是因为很多人把JTBD当成了立竿见影的“咒语”以为念一句“用户要的是完成工作”产品就能自动变好。实际上JTBD是一个分析框架它提供的是思考路径不是答案本身。一种更实际的做法是别急着把“任务”上升到公司战略层面先把一个小团队、一个模块作为试点。选定一个任务场景快速做5组访谈用任务清单驱动一次版本迭代把用户反馈结果可视化出来。等大家真的看到“一个任务洞察改变了上线优先级”之后这种理论才会变成团队的内置语言。在推进过程中还会遇到一种情况资深的产品经理会觉得“我早就知道用户要的是什么”在这种前提下JTBD访谈会被视为昂贵的走流程。这时候我不建议辩论而是建议直接用高保真原型做一次A/B对照一个版本围绕原有功能逻辑做优化一个版本围绕任务逻辑做优化让数据说话。数据不会偏向谁它只会告诉你用户到底在哪个版本里更顺利地完成了自己的“工作”。4.4 常见误区速查表误区问题表现修正方向把用户画像当成任务“我们的用户是28岁女性白领”换成“在什么情境下需要完成什么工作”把功能需求直接当方案用户说“要个夜间模式”就去做先追问“夜间模式帮你完成什么”任务定义过于抽象“提高用户幸福感”收敛到具体情境、具体事件、具体结果只访谈付费用户样本全是忠实用户缺少替代品用户加入流失用户、竞品用户、潜在用户缺少衡量指标任务洞察停留在文档里为每个任务设置计量的完成度指标拿JTBD否定所有已有功能“既然用户没提这个功能就应该砍掉”JTBD是优先级排序工具不是功能删除工具5. 从JTBD到长期产品竞争力的延伸思考5.1 任务的生命周期与品类演变的启示很多产品团队把这些方法看作一套静态分析工具做完一个任务清单就能管一年。但实际上用户的任务有演变周期经济环境、新技术和文化风向都会让任务的表达方式、完成标准和满意阈值发生变化。举个例子十年前一个人要“保管自己的纪念照片”任务的核心是“别弄丢、别损坏”所以云盘、移动硬盘都是合理方案。到今天很多人要的已经变成“让我有意思的照片被重要的人看到”于是相册App开始加入拼图、模版、甚至私密共享功能。核心任务从“存储”迁移到了“表达和连接”。谁先感知到这个任务迁移谁就能在下一波产品竞赛中占据先机。从这个角度看JTBD的价值不只是在当下的版本迭代中提供决策依据它更是一个雷达工具。通过定期回访用户观察他们在完成同一任务时选择方案的变化你就能捕捉到需求的迁移方向提前调整产品定位而不是等到数据下滑到难以挽回时才开始行动。5.2 JTBD与其他方法论的协同画像、场景、体验地图一个常见的误解是有了JTBD就不需要用户画像或者反之。从我实操的角度看它们解决的是不同层面的问题应该组合使用而不是互相替代。用户画像回答“为谁做”它的价值在于统一团队对目标人群的具象认知特别是涉及品牌调性、沟通风格和渠道选择时画像仍然管用。JTBD回答“做什么”它负责刻画具体的完成场景和任务逻辑是功能优先级排序时最重要的依据。用户体验地图则把“人”和“任务”串到一条时间轴上给出完整的服务流程视角适合用来做体验诊断和跨部门协作。一个典型的产品定义项目中我会先用画像框定目标人群的边界再用JTBD访谈挖出核心任务清单然后用体验地图把任务落到具体触点和流程上最后再用JTBD的任务陈述做功能优先级排序。这样整个流程有全景也有人物有战略方向也有落地细节才能真正形成一套打得出去的产品策略。5.3 个人与组织的思考习惯养成JTBD真正发挥威力不只是因为它能用于某个具体的调研项目而在于它可以把团队乃至整个组织的思维方式训练成“任务导向型”。当每个成员在开需求评审会时本能地先问“这个需求帮助用户完成什么任务”很多无谓的争论会自然消失。我在实践中还发现把JTBD应用到自己日常学习和职业规划上也很好用。你可以把自己当作“产品”把雇主或者目标公司当作“用户”他们的任务不是“招聘一个程序员”而是“在三个月内把数据中台建设完成并且不给团队留坑”。如果你的能力积累和表达方式都围绕这个任务展开面试的成功率和对工作的满意度都会显著提升。养成这种习惯的唯一方式是反复练习。不用等到有正式项目才开始日常看到任何一个爆款产品、一条广告、一个让你心动的消费决策都可以停下来问一句“用户雇佣它完成什么工作为什么是‘它’而不是别的东西”坚持两个月后你会在很多产品决策上比普通人看得更深半层。6. 一些实践者的额外叮嘱尽管前面写了很多实操层面的方法但我还是想单独留一小节聊聊那些没法被流程所涵盖的经验。毕竟JTBD不是一个可以被当作“公式”去套的东西它的边界感决定了你是拿着它做真洞察还是拿着它做个汇报。第一件事关于访谈样本量。网上经常有人问“JTBD访谈到底要做多少个样本才够”这个问题的正确答案是“取决于你的团队接下来要冒多大的风险”。需求探索阶段我们通常做8到15个深度访谈就能看到非常明显的任务模式而如果要为一个重大战略投资做决策建议分两轮每轮不少于20个样本。但无论样本量多少都别忘了样本的多样性跨人群、跨场景、跨竞品的反例样本永远比多访谈两个同类用户更有价值。第二件事关于何时放弃JTBD。你可能会意外但JTBD并不是解决所有产品问题的万能钥匙。如果你们的市场已经高度成熟用户对任务的表达极其一致你不需要再做什么探索性的任务访谈而是应该把精力投入到执行效率、交付质量、成本控制上。比如做纯净水用户的核心任务“解渴补水”已经明确得不能再明确你再去访谈“你喝水是为了什么”纯粹是浪费预算。这种时候JTBD反而会遮蔽你对供应链和渠道的关注。第三件事关于用JTBD推导品牌沟通策略。很多人以为JTBD是产品经理的专属工具但实际上它对新品牌定位和广告沟通同样有效。当你清晰地知道“用户雇佣产品完成的情绪任务”是什么你的广告语就不能再停留在参数和性能层面而应该直接唤起那个任务场景和任务结果。比如一个卖高端户外手表的品牌如果了解到用户雇它的任务核心是“进入户外圈子后获得身份认同”那广告画面就应该聚焦在人群归属和认同瞬间而不是防水深度和气压计精度。最后想提醒的是工具好坏只取决于使用者的判断力。JTBD的价值不在于它能替你做出正确决策而在于它能逼你把决策依据从“我觉得”“大家都这么做”升级为“用户在那个真实情境里想要完成的实事”。当你习惯了这种思考方式后再回看你会发现自己对产品、对用户、甚至对很多商业现象的理解都发生了难以逆转的变化。这种认知层面的更新才是这套理论带给从业者真正的长期回报。
