Skip to content

用 Jobs to Be Done 找到用户真正想完成的事

本章导读

🎯本章学习目标
JTBD用户需求产品思维需求洞察

很多人刚开始做产品时,最容易犯的一个错误是把注意力全部放在“我要做什么功能”上。看别人有智能分类,你也想加;看别人有自动总结,你也想接;看别人做了 Agent、多模态、工作流,你也觉得自己不能少。

但现实里,用户很少是因为“这个功能名字很酷”才决定用一个产品。他们更多是在某个具体时刻,想把一件事情推进下去,于是临时“雇用”了一个工具、一个服务,甚至一个人,来帮自己完成这一步。

这正是 Jobs to Be Done(JTBD) 这套方法想提醒我们的事情:用户不是在购买功能本身,而是在雇用某种解决方案,帮助自己完成一个进展。

本篇文章会用尽量直白的语言,带你从零理解 JTBD,并把它变成你做 AI 应用时能直接拿来用的分析工具。

⏱️
预计耗时
1.5 小时
📦
预期产出
1 条更像真实需求的 JTBD 句子
能把模糊点子收成一个更具体的用户场景和 MVP 方向

最小 SOP

目的:看完后,你会更清楚怎样把一个模糊点子,收成一句真正有用户场景的需求,而不是脑子里只有一堆功能名。

行动项:写 1 句模糊点子,找 3 个潜在用户聊“最近一次怎么处理”,再整理成 1 条 JTBD 句子。

结果:你会得到一个更清楚的需求假设,知道第一版该先解决什么。

关键词跳转JTBD 是什么 · 一句话公式 · AI 怎么帮你

你将学到以下内容

  1. 什么是 Jobs to Be Done,为什么它比“功能脑暴”更接近真实需求
  2. 如何区分“用户说想要的功能”和“用户真正想完成的事”
  3. 怎样用一套简单模板,把一个模糊点子拆成场景、触发、障碍和成功标准
  4. 如何把 JTBD 用在 AI 产品、访谈提问和提示词整理里

1. 什么是 Jobs to Be Done

Jobs to Be Done 常被简称为 JTBD。它背后的核心想法,和 Clayton Christensen 团队推广的那句经典表达有关:用户会“雇用”某个产品来完成一件事。

这里的“事”,不是待办清单里那种表面动作,而是用户希望自己状态发生的一种 进展 。比如:

  • 不是“我要一个 AI 纪要工具”,而是“我想在会后 10 分钟内把重点、待办和责任人整理清楚,别再靠回忆补笔记”
  • 不是“我要一个记账 App”,而是“我想知道钱到底花去哪了,好让我月底别再焦虑”
  • 不是“我要一个简历优化器”,而是“我想更有把握地投出一份像样的简历,不想每次投递都怀疑自己写得太差”

所以,JTBD 关注的不是产品长什么样,而是用户为什么在这个时刻需要它。

这也是为什么很多看似不同的产品,实际上在竞争同一个 job。用户想“在上班路上不那么无聊”,可雇用的对象可能是短视频、播客、游戏、聊天,甚至打瞌睡。用户想“快速搞懂一份很长的 PDF”,可雇用的对象可能是 AI 摘要工具、实习生、同事、自己硬着头皮看,或者干脆先不看。

一旦你用这种视角看问题,你会发现自己真正的竞争对手,往往并不只是“另一个长得像你的 App”,而是 用户当前所有可接受的替代方案

2. JTBD 和用户画像、功能列表有什么不同

很多新手刚开始做需求分析时,会先写用户画像:25 岁,女生,一线城市,白领,喜欢效率工具,愿意尝试新产品。这样的信息不能说完全没用,但它通常 不够解释一个人为什么会在此刻采取行动。

JTBD 更关心的是下面这些问题:

  • 他是在什么场景下决定找解决方案的
  • 当时到底卡住了什么
  • 他想把什么事情推进到下一步
  • 现在正在用什么笨办法撑着
  • 如果事情解决得好,什么结果会让他觉得“值了”

