pm-skills 实战：用 outcome-roadmap 技能把功能清单路线图重构为结果导向路线图

pm-skills 实战：用 outcome-roadmap 技能把功能清单路线图重构为结果导向路线图

【免费下载链接】pm-skillsPM Skills Marketplace: 100+ agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.项目地址: https://gitcode.com/GitHub_Trending/pm/pm-skills

在 pm-skills 项目的 pm-execution 插件中，outcome-roadmap是一套把"输出导向（output-focused）路线图"改写成"结果导向（outcome-focused）路线图"的 Agent 技能。它的核心使命只有一个：让团队从"下季度要上线哪些功能"的清单思维，切换到"我们要为客户和业务带来什么可衡量的改变"的结果思维。读完本文，你将掌握该技能的完整方法论、可复制的三步改写流程、标准化的结果陈述句式，以及配套命令/transform-roadmap的实战用法，并了解它在 pm-skills 整个执行工作流中的定位。

为什么输出导向的路线图会失败

outcome-roadmap/SKILL.md 开篇给出了明确的问题诊断：输出导向路线图制造了"虚假的精确性"（false precision），并把团队的对齐目标从"结果"错位到"功能"上。

具体来说，这类路线图通常长这样：

Q2：上线高级搜索筛选器、实现 AI 推荐、重构仪表盘

表面上看它清晰、可排期、可交付，但存在三个结构性缺陷：

1. 对齐错位：团队围绕"功能"对齐，而不是围绕"为什么要做这个功能"对齐。开发完成了"高级搜索筛选器"就算交付，却没人回答"客户是否因此更快找到了商品"。
2. 虚假精确：用具体日期和功能名制造"计划已确定"的错觉，一旦市场变化，功能列表会迅速失真。
3. 抑制灵活性：当团队被锁死在功能清单上，即使发现另一条更便宜、更有效的达成路径，也不敢轻易改变。

结果导向路线图的回应是：先厘清"正在解决的客户问题"和"期望产生的业务价值"，再让执行方式保持灵活。这正是该技能存在的原因——把路线图从"做什么"（what）提升到"为什么"（why）。

在 pm-skills 仓库中，这个技能的 frontmatterdescription明确写了触发条件："Use when shifting to outcome roadmaps, making a roadmap more strategic, or rewriting feature lists as outcomes"，这意味着在 Claude Code / Cowork 等支持技能的 AI 助手中，当对话涉及路线图战略化改造时，该技能会被自动加载。

核心方法论：三步改写流程

技能文档定义了三步转换流程（Transformation Process），每一步对应一个需要回答的问题：

第一步：识别输出（Identify the Output）

先问"计划中的功能或项目是什么？"——这是清单上的原始条目，比如"构建 SSO 集成""重构仪表盘""增加 CSV 导出"。

第二步：挖掘结果（Uncover the Outcome）

再追问三个层次的问题：

• 我们为什么要构建它？
• 对客户或业务来说，什么发生了改变？
• 底层是哪个业务指标会因此改善？

这一层的关键是穿透功能外壳，找到真实价值。文档的 Notes 部分给出了一个非常实用的"逼问"技巧：如果搞不清某个功能驱动了什么结果，就一直问"So what?"（那又怎样？），直到触及真实的客户/业务价值为止。

第三步：改写为结果陈述（Rewrite as Outcome Statement）

使用技能规定的标准句式：

Enable [customer segment] to [desired customer outcome] so that [business impact]

即：让 [客户群体] 能够 [期望的客户结果]，从而实现 [业务影响]。

这个句式比简单地把功能换个说法要高一个维度，因为它强制同时回答三个问题：为谁（segment）、达成什么客户效果（outcome）、带来什么业务收益（business impact）。配套命令 transform-roadmap.md 也提供了一个变体句式：

[Verb] [metric/experience] for [user segment]

两种句式可以互为补充：技能文档的完整版适用于正式路线图，命令里的精简版适用于快速改写单条功能。

实战案例：同一份 Q2 计划，两种写法

技能文档给出了一个完整的转换示例，这里结合配套命令中的案例一起展开：

技能文档示例

• 输出（旧）：Q2：构建高级搜索筛选器、实现 AI 推荐、重构仪表盘
• 结果（新）：
  • Q2：让客户通过直觉化的发现流程，将找到商品的速度提升 50%
  • Q2：通过个性化 AI 推荐，将平均订单价值提升 20%
  • Q2：帮助运营人员监控所有系统，将仪表盘加载时间降低 80%

注意观察：三条新陈述没有一条再提"筛选器""推荐算法""重构"这些实现手段，而是全部落在"客户体验改进 + 可量化指标"上。

命令文档补充案例

原功能（Output）	转换后结果（Outcome）	成功目标
构建 SSO 集成	降低企业客户的上手摩擦	企业账户首次价值实现时间（time-to-first-value）缩短 50%
重构仪表盘	帮助重度用户更快发现洞察	获得洞察的时间（time-to-insight）降低 30%
增加 CSV 导出	让团队能在产品外部分享数据	报告分享量提升 25%

