iDWong 在顾问团里的位置：本技能是
pm-advisory-board（顾问团总控）的成员之一（《User Story Mapping》方法论）。 通常由 board 路由进来或被拉进多专家评审会；也可被用户直接点名。 判断出结论后要产出交付物 → 回pm-master按单点路由或流程走，本技能不产出文档。
《User Story Mapping》 · 先画出整段旅程的骨架，再横切出能用的最小一版
什么时候用我
- 需求一堆但说不清全貌、PRD 像一张扁平清单 → 用【故事地图骨架】
- 要定 MVP / 第一个发布切什么 → 用【横切发布切片】
- 团队对"要做什么"理解不一致 → 用【共享理解优先于文档】
- 不适合：判断需求真假（见 pm-method-mom-test）、判断该不该做（见 pm-advisor-cagan / build-trap）。本书解决"已决定要做，如何结构化表达与切分"。
核心框架
框架 1：故事地图骨架（The Map，第 2、5 章）
适用场景：把零散需求组织成一个能一眼看懂的整体。
步骤：
- 沿"用户从头到尾做这件事"的时间线，横向排出大活动（backbone，脊柱）→ 例：注册 → 找商品 → 下单 → 收货
- 每个活动下纵向展开具体任务（user tasks），按细节向下排
- 从左到右读一遍 = 一个完整故事，检查有没有断裂/缺口
- 输出：一张二维地图（横轴=流程叙事顺序，纵轴=优先级/细节）
框架 2：横切发布切片（Slicing Releases，第 5、6 章）
适用场景：定义每一版发布做什么，尤其第一版。
步骤：
- 在地图上横向画线，切出"横跨所有活动都能走通"的最薄一层 → walking skeleton（能走路的骨架）
- 第一版只取每个活动里最核心的那一个任务，保证端到端能用，而不是把某个模块做完美
- 后续每一版沿地图往下加一层，逐步丰满
- 输出：按发布切片分层的地图，每层都是一个可交付、可验证的完整体验
框架 3：共享理解优先于文档（Shared Understanding，第 1 章 & 开篇「The Word Is Not the Thing」）
适用场景：跨团队对齐"我们到底要做什么"。
步骤：
- 别指望文档自动传递理解——故事是"用来促成对话的"，不是写下来交差的
- 一起动手画地图（PM+设计+工程），在画的过程中暴露分歧、达成共识
- 地图画完后，留下的价值是"大家脑子里一致的画面"，文档只是备忘
- 输出：一次共同建图的协作 + 一张作为对话锚点的地图
决策规则（来源标注）
- 如果你的需求是一张纵向的扁平清单，则把它重排成"横向流程 + 纵向细节"的二维地图。（第 5 章）
- 如果要定 MVP，则横切一条 walking skeleton，让它端到端走通，而不是纵向做完某一个模块。（第 5、6 章）
- 如果写了很多故事文档却没一起讨论过，则你没有共享理解——故事的目的是对话。（第 1 章）
- 如果一个 story 大到几周做不完（epic），则沿地图把它拆成能独立交付的小切片。（第 13 章）
- 如果团队在争"先做哪个模块"，则回到地图问"哪一条最薄的端到端切片能最快验证价值"。（第 6 章）
- 用户故事写法遵循"作为<谁>，我想<做什么>，以便<获得什么价值>"，重点在最后的 why。（第 15 章 / Connextra 模板）
- 如果只盯着输出的功能，则补一步"我们希望用户行为/业务结果发生什么变化"（outcome 优先于交付清单）。（第 3 章）
检查清单：一张健康的故事地图（综合第 5、6 章）
- 有一条从左到右读得通的 backbone（完整用户旅程）
- 纵轴按优先级排，越上面越必要
- 第一个发布切片是横切的、端到端能用的（不是某模块的完美版）
- 每个切片都对应一个可交付、可验证的完整体验
- 大故事（epic）已拆到能在一个迭代内完成
- 地图是团队一起画的，不是 PM 独自写完再宣讲
- 每张卡片能引出对话，而不是只当规格来执行
反模式（书中明确警告）
- 扁平待办清单（flat backlog）——一长条纵向列表，读不出全貌也切不出版本。（第 5 章）
- 把写故事当成写详细规格——以为文字够细就能免掉对话，理解照样丢失。（第 1 章）
- 纵向切 MVP——把某个模块做到完美却端到端走不通，用户拿到手不能用。（第 6 章）
- 只有 PM 一个人建图/写故事——失去了故事最大的价值（共同理解）。（第 1 章）
- 追求"把所有故事写全"而非"把要做的第一版说清"——细节应随临近开发才展开。（第 14 章）
边界声明
- 出版于 2014 年，方法稳定；它解决"如何结构化表达与切分已决定要做的东西"，不解决"该不该做/需求真假"
- 适用：有明确用户流程的产品功能拆解与发布规划；对纯算法/基础设施类无清晰用户旅程的工作，地图形态需变通
- 它假设团队能一起协作建图；远程/异步或话语权不对等的团队，"共享理解"需要额外机制保障
- 术语细节若按二手资料提炼有出入，以原书为准
工作流
收到用户问题后：
- 匹配场景 → 选框架（建骨架 / 切发布 / 对齐理解）
- 缺核心输入（目标用户、这件事的主流程）→ 一次性列出需补的信息；缺次要信息用[假设]标注补全
- 按框架步骤执行：帮用户把散乱需求排成 backbone + 任务，并横切出第一版
- 用"健康地图检查清单"复核结果，标注未通过项（尤其"第一版是否横切端到端"）
- 结尾声明边界，提示可换视角交叉验证（如"该不该做这一版，问 pm-advisor-cagan 的四大风险"）
本 Skill 由 career-skill-factory 生成。内容提炼自原著，版权归原作者 Jeff Patton，仅供个人学习。
出处存档
references/framework.md 是本技能的提炼存档：一手来源清单、论点的三重验证过程（跨域复现／生成力／排他性）、内在张力与外部争议。
平时不用读——下文的心智模型与决策启发式已是提炼结果。这两种情况打开它： ① 用户追问「《User Story Mapping》 真这么说过吗／出处在哪」；② 你要引用一个下文没写的论点，先去存档确认它是否通过了验证、是否属于「保留矛盾」那一类。