也就是说,用户画像更像“这个人大概是谁”,JTBD 更像“这个人现在到底想完成什么”。

同样地,功能列表也容易把人带偏。用户说“我想要导出 Word”“我想要 AI 改写”“我想要语音输入”,这些都只是表层表达。JTBD 会继续往下追问:

  • 为什么你现在需要导出 Word,而不是 PDF?
  • 你想改写,是因为文风太差,还是因为需要适配不同对象?
  • 你想语音输入,是因为懒得打字,还是因为你经常在走路、开车、开会后马上记录?

很多时候,功能只是 job 的一种临时翻译 。如果你只收集功能,很容易把产品做成“用户说什么就堆什么”;如果你能看见背后的 job,才更有机会做出真正顺手、真正有竞争力的方案。

3. 一个零基础也能理解的例子

先不要急着想复杂的 AI 产品,我们从一个生活例子开始。

假设有人早上出门前总来不及吃早餐,于是经常在地铁口买一个三明治和咖啡。表面上看,他“购买”的是早餐;但如果用 JTBD 看,他真正想完成的事可能是:

  • 在赶时间的早晨,用最省脑力的方式解决一顿饭
  • 让自己在到公司前不至于饿得发慌
  • 不因为吃早餐耽误通勤节奏

这时候,用户雇用的不是“某个固定品牌的三明治”,而是一个能帮他把早晨顺利推进下去的解决方案。如果隔壁便利店更快、更近、更稳定,他可能立刻换掉原来的选择。

把这个逻辑搬到 AI 产品里就更明显了。

比如你想做一个“AI 会议纪要工具”。如果只停在功能层面,你会很容易开始想:

  • 要不要支持上传音频
  • 要不要接入说话人分离
  • 要不要导出 Markdown
  • 要不要自动生成待办

这些都没错,但还不够。用 JTBD 再问一层,用户真正想完成的可能是:

  • 我想在会后 10 分钟内,把讨论结果同步给没参会的人
  • 我想把待办、责任人和截止时间提干净,别让团队靠记忆协作
  • 我想减少重复整理会议内容的时间,把精力留给决策和推进

一旦 job 被说清楚,很多功能优先级就会自动浮出来。第一版最重要的也许不是“支持 12 种导出格式”,而是:

  • 纪要结构要足够清楚
  • 待办提取要稳定
  • 分享链接要方便
  • 输出结果要让人敢直接转发给团队

这就是 JTBD 的价值:它能帮助你从“我要堆哪些能力”回到“我要帮用户推进什么进展”。

4. 一个好用的 JTBD 模板

如果你是零基础,可以先不要试图把 JTBD 想得很学术。先抓住最实用的 5 个要素就够了。

4.1 场景

用户是在什么时刻、什么环境里想起这个产品的?

  • 是开完会以后
  • 是老板临时要材料的时候
  • 是晚上准备投简历的时候
  • 是月底发现钱又不够花的时候

没有场景的需求,通常都还不够真实。

4.2 触发

是什么让他决定立刻找解决方案?

  • 被长文档压住,不知道从哪开始看
  • 明天要交材料,今天才发现格式乱七八糟
  • 刚被领导追问进度,意识到自己没有整理清楚
  • 想坚持记录,但手写、复制、整理都太麻烦

触发点往往带着情绪。这个情绪很重要,因为它决定了用户为什么会在这一刻产生行动。

4.3 想完成的进展

他不只是想“做个动作”,而是想把自己推进到什么新状态?

  • 从混乱到清楚
  • 从焦虑到安心
  • 从拖延到启动
  • 从低效到顺手
  • 从说不明白到能直接交付

这一步里,“进展”这个词非常关键。因为很多人真正买的不是工具,而是 状态变化

4.4 当前替代方案

现在没有你的产品时,他怎么做?

  • 手工复制粘贴
  • 用 Excel 或备忘录硬撑
  • 找同事帮忙
  • 拖着不做
  • 在几个工具之间来回切

