把功能交付型路线图改写成用户与业务成果型路线图时使用

当你需要将路线图中的功能/项目列表转化为可衡量、可传达战略意图的成果陈述时使用。

适用场景

解决思路

1. 收集信息：如果用户提供当前路线图，仔细阅读；如果用户提到战略文档或公司目标，使用 web search 理解路线图应如何与更广泛目标对齐。
2. 逐步思考：对每个 initiative 提问“我们想达成什么成果？”、“解决什么客户问题？”、“哪个业务指标会改善？”、“这会如何影响客户体验或业务？”、“是否有更好、不同的方式达成同一成果？”。
3. 转换流程中识别 Output：对路线图中的每个 initiative，先明确计划做什么功能或项目。
4. 转换流程中挖掘 Outcome：对每个 initiative，追问为什么做它、客户或业务会发生什么变化。
5. 转换流程中改写为成果陈述：使用格式 `Enable [customer segment] to [desired customer outcome] so that [business impact]`，即“让 [客户细分] 能够 [期望的客户成果]，从而 [业务影响]”。
6. 参考示例转换：Output (Old) 为 Q2: Build advanced search filters, implement AI recommendations, redesign dashboard；Outcome (New) 为 Q2: Enable customers to find products 50% faster through intuitive discovery、Q2: Increase average order value by 20% through personalized AI recommendations、Q2: Help operators monitor all systems with 80% reduction in dashboard load time。
7. 组织输出：呈现转换后的路线图，包含按季度/阶段列出的原始 initiatives、每个 initiative 的成果陈述、表示成功的关键指标、依赖关系或排序说明。
8. 加入战略背景：针对整体路线图，添加成果如何与公司战略对齐、关于客户需求的关键假设、灵活的发布窗口（季度，而非具体日期）。
9. 保存输出：如果内容较多，保存为 markdown 文档 `Outcome-Roadmap-[year].md`。
10. 检查成果是否可测试、可衡量。
11. 识别多个输出可能达成同一成果，聚焦成果而非功能列表。
12. 采用成果路线图时拥抱灵活性，因为成果路线图更能适应变化。
13. 如果不确定某功能驱动什么成果，反复问“So what?”直到达到真实客户/业务价值。
14. 避免把成果写成无法度量的口号；若无法度量，先完善指标或假设再改写。
15. 确保每个成果陈述都能回答客户影响和业务影响，而不仅是描述功能交付。

适用边界 · 注意事项

• 当路线图必须对外承诺固定功能范围、固定交付日期或合同/合规硬性交付时，不宜只采用成果型路线图。
• 当仍处于早期探索、客户问题与可衡量成果尚未明确时，先不要强行改写为成果陈述。
• 当组织还没有可度量的业务/客户指标时，先建立指标再使用成果路线图。