正在读取本机记录…

重要产品判断◷ 70 分钟

JTBD、用户故事与痛点分析

从用户任务、动机和阻碍描述真正的进展。

学完你能做到

用自己的话解释“JTBD、用户故事与痛点分析”及其核心术语。
在真实 AI 产品场景中识别何时应该使用本课方法。
完成一份可沉淀进“访谈提纲、需求洞察报告与 MVP 范围说明”阶段任务的实践产出。

前置与关联课程

完成阶段 0 的能力检查，或先预览相关基础课

前置 · 问卷、观察、数据与桌面调研关联 · 需求真实性、频率、强度与付费意愿

REAL SCENE

先从一个真实场景开始

用户说想要“一个更聪明的学习助手”，团队写成“作为用户，我想和 AI 对话”。这句话没有说明用户在什么情况下为什么需要帮助，也无法判断聊天是否是最佳方式。JTBD、用户故事和痛点分析分别从进展、交互价值与阻碍角度补全需求。

PLAIN EXPLANATION

说人话：它到底是什么？

JTBD 描述用户在特定情境下想取得的进展，包含功能、情绪和社会动机；用户故事用角色—目标—价值表达一项可交付需求；痛点则是阻碍进展的具体摩擦、成本或风险。三者不是互斥模板：先用 JTBD 理解为什么，再用痛点定位障碍，最后用用户故事进入设计与开发，并以验收标准防止歧义。

写出完整 JTBD

“当我准备面试却只有 30 分钟时，我想快速找到薄弱重点并完成一次自测，从而带着确定感进入面试。”这里包含情境、动机、期望结果和情绪进展，聊天只是候选方案。

情境触发真实需求
进展而非产品功能
同时考虑功能与情绪结果

把痛点量化

痛点不能只写“麻烦”。需要记录出现节点、频率、持续时间、失败后果和用户采取的绕路。痛点强度决定优先级，也帮助区分核心阻碍与轻微不便。

摩擦发生在哪一步
用户付出什么代价
为什么现有替代仍被使用

转成可验收故事

用户故事保持价值视角，但不能代替规则。每个故事还要补前置条件、正常流程、边界和验收标准。大型故事需要按用户价值纵向切分，而不是按前端后端横向切分。

角色必须具体
目标可观察
价值与验收直接关联

JTBD 描述进展，不在句子里预设聊天、Agent 等方案。

痛点要有节点、频率、代价和当前绕路证据。

用户故事必须补充规则、边界和可测试验收。

#JTBD #用户故事 #痛点

KEY POINT

这节课最重要的结论

核心重点

好需求同时包含情境、动机、期望结果和当前阻碍。

为什么重要: 这决定了从真实用户问题出发，判断需求价值并确定 MVP 范围时，团队是否拥有一致、可验证的判断标准。
适用边界: 当问题目标、数据来源或失败成本发生变化时，不要机械套用；先重新确认假设和风险等级。

EXAMPLES

正确案例与常见反例

✓ 正确做法

团队发现用户在面试前需要快速判断薄弱点，痛点是课程太长且没有反馈。用户故事写为“作为两天后面试的转型者，我想用 15 分钟完成 RAG 场景测验，以便决定今晚复习什么”，并补充题量、反馈、未通过和重试规则。

× 常见误区

团队把所有需求写成“作为用户，我想使用 AI 功能，以便提高效率”，既没有具体角色、情境和价值，也没有验收标准。开发完成聊天框后才发现用户真正想要的是结构化测验和错误解释。

和工程师这样沟通

“用户任务不是“和 AI 聊天”，而是在面试前 15 分钟识别薄弱点。聊天、测验或知识卡都可以比较。首个用户故事先做 5 题测验和错误解释，验收按任务完成与推荐准确性定义。”

HANDS-ON

必做实操任务

本节产出：“访谈提纲、需求洞察报告与 MVP 范围说明”阶段任务中的《JTBD、用户故事与痛点分析》一页实践卡

步骤 1选择一个模糊功能请求，将它改写为包含情境、动机和结果的 JTBD。
步骤 2沿用户流程列出三个痛点，并分别记录频率、代价和当前绕路。
步骤 3将最高优先痛点写成具体用户故事，避免在目标中预设实现。
步骤 4为故事补充三个正常验收、两个边界验收和一个护栏指标。

○

实践完成度 0/4

实践结果会自动保存在本机，并进入项目工坊的任务来源。

JTBD 到用户故事转换表

当____（情境）时，
我想要____（动机/任务），
从而____（功能进展），
并感到/被认为____（情绪/社会进展）。

痛点节点：____
频率：____　时间/金钱/风险代价：____
当前绕路：____　仍使用原因：____

作为____（具体角色），
我想要____（可观察目标），
以便____（用户价值）。
前置条件：____
正常验收：1. ____ 2. ____ 3. ____
边界验收：1. ____ 2. ____
护栏指标：____

CHECKLIST

产品经理工作检查表

JTBD 是否描述用户进展而不是产品功能？是否同时包含触发情境、功能结果和情绪/社会动机？痛点是否有频率、代价和替代方案证据？用户故事的角色、目标和价值是否具体？故事是否补充规则、边界与可测试验收标准？

INTERVIEW

常见面试题

JTBD 和用户故事有什么区别，如何一起使用？

展开参考回答

JTBD 用于发现层，描述用户在特定情境下追求的功能、情绪与社会进展，不预设方案；用户故事用于交付层，把具体角色、目标和价值转成可排期需求。中间用痛点证据定位阻碍，再为故事补规则与验收，形成从洞察到开发的链路。

RECAP & FURTHER READING

重点回顾、延伸阅读与下一步

一句话回顾好需求同时包含情境、动机、期望结果和当前阻碍。

1
围绕“JTBD、用户故事与痛点分析”继续阅读：选择一篇真实用户研究或产品决策复盘，识别其中的问题证据、方案取舍与验证闭环。
2
用“JTBD、用户故事、痛点”作为检索词，分别写下一条定义、一条适用边界和一个反例。
3
对照本课正确案例与反例，寻找一个公开案例并记录其中可复用的判断与不能照搬的条件。

关联术语