job-story-mapper

Job Story 映射技能

别再写功能了，开始理解用户要完成的工作。这项技能将产品需求和用户访谈转化为精准的 Job Story，让团队专注于结果，而非产出。

Jobs-to-be-Done 基础知识

“工作”是客户在特定情境下试图取得的进展。人们购买的不是产品，而是雇用产品来完成一项工作。

每项工作都有三个维度：

• 功能性工作： 实际任务（“从 A 到 B”）
• 情感性工作： 他们想要的感受（“确信自己做出了正确选择”）
• 社会性工作： 他们希望别人如何看待自己（“在团队面前显得专业可靠”）

优秀的产品会兼顾这三个维度。大多数产品路线图却只关注功能性工作。

---

Job Story 格式

模板：

当 [情境/触发因素] 时，我想要 [动机/目标]，这样我就能 [预期结果]。

不是用户故事： 用户故事聚焦于角色和功能：“作为一名[角色]，我想要[功能]，这样就能[益处]。” Job Story 聚焦于情境和动机：“当[我处于这个特定情境]时，我想要[这种能力]，这样我就能[实现这个结果]。”

情境是最重要的部分。“当我正在进行冲刺，而 PM 要我汇报进展时”比“作为一名开发者”丰富得多。

---

映射流程

步骤 1：确定主要工作

用一句话说明：你的产品受雇完成的核心工作是什么？

“在[情境]下，帮助[用户类型][实现结果]。”

步骤 2：拆解工作步骤

主要工作包含哪些子任务？ （使用工作地图：定义 → 定位 → 准备 → 确认 → 执行 → 监控 → 修改 → 结束）

步骤 3：识别每个步骤的痛点

目前在哪些环节进展不顺？客户在哪些地方会采用变通办法？

步骤 4：针对每个痛点编写 Job Story

每个不同的“情境—动机”组合对应一则 Job Story。

步骤 5：映射产品机会

哪些 Job Story 尚未得到充分满足？哪些已有解决方案？你的差异化在哪里？

---

输出格式

Job Story 地图 — [产品/功能领域] — [日期]

核心工作陈述：

当[情境]时，[用户类型]希望[主要工作成果]，这样就能[最终目标]。

---

工作地图：

步骤	子工作	当前解决方案	痛点	是否未充分满足？
定义	[用户所做的事]	[所用工具/方法]	[挫折]	H/M/L
定位
准备
确认
执行
监控
修改
结束

---

Job Story（按未充分满足程度排序）：

Job Story 1 — [情境标签]

当[具体情境]时，我想要[动机]，这样我就能[结果]。

功能维度：[他们需要完成的事] 情感维度：[他们希望获得的感受] 社会维度：[他们希望别人如何看待自己]

当前变通办法：[他们目前的做法] 痛点强度：[高 / 中 / 低] 发生频率：[这种情境出现的频率] 产品机会：[我们可以构建什么来解决这个问题]

---

对每个主要 Job Story 重复以上步骤。

机会评分： 为每则 Job Story 评分：

• 对客户的重要性（1–10）
• 对当前解决方案的满意度（1–10）
• 机会分数 = 重要性 + max(重要性 – 满意度, 0)
• 优先处理：机会分数 > 10

---

深入材料

这项技能附带支持文件——如果这些文件可用，请使用：

• references/situation-mining.md — 情境挖掘——“当……”就是整个方法。在生成输出时应用该方法；此文件包含了上述方法摘要中被压缩的校准方式和判断要点。
• templates/job-story-canvas.md — 可填写的交付成果模板，内含质量检查项。用户想亲自填写文档，而不是让你生成时，请提供此模板。

评分标准（0–40）

交付前，请为此技能的任何输出评分；32 分及以上才达到可交付质量。

维度	0	5	10
情境具体性	“当……时”描述的是角色或泛泛的诉求（“作为一个想要管理工作的人”）	情境提到了任务，但没有具体时刻——缺少触发因素、时间或情绪背景	每个情境都是具体且容易识别的时刻（“晚上 11 点，租客给我发短信”），让动机不言自明
维度完整性	只映射了功能性任务；情感和社交字段为空或缺失	三个字段都已填写，但情感和社交条目只是用表达感受的词语重述功能性任务	功能、情感和社交维度各自包含不同内容，且至少有一个非功能性维度影响机会分析
替代方案依据	没有找出当前的替代方案；任务脱离了客户当下的做法	提到了替代方案，却把它们当作无关紧要的细节——没有从中得出任何推断	每个高机会的工作故事都指出其替代方案，并将其视为任务价值的证据（投入的时间、支付的费用、容忍的延迟）
评分与优先级纪律	没有机会评分，或未依据重要性／满意度输入凭空打分	分数计算正确，却将其直接视为开发顺序——未检查可行性或战略契合度	展示的算术过程一致，临界分数不会向上取整；产品路线图无法实现的高分项会被标记为战略问题，而非直接排入待办

质量检查

• 工作故事使用“当……时 / 我想要…… / 以便……”格式（而非用户故事格式）
• 情境具体（不是“作为一个用户”——而是真实时刻或触发因素）
• 涵盖所有三个维度：功能、情感、社交
• 为每个工作故事计算机会分数
• 为每个高机会故事找出当前的替代方案
• 产品机会与“开发该功能”有所区别（它关注的是结果）

必要输入

如果用户未提供，请向其询问以下信息：

• 要映射的产品或功能领域（例如：引导流程、结账、仪表盘）
• 用户类型或角色画像（我们要为谁映射待完成的任务？）
• 素材来源（用户访谈记录、支持工单、探索研究发现，或根据记忆描述）
• 范围（完整的产品任务地图，还是单个功能领域）

反模式

• 不要编写描述功能而非情境与动机组合的工作故事
• 不要跳过社交和情感维度——只映射功能性任务会错失最站得住脚的差异化机会
• 不要将情境定义得过于宽泛（“作为一个想要管理工作的人”）——情境必须是具体时刻或触发因素
• 不要混淆机会评分与优先级——高机会分数仍需评估可行性和战略契合度
• 不要在未找出当前替代方案的情况下制作任务地图——替代方案揭示了这项任务对客户的价值

指南

• 绝不要为功能编写工作故事；应围绕让该功能有价值的情境来写
• 如果无法识别情境，就说明你还不了解这项任务——回到用户研究
• 社交和情感任务更难挖掘，但往往最能形成有力的差异化优势
• 建议与工程团队分享工作故事——理解“为什么”能帮助他们做出更好的技术决策