谁是替代方案,谁就是你的真实竞争环境。

4.5 成功标准

事情怎样才算真的被解决?

  • 10 分钟内得到可分享的结果
  • 不需要二次大改就能发给别人
  • 不容易漏项、出错、忘事
  • 第一次用就知道下一步怎么走

如果你连“用户怎么判断值不值”都说不清,那这个方向大概率还没有收敛好。

5. 直接套用的一句话公式

当你想梳理一个产品方向时,可以先套这个非常实用的句式:

当 __________ 的时候,我想要 __________,以便于 __________。
现在我只能通过 __________ 来勉强完成这件事。

比如:

当我开完一场信息量很大的项目会时,我想要快速得到一份带待办、责任人和截止时间的纪要,以便于我能马上同步团队并推进执行。
现在我只能靠自己回忆、翻聊天记录和手工整理来勉强完成这件事。

再比如:

当我准备投递一个新岗位时,我想要快速把已有经历改写成更贴合岗位的版本,以便于我能更有把握地投出一份像样的简历。
现在我只能反复复制旧简历、手改措辞,改到最后越来越不确定。

如果你能把一句话写到这种清晰程度,后面的页面设计、提示词设计、功能优先级判断,都会容易很多。

6. 做 AI 产品时,特别要看的三层 job

很多 AI 产品在功能演示时看上去很强,但真正上线之后却留不住人,常见原因是只解决了表层动作,没有解决更深的 job。

你可以把一个 job 粗略分成三层来看:

6.1 功能层

最表面的任务是什么?

  • 总结文档
  • 改写文案
  • 提取待办
  • 生成图片

这是用户嘴上最容易说出来的一层。

6.2 情绪层

用户希望减少什么不舒服,或者获得什么感受?

  • 不想那么慌
  • 不想显得不专业
  • 不想每次都从零开始
  • 想更有掌控感

很多付费意愿,实际上和情绪层关系很大。

6.3 社会层

用户希望在别人眼里变成什么样?

  • 看起来更靠谱
  • 在团队里更有组织能力
  • 在客户面前更专业
  • 在社交平台上更会表达

如果你只做功能层,产品很容易被替代;如果你同时理解了情绪层和社会层,你就更容易找到真正有黏性的价值。

7. 用 JTBD 反过来筛产品方向

有时候不是你已经有产品,而是你手里有 3 到 5 个点子,不知道做哪个。这时 JTBD 很适合拿来做筛选。

你可以拿着每个点子,分别问自己 5 个问题:

  1. 这个点子对应的场景是不是足够具体?
  2. 用户现在是否已经在用某种笨办法解决?
  3. 这个 job 的痛感是否足够强,或者足够高频?
  4. 如果我做好了,用户会不会明显感受到“状态变好了”?
  5. 第一版能不能只围绕这个 job 的关键一步,做出一个很小但有用的版本?

如果一个方向讲到最后还是只能说“感觉挺有意思”,却说不清触发、替代方案和成功标准,那它大概率还只是一个模糊灵感,不是一个成熟方向。

8. 可以直接拿去访谈用户的问题

很多人一做调研就问:“你想要什么功能?”这种问法很容易得到表面答案。

JTBD 更适合问下面这些问题:

  • 最近一次你遇到这个问题是什么时候?
  • 当时你在做什么,为什么会卡住?
  • 你最后是怎么解决的?
  • 这个过程里最烦、最慢、最不放心的地方是什么?
  • 如果有一个工具能帮你,什么结果会让你觉得真的有用?
  • 你试过哪些替代方法?为什么它们不够好?

这种问法有个好处:它会把对话拉回真实经历,而不是停留在想象中的偏好。

9. 用 AI 帮你做 JTBD 拆解

JTBD 本身不是 AI 发明的,但 AI 很适合帮你整理和提炼 JTBD。

比如你已经收集了 5 到 10 条用户反馈,就可以把它们丢给模型,让它按以下结构总结:

text
请你扮演产品研究助手。
我会给你一些用户原话,请你不要先给功能建议,
而是先按 Jobs to Be Done 的框架整理:

1. 用户处在什么场景
2. 触发他采取行动的事件是什么
3. 他真正想完成的进展是什么
4. 当前替代方案是什么
5. 他最在意的成功标准是什么
6. 这些反馈里反复出现的情绪词有哪些

最后,请把这些内容整理成 3 个最值得优先验证的 JTBD 假设。

如果你已经有一个点子,也可以让 AI 帮你做第一轮收敛:

text
我想做一个 [你的产品想法]。
请不要直接给我功能列表,而是用 Jobs to Be Done 方法帮我分析:

1. 这个产品可能服务哪些具体场景
2. 每个场景中用户想完成的核心 job 是什么
3. 现有替代方案有哪些
4. 哪个 job 最适合作为 MVP 的起点,为什么
5. 请把最终推荐的 job 写成一句清晰的 JTBD 句子

这样做的好处是,你不会一上来就被 AI 带去“脑暴 50 个功能”,而是先把方向讲清楚。

10. 新手最常见的 4 个误区

10.1 把 job 写成功能名

“AI 总结”“智能分类”“自动生成”都不是 job,它们只是可能的实现方式。

10.2 把人群写得很宽

“所有职场人”“所有学生”“所有创业者”通常都太泛。越泛,你越难看见真实场景。

10.3 只听用户说,不看用户怎么做

用户会描述自己想要什么,但他真正的优先级,常常藏在他现在如何凑合解决问题里。

10.4 一开始就想做完整平台

JTBD 的正确打开方式,通常不是“我来做一个包打天下的大平台”,而是先盯住一个场景里最关键的一步,把它做到非常顺手。

11. 小结

Jobs to Be Done 最有价值的地方,不是给你一个新名词,而是帮你换一个观察角度:不要只盯着产品功能,而要盯着用户想把什么事情推进到下一步。

当你开始反复问自己:

  • 用户是在什么场景下雇用这个产品的
  • 他到底卡在了哪里
  • 现在正用什么办法硬撑
  • 事情解决后,状态会发生什么变化

你会发现,很多原本模糊的点子一下子变清楚了,很多原本很花哨的功能也一下子没那么重要了。

做产品,尤其是做 AI 产品,最怕的是一开始就沉迷能力展示。JTBD 能帮你把注意力拉回到真正重要的地方:用户为什么需要你,以及你到底在帮他完成什么进展。

12. 如何利用 AI 帮你实践 JTBD

JTBD 不是 AI 发明的,但 AI 很适合在这套方法里当你的研究助手、整理助手和对照助手。关键是:让 AI 帮你整理和扩展,而不是替你臆测用户。

你可以这样用:

12.1 让 AI 帮你把模糊点子改写成 JTBD 假设

当你脑子里只有一句模糊描述,比如“我想做一个帮大学生找实习的工具”,可以先让 AI 帮你把它拆成几种可能的 job:

text
我现在有一个模糊产品点子:[你的点子]
请不要直接给我功能列表,而是用 Jobs to Be Done 的方式帮我分析:
1. 可能对应哪些具体场景
2. 每个场景里用户真正想完成的进展是什么
3. 当前替代方案可能是什么
4. 哪个 job 最适合先做 MVP
请最后把每个 job 写成一句清晰的 JTBD 句子。

你甚至可以把输入写得很小白:

text
我想做一个帮大学生找实习的东西。
我现在也说不清具体是做什么,你帮我想想用户到底想完成什么事。

AI 可能给出的有用输出会像这样:

text
可能的 JTBD 方向:

1. 当我第一次准备投实习时,我想快速知道应该先准备哪些材料,
以便我不要因为信息混乱一直拖着不投。

2. 当我看到一个实习岗位时,我想快速判断自己是否值得投,
以便我不要在不合适的岗位上浪费太多时间。