这两组案例揭示了同一个模式：功能名 → 动词开头的结果描述 + 可量化的目标值。指标必须带目标（50%、20%、80%、25%），因为"结果导向"不等于"口号导向"，没有数字的陈述无法被检验。

完整工作流：从输入到产出

技能文档定义了 7 步操作指令，与配套命令/transform-roadmap的 5 步工作流互为表里。合并后的完整流程如下：

1. 收集信息（Gather Information）

• 用户提供当前路线图时，仔细阅读；
• 用户提及战略文档或公司目标时，检索相关资料，理解路线图应当如何对齐更宏大的目标；
• 命令版本进一步明确：接受任意格式的输入——功能清单、待办项、Now/Next/Later 或季度路线图文档、电子表格或甘特图导出、甚至路线图工具的截图；
• 解析每个条目，提取：功能名称、描述、目标日期/时间窗口、以及任何上下文。

2. 逐步思考（Think Step by Step）

对每个条目依次提问：

• 我们试图达成什么结果？
• 我们在解决什么客户问题？
• 哪个业务指标会改善？
• 这对客户体验或业务有什么影响？
• 是否存在达成同一结果的更好、不同的路径？

最后这个问题尤其重要——它把团队从"按既定方案执行"解放为"按结果优化方案"。

3. 理解战略上下文（Understand Strategic Context）

命令文档要求在执行改写前先确认三个背景信息：

• 本周期（季度）的产品目标或 OKR 是什么？
• 这份路线图的受众是谁？（高管、工程团队、客户、董事会——受众不同，详略不同）
• 期望的输出格式是什么？（Now/Next/Later、季度、时间线）

这三点决定了改写后路线图的"颗粒度"和"展示口径"。技能文档第 6 步"包含战略上下文"（Include Strategic Context）与此呼应，要求最终输出中体现：结果与公司战略的对齐关系、关于客户需求的关键假设、灵活的发版窗口（用季度而非具体日期）。

4. 逐条转换并归组（Transform Each Item）

命令文档补充了一个技能文档未展开的关键动作：把服务同一结果的多个功能归组到同一个计划项（initiative）下。例如"SSO 集成 + 团队管理界面 + 审计日志"可能共同服务于"企业客户上手更顺畅"这一个结果——三者不再各自占一行，而是合并为一个结果条目，下面挂多个关键举措。

5. 组织输出结构（Structure Output）

技能文档第 5 步要求转换后的路线图包含四类信息：

• 按季度/阶段列出的原始计划项
• 每个计划项对应的结果陈述
• 标志成功的关键指标
• 依赖关系或排序说明

6. 保存输出（Save the Output）

内容成型后保存为 Markdown 文档，技能文档指定的文件命名为：Outcome-Roadmap-[year].md。

标准输出模板：Now / Next / Later 结构

配套命令 transform-roadmap.md 提供了一个可直接套用的完整模板，这是把结果导向路线图落到纸面的关键工具：

## Outcome-Focused Roadmap: [Product] — [Period] **Strategic themes**: [2-3 high-level themes] ### Now (Current Quarter) **Theme: [Strategic Theme]** | Outcome | Success Metric | Key Initiatives | Status | |---------|---------------|----------------|--------| ### Next (Next Quarter) **Theme: [Strategic Theme]** | Outcome | Success Metric | Key Initiatives | Confidence | |---------|---------------|----------------|------------| ### Later (Future) **Theme: [Strategic Theme]** | Outcome | Success Metric | Key Initiatives | Dependencies | |---------|---------------|----------------|-------------| ### Transformation Notes | Original Feature | Transformed Outcome | Why This Framing | |-----------------|--------------------|-----------------| ### What Changed [Summary of how the roadmap narrative shifted]

这个模板的设计意图值得注意：

• Now 列带 Status（状态），因为当前季度需要承诺与推进跟踪；
• Next 列带 Confidence（置信度），因为下季度计划尚未完全确定，需要标注把握程度；
• Later 列带 Dependencies（依赖），因为远期条目主要是占位与依赖梳理，不应过度具体——技能文档 Notes 明确指出："Later 项应更不具体——只有结果，没有已承诺的解决方案"；
• Transformation Notes 表记录"原功能 → 转换后结果 → 为什么这样表述"，保留可追溯的转换推理过程；
• What Changed 段落总结路线图叙事发生了怎样的转变，便于向团队或高管讲述"我们改了什么、为什么改"。

配套命令/transform-roadmap的调用方式

在 pm-skills 中，技能（skill）是基础能力，命令（command）是把一个或多个技能串成端到端流程的入口。outcome-roadmap技能被 pm-execution/commands/transform-roadmap.md 命令直接引用（命令文档原文写有"Apply theoutcome-roadmapskill"），是该命令的底层引擎。

调用方式（命令文档 Invocation 部分）：

/transform-roadmap [paste your feature list or roadmap] /transform-roadmap [upload a roadmap doc, spreadsheet, or screenshot]

也就是：直接粘贴功能清单，或上传路线图文档、表格、截图均可。命令完成后还会主动提供三个后续增值动作（Review 步骤）：

