mcpField
O
outcome-roadmap

outcome-roadmap

github.com/avelikiy生产力10841 次安装今天更新
代码仓库

关于 outcome-roadmap

这项产品管理技能将功能清单改写为以结果为导向的路线图陈述，突出客户价值与业务影响，帮助团队和 PM Agent 明确计划的意义。

主要功能

  1. 01将功能改写为客户和业务结果
  2. 02使用统一的结果陈述公式
  3. 03按战略主题归类结果
  4. 04检查指标与战略目标的一致性
  5. 05将结果陈述用于 PM 任务规划

适用场景

  1. 01把功能路线图转换为结果陈述
  2. 02为计划中的项目补充可衡量目标
  3. 03按主题整理五项以上结果

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/avelikiy/great_cto --skill outcome-roadmap

安装后在 Claude Code 中输入/outcome-roadmap确认已加载。

详细介绍

成果路线图——从功能转向结果

将以功能为重点的路线图转变为以成果为重点的路线图。

**核心原则：**团队构建功能，但客户和企业关注的是成果。成果路线图传达的是会发生什么变化，而不是要构建什么。

转换公式

对路线图中的每项计划，都应用：

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

示例：

产出（旧）成果（新）
Q2：构建高级搜索筛选器Q2：通过直观的发现体验，让客户查找产品的速度提升 50%
Q2：AI 推荐Q2：通过个性化推荐，将平均订单金额提升 20%
Q3：重新设计仪表板Q3：帮助运营人员监控所有系统，将花在仪表板上的时间减少 80%
Q3：SSO 集成Q3：消除企业管理员的身份验证障碍，助力我们签下 3 笔以上的企业交易
Q4：移动应用Q4：让用户能够在移动设备上完成核心工作流，将 7 天留存率从 20% 提高到 35%

如何应用

步骤 1——阅读现有路线图

如果用户提供了路线图文件，请阅读。如果用户通过口头描述路线图，请提取其中的计划事项列表。

对每项计划，先在内部询问：

  • 计划开发什么功能／项目？
  • 我们为什么要开发它？这会给客户或企业带来什么变化？
  • 哪项指标会提升多少？
  • 有没有更好的其他方式来实现同样的成果？
步骤 2——将每项计划改写为成果

对路线图中的每一项：

  1. 识别产出：计划开发什么功能或项目？
  2. 挖掘成果：我们为什么要开发它？不断追问“然后呢？”，直到找到真正的客户或业务价值。
  3. 改写：使用上述公式。尽可能加入指标。

“然后呢？”追问示例：

  • “我们要添加搜索筛选器” → 然后呢？
  • “用户可以缩小结果范围” → 然后呢？
  • “用户能更快找到想要的内容” → 然后呢？
  • “用户能更快找到产品，不会因此放弃购买，所以转化率更高” ✅ 这就是成果。
步骤 3——按战略主题分组（可选）

如果路线图包含 5 项以上内容，可将相关成果归为主题：

  • 留存（降低流失率的成果）
  • 获客（提高转化率的成果）
  • 变现（提高每位用户收入的成果）
  • 运营效率（降低内部成本／时间的成果）
步骤 4——输出格式
## Outcome Roadmap — <Product> <Quarter/Year>

### Strategic context
<1–2 sentences on what the team is optimising for this period>

### Q<N> Outcomes

| Initiative | Outcome Statement | Primary Metric | Target |
|------------|------------------|----------------|--------|
| <original feature name> | Enable [segment] to [outcome] so that [business impact] | <metric> | <target> |

### What we're NOT doing this quarter (and why)
- <deprioritised initiative>: <reason — not enough signal / too early / wrong priority>

### Key assumptions
- <assumption this roadmap depends on — if it's wrong, the outcomes change>
步骤 5——验证

提交前，检查：

  • 每项成果都包含可衡量的要素（百分比、数字、比率、频率）
  • 每项内容都追问过“然后呢？”——没有留下纯粹的功能描述
  • 至少列出一项“不做”的内容，否则范围将没有边界
  • 成果与 PROJECT.md 中列出的 OKR 或战略目标一致

反模式

❌ “我们将构建 X”——这是产出，不是成果。

❌ “改善 UX”——无法衡量。应改写为：“将完成结账所需的时间从 4min 缩短至 90sec”。

❌ 不包含指标的成果——无法衡量，就无法知道是否实现了成果。

❌ 必须构建特定解决方案才能实现的成果——“让用户通过移动应用访问功能”限定了解决方案。更好的写法是：“让用户能够在任何设备上完成核心工作流”。

与 pm agent 集成

当 pm agent 收到一份没有 PRD 的功能列表时：

  1. 检查列表看起来是产出（功能名称）还是成果（结果描述）
  2. 如果是产出 → 应用此技能进行转换，再拆解为任务
  3. 将成果描述作为每组任务的“原因”写入 PLAN 文档

评论

支持 Markdown