user-story-mapping

user-story-mapping 技能概览

user-story-mapping 技能可以帮你把一个粗糙的产品想法，整理成结构清晰的 story map：活动、步骤、任务，以及发布切片。它最适合在你还在争论 backlog 优先级、范围或 MVP 切分线之前，先拉出一个人人都能对齐的用户旅程视图。

这个技能适合做什么

在产品管理场景里，user-story-mapping 更适合回答的不是“我们要写哪些 ticket？”，而是“用户究竟是怎么一步步走完整个体验的？”它适用于早期探索、发布规划、流程重构和 backlog 成形。

适合谁安装

如果你经常需要让产品、设计和工程围绕一条基于旅程的计划达成一致，就值得安装 user-story-mapping 技能。它非常适合 PM、产品运营、设计师，以及需要根据目标用户、场景或结果来起草 story map 的 AI agent。

它有什么不同

和通用 prompt 不同，这个技能是围绕 Jeff Patton 的 story mapping 结构设计的，强调从左到右的叙事展开，以及纵向的发布优先级划分。这样更容易暴露缺口、梳理价值顺序，并把 MVP 的必需项和后续增强项分开。

如何使用 user-story-mapping 技能

安装并找到源文件

对于 user-story-mapping install，使用：

npx skills add deanpeters/Product-Manager-Skills --skill user-story-mapping

然后先读 skills/user-story-mapping/SKILL.md，再看 template.md 和 examples/sample.md。这三个文件分别提供核心结构、输出形态和一个具体示例，足够你直接上手，而不用自己倒推这个 repo 的写法。

输入要给对

这个技能最适合吃“真实产品场景”，而不是空泛目标。一个好的 prompt 应该明确写出用户群、persona、目标、约束，以及你想要映射的用户旅程。

好的输入：

• “梳理一个面向首次使用的小型 SaaS 发票管理自由职业用户的 onboarding 旅程。”
• “为一个以 mobile-first 使用和尽量少创建账号为主要约束的 checkout flow 创建 story map。”
• “为一款 Project Management 软件生成 user-story-mapping 输出，面向团队负责人审批任务并跟踪进度。”

不太好的输入：

• “给我的 app 做一个 story map。”
• “规划产品 backlog。”
• “优化用户旅程。”

更容易出好结果的建议流程

先定 persona 和结果，再要 backbone，然后是步骤、任务，最后再给一个初步的发布切片。如果你跳过前两层，最后常常会变成功能列表，而不是旅程地图。

一个实用的 prompt 结构：

1. 目标用户和细分人群
2. 核心待办任务（job-to-be-done）
3. 范围边界和约束
4. 期望输出格式
5. 如果已知，发布意图

先检查这些仓库路径

对于 user-story-mapping usage，重点看：

• SKILL.md：方法和预期结构
• template.md：标准输出骨架
• examples/sample.md：你要对齐的详细程度

如果你只是想快速判断是否适合，这几个文件已经足够让你看出这个技能是否匹配你的规划方式。

user-story-mapping 技能 FAQ

这只适合 Product Management 吗？

不是。user-story-mapping for Project Management 也很有用，尤其是在 PMO、delivery lead 或跨职能团队需要从用户视角，而不是从任务看板视角，去理解顺序、依赖和发布范围时。

它和普通 prompt 有什么区别？

普通 prompt 往往只会产出一个功能清单。而 user-story-mapping 技能会把输出推成一个结构化旅程：顶部是活动，下面是步骤，再往下是任务或发布切片。如果你需要的是对齐，而不只是头脑风暴，这种结构就是它的核心价值。

新手也能用吗？

可以，只要你能描述清楚一个用户和一个目标就行。你不需要精通 story mapping 也能使用它，但你必须把旅程描述明确。对于新手来说，最好的结果通常来自“一个 persona + 一个主要场景”，而不是多个互相竞争的用例。

什么时候不该用它？

如果你需要的是纯 backlog、技术实现方案，或者带有详细验收标准的 feature spec，就不建议用 user-story-mapping。它最擅长的是探索和优先级排序，而不是替代交付文档。

如何改进 user-story-mapping 技能

让模型看到更清晰的旅程

最好的 user-story-mapping 输出，来自一条单一、具体的用户路径。如果你想要更好的结果，就把起点触发、终点和上下文说清楚。比如说“从注册到第一次成功完成任务”，而不是只说“onboarding”。

补充会改变地图的约束

如果产品真的有约束，就尽早写出来：只能在 mobile 上使用、受监管流程、低信任用户、多级审批，或 onboarding 时间有限。这些细节会直接影响哪些活动应该放进 backbone，哪些任务应该放进 MVP 切片。

要求输出发布切片，而不只是结构

一张好的 story map 应该能看出先发什么、后发什么。使用 user-story-mapping 指南时，要明确要求一个 MVP 线，再加一到两个后续切片，这样输出才真正能帮助优先级排序，而不只是做记录。

从缺口迭代，不要只改措辞

第一版出来后，重点检查有没有漏掉用户步骤、隐藏依赖，或者某些任务其实应该归到别的活动下面。如果地图看起来过于偏功能，要求它围绕用户意图重写；如果太抽象，就让它在最有风险的步骤下补更多 task 级细节。