1.1 什么是 Roadmap？为什么它比其他文档更“战略”？
在进入优先级排序方法之前，必须先理解 Roadmap 在整个产品生命周期中的位置。很多团队把 Roadmap 当作“排期表”或“待办清单”，结果版本规划变成了接单工具，丧失了战略指引功能。
Roadmap 是连接业务战略与版本交付的战略地图，它回答三个核心问题：
- 为什么做（业务目标）
- 做什么（关键需求与方案）
- 什么时候做（时间窗口与版本边界）
1.1.1 定义 Roadmap：从“需求清单”到“战略地图”
| 维度 | 传统需求清单 | Roadmap（战略地图） |
|---|---|---|
| 驱动 | 被动响应（客户说、老板说） | 主动对齐（目标 -> 机会 -> 方案） |
| 颗粒度 | 功能级（“增加筛选” “优化列表”） | 主题/能力级（“提升搜索转化” “降低新客流失”） |
| 时间绑定 | 模糊或固定死（“下个月必须上线”） | 动态窗口（现在/近期/远期） |
| 变更方式 | 被催促、无原则 | 评审后调整、有依据 |
| 受众 | 开发团队内部 | 跨团队（高管、运营、销售、客户） |
产品经理行动点： 如果你在向项目组展示 Roadmap 时只讲了“功能上线顺序”，那么你已经偏离了 Roadmap 的使命。Roadmap 的每一个版本节点，都应该能追溯到可衡量的业务指标。
1.1.2 版本规划目标：在不确定中做确定的选择
版本规划的核心目标不是“按时交付”，而是在有限资源和不确定需求下，最大化业务价值。具体目标拆解为：
- 价值对齐： 确保每个版本交付的内容，都直接支撑当前季度的业务目标。
- 风险控制： 通过阶段性交付，尽早暴露技术或需求风险。
- 市场节奏： 与外部市场活动（如促销季、合规截止日）匹配。
- 团队产能可持续： 避免过度承诺导致质量下降或团队 burnout。
1.1.3 核心交付物：一套可复用的模板
在每个版本规划周期中，产品经理需要输出以下关键交付物：
- 需求池（Backlog） —— 统一收口所有来源的需求，含用户场景、业务问题、预期指标。
- Roadmap（高层面时间轴） —— 展示未来 3~6 个版本的主题与关键节点。
- 版本定义文档（Release Definition） —— 明确版本目标、范围边界、验收标准。
- 优先级排序清单（Prioritized Backlog） —— 使用 RICE、WSJF 或 MoSCoW 等方法排序后的需求列表。
- 验收与复盘报告 —— 版本上线后的指标验证与问题总结。
常见避坑： 很多团队只维护一个需求文档，却没有独立的 Roadmap 视图。缺少 Roadmap 层会导致版本规划总是被临时需求打断，长期方向感消失。Roadmap 必须以独立的、可分享的格式存在，而不是藏在 PRD 的附录里。
SVG 图解读： 上图展示了 Roadmap 在整条价值链中的位置。业务目标驱动需求汇聚，需求经排序形成 Roadmap，Roadmap 细化后进入版本规划，最终输出核心交付物。交付物的指标验证又反过来修正下一期的业务目标，形成闭环。这也是为什么 Roadmap 不能只用一次——必须定期根据验证结果刷新。