• "需要我为每个结果添加 OKR 对齐吗？"
• "要不要我起草一份路线图利益相关方汇报？"
• "需要我识别 Now 部分项目的风险吗？"

这体现了 pm-skills 的设计哲学——命令之间相互衔接，形成连续的工作流（README 中明确说明："Commands are designed to flow into each other, matching the PM workflow"）。

与周边技能的联动：从路线图到执行闭环

outcome-roadmap不是孤立的。在 pm-execution 插件中，它天然与几个相邻技能形成闭环：

• brainstorm-okrs/SKILL.md：结果导向路线图与 OKR 高度同源——OKR 也是"定性目标 + 可量化关键结果"。命令的 Review 步骤建议把每个结果与 OKR 对齐。该技能还澄清了 OKR、KPI、North Star Metric 三者的关系：Key Results 指向量化指标，KPI 可作 Key Result 或健康指标，North Star Metric 则是客户中心的单一 KPI——这些正是结果陈述中"业务指标"的来源。注意该技能的一个纪律同样适用于路线图改写：避免输出导向指标（如"上线 5 个功能"），聚焦结果。
• wwas/SKILL.md：WWA（Why-What-Acceptance）格式把每个工作项拆成"战略 Why + 简洁 What + 验收标准"，与结果导向路线图共享同一个核心——先讲清"为什么"，再谈"做什么"。路线图确定结果后，可用 WWA 把结果拆解为可独立开发、可验收的待办项。
• sprint-plan/SKILL.md：路线图的"Now"部分最终要进入 Sprint 规划。sprint-plan 技能要求"Sprint Goal 用一句话描述成功的样子"——这本质上就是把路线图层面的结果陈述下放到迭代层面。
• strategy-red-team/SKILL.md：路线图改写完成后，可以用红队技能攻击其中的承重假设（load-bearing assumptions），例如"客户真的会因为个性化推荐提升客单价吗"。它要求把每条失败模式写成可证伪的"Fails if ___"形式，并给出"本周就能拿到证据 + 终止标准 + 最便宜的测试"——这与结果导向路线图强调"可测试、可衡量"的要求完全一致。

设计要点与最佳实践

技能文档的 Notes 部分是长期使用沉淀下来的四条纪律，也是判断改写质量的标准：

1. 结果必须可测试、可衡量（An outcome should be testable and measurable）——没有度量标准的陈述不是结果，是口号；
2. 多个输出可以服务于一个结果；关注结果，而非功能清单（Multiple outputs may achieve one outcome; focus on the outcome, not the feature list）——这正是"功能归组到同一结果"的理论依据；
3. 结果导向路线图对变化更具韧性，拥抱灵活性（Outcome roadmaps are more resilient to change—embrace flexibility）——市场变化时，换实现方案而不换目标；
4. 拿不准功能驱动什么结果时，持续问"So what?"，直到触及真实价值——防止把"技术输出"误当成"业务结果"。

配套命令还补充了几条实操纪律：

• 结果要有清晰的"完成状态"（done state）；
• 多个功能映射到一个结果——这是特性，不是缺陷；
• 如果某个输出无法清晰服务于任何结果，把它标记出来，让用户决定是补充理由还是降级处理；
• 受众决定颗粒度：高管看的路线图应纯结果导向，工程路线图可以在每个结果下附带交付物；
• Later 部分应保持模糊——只有结果，没有已承诺的解决方案。

在 pm-skills 仓库中的落地方式

从仓库实现看，outcome-roadmap技能遵循了统一的技能规范：

• 目录结构为skills/outcome-roadmap/SKILL.md，frontmatter 的name必须与目录名一致（仓库根目录的 validate_plugins.py 会对所有插件执行此项校验，validate_skill函数会检查 frontmattername与目录名匹配、description字段必填，并提示是否包含 "use when" 等触发词）；
• 该技能属于pm-execution插件，与其余 15 个技能、11 个命令一起组成"执行"域。插件 README 中将其描述为"Transform a feature list into an outcome-focused roadmap"；
• 安装整个 pm-skills 市场后即可在 Claude Code / Cowork 中使用；技能文件采用通用 skill 格式，其他支持该格式的 AI 助手（如 Gemini CLI、OpenCode、Cursor 等）复制技能目录后同样可用（安装方式详见 README.md）。

结语

outcome-roadmap技能的价值不在于"换个说法"，而在于把路线图从一份功能交付排期表升维为一份可度量、可谈判、可应变的战略意图声明。配合/transform-roadmap命令的 Now/Next/Later 模板、"原功能 → 结果 → 为什么"的转换追溯表，以及 OKR、WWA、Sprint、红队演练等周边技能的衔接，pm-skills 为"从结果到交付"提供了完整的执行链路。下一次当你面对一份全是功能名的路线图时，不妨先用本文的句式问一句：它到底要为客户和业务带来什么可衡量的改变？

【免费下载链接】pm-skillsPM Skills Marketplace: 100+ agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.项目地址: https://gitcode.com/GitHub_Trending/pm/pm-skills