3. 当我开始投递时,我想把现有简历改成更贴合岗位的版本,
以便我能更快完成投递并提高通过率。

这种输出的价值在于,它会把你原本一句很泛的想法,拆成几个更接近真实场景的方向。

12.2 让 AI 帮你整理访谈原话

如果你已经做了几次用户访谈,可以把访谈记录交给 AI,让它帮你提炼反复出现的场景、触发点、替代方案和成功标准。

text
下面是 5 位用户的访谈原话。
请不要先给解决方案,而是按 JTBD 框架整理:
1. 用户处在什么场景
2. 触发他采取行动的事件是什么
3. 他真正想完成的进展是什么
4. 当前替代方案是什么
5. 他最在意的成功标准是什么
6. 哪些信息在多位用户中重复出现
最后整理成 3 条最值得优先验证的 JTBD 假设。

一个很简单的小白输入也可以这样写:

text
我问了 3 个人,他们大概是这样说的:

1. 每次要投实习我都得重新改简历,特别烦。
2. 我其实最怕的是不知道自己写得对不对。
3. 我现在会先找学长学姐帮我看,但每次都不好意思总麻烦别人。

你帮我整理一下,他们真正想完成的事情是什么。

AI 可能输出:

text
整理结果:

- 共同场景:准备投递实习前,需要处理简历
- 共同困难:不知道如何修改到“够好”
- 当前替代方案:找学长学姐帮看,自己反复修改
- 可能的 JTBD:
  当我准备投递实习时,我想更快判断简历是否已经达到可投递水平,
  以便我不要一直卡在“再改一改”而迟迟投不出去。

这种输出很有用,因为它帮你从零散原话里提炼出更像“需求”的东西。

12.3 让 AI 帮你做一轮轻量级网络调研

在你还没开始大规模访谈前,可以先让 AI 帮你做一些很轻的外部信息扫描,比如:

  • 公开论坛或社区里,大家是怎么抱怨这个问题的
  • 市面上已有产品主要在解决哪一层问题
  • 用户最常见的替代方案是什么
  • 常见评价里,大家最满意和最不满意的点是什么

这种调研不能代替真实用户访谈,但很适合作为 Discover 阶段的热身,帮你先建立问题地图。

一个简单输入可以是:

text
请你帮我查一查:
“大学生改简历、投实习时最常见的痛点是什么?”
优先看公开论坛、经验帖、求职社区里大家自己说的话。
帮我整理成 5 条最常见问题。

AI 可能输出:

text
常见痛点整理:

1. 不知道简历该写什么,经历太少
2. 不知道怎么针对不同岗位修改
3. 改了很多版,但始终不确定是否够好
4. 找不到可靠的人帮忙看
5. 投递流程复杂,容易拖延

这类输出不能当最终结论,但很适合帮你先决定要优先访谈哪类问题。

12.4 让 AI 充当“反方”

很多时候,我们会对自己的想法太有感情。你可以专门让 AI 扮演一个挑刺的人,逼你把问题说得更清楚:

text
请你扮演一个非常严格的产品研究顾问。
下面是我的 JTBD 假设:[你的假设]
请从以下角度批判它:
1. 这个场景是否过宽
2. 这个 job 是否写成了功能而不是真正进展
3. 替代方案是否太弱
4. 成功标准是否不够清楚
5. 这个假设最需要被验证的风险是什么

这样做的好处是,你能更快发现自己是在看需求,还是只是在看自己喜欢的方案。

📚 Assignments

请你根据上文内容,完成下列作业:

  1. 选一个你最近想做的产品点子,用一句 JTBD 公式把它写清楚
  2. 为这个点子补齐 5 个要素:场景、触发、进展、替代方案、成功标准
  3. 找 3 个潜在用户,至少问出一次“最近一次你遇到这个问题是什么时候”
  4. 把访谈原话交给 AI,整理成 3 条最值得优先验证的 JTBD 假设

延伸阅读