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

const duration = '约 1.5 小时'

内容来源:Datawhale Easy-Vibe,许可协议:CC BY-NC-SA 4.0

<script setup> const duration = '约 <strong>1.5 小时</strong>' </script>

<a id="top-jtbd"></a>

本章导读

Duration: duration | Core output: 1 条更像真实需求的 JTBD 句子 | Expected output: 能把模糊点子收成一个更具体的用户场景和 MVP 方向

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

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

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

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

你将学到以下内容

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

<a id="jtbd-what"></a>

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

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

<a id="jtbd-formula"></a>

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 条用户反馈,就可以把它们丢给模型,让它按以下结构总结:

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

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

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

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

我想做一个 [你的产品想法]。
请不要直接给我功能列表,而是用 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 能帮你把注意力拉回到真正重要的地方:用户为什么需要你,以及你到底在帮他完成什么进展。

<a id="jtbd-ai"></a>

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

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

你可以这样用:

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

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

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

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

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

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

可能的 JTBD 方向:

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

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

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

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

12.2 让 AI 帮你整理访谈原话

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

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

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

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

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

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

AI 可能输出:

整理结果:

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

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

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

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

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

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

一个简单输入可以是:

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

AI 可能输出:

常见痛点整理:

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

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

12.4 让 AI 充当“反方”

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

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

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

📚 Assignments

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

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

延伸阅读