产品路线图制定，是把产品战略转成跨版本演进方向的管理动作：先明确目标与约束，再按主题组织候选方向，用价值、成本、依赖和风险排序，形成带时间窗和判断依据的路线图，并用评审与变更机制维持它有效。本文给出制定前的输入清单、五步操作流程、角色分工、方向条目示例和完成检查表，范围限定在跨版本方向；单版本内的需求排期与发布执行另行处理。
要点总览（TL;DR）
- 路线图制定先明确目标来源、范围边界和时间窗约定，把跨版本演进方向与单版本需求排期、发布执行分开。
- 五步流程：归并候选方向、补齐价值假设、评估成本依赖风险、排序并放入时间窗、形成文档进入评审，每步都有输入、输出和完成标志。
- 产品负责人主导方向归并与排序主张，业务与销售提供诉求，研发负责人评估成本与风险，管理层确认目标与承诺项。
- 方向条目写清主题、目标用户、价值假设、成功判断、时间窗、状态和排序理由，承诺项与探索项按确定程度区分写法。
- 用定期评审加触发式评审维持路线图有效，变更需明确批准人并保留记录，完成与否按检查清单逐项核对。
路线图先定什么：目标、范围与时间窗
路线图制定最常见的失败，是把一堆需求按时间排开，看起来像计划，实际没有回答“为什么往这个方向走”。开始动笔前，先把四类输入准备齐，路线图才有判断依据。
目标来源。路线图的方向要能追溯到业务目标与产品战略，例如年度营收结构变化、目标客群调整、关键能力补齐。客户访谈、销售反馈、市场与竞品信息是重要输入，但它们提供的是诉求和信号，需要经过归并和取舍，不能直接变成路线图条目。
范围界定。路线图管的是未来几个版本的演进方向，回答“往哪走、为什么这样排”。单个版本里做哪些需求、优先级怎么排，属于版本规划；具体什么时候提测、何时上线、如何灰度，属于研发版本与发布管理。三者衔接但交付物不同，混在一起写，路线图就会退化成需求清单。
时间窗设定。常用做法是按季度或半年划分时间窗，每个窗口内放若干方向，并标注状态。承诺项指已经过决策、资源有保障、对外可以对期的方向；探索项指方向成立但细节待验证、时间窗可能移动的方向。两类混排而不标注，是后续争议的主要来源。
输入清单。建议在制定前收齐以下内容，缺项要写明缺口和补齐时间：
| 输入类别 | 具体内容 | 提供方 |
|---|---|---|
| 目标 | 业务目标、产品战略、年度重点 | 管理层、产品负责人 |
| 约束 | 人力与预算上限、合规与合同要求、关键技术依赖 | 研发负责人、财务或业务负责人 |
| 现状基线 | 当前版本能力、遗留问题、技术债与架构限制 | 产品与研发团队 |
| 干系人诉求 | 客户反馈、销售与售前需求、支持团队高频问题 | 业务与销售、客户成功 |
时间窗约定建议形成一页说明：本次路线图覆盖几个时间窗、每个窗口的起止、承诺项与探索项的判定口径、哪些内容不在本次范围内。这份约定在评审时先确认，能减少大量“这个版本为什么没有”的争论。
核心步骤：从候选方向到可评审的路线图
五步流程的每一步都有明确输入、动作、输出和完成标志。完成标志的作用是让团队知道这一步可以结束，避免在收集阶段无限扩张或在排序阶段反复拉扯。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、收集并归并候选方向 | 客户反馈、销售诉求、战略目标、现状基线 | 把零散需求按主题聚类，例如“权限与组织管理”“数据接入能力”“移动端体验”，每个主题形成一个方向候选 | 方向候选清单，含来源与涉及诉求 | 候选方向数量收敛到可评审规模，每条能说清解决哪类问题 |
| 二、补齐价值假设 | 方向候选清单 | 为每个方向写明目标用户、要解决的问题、预期价值、成功判断指标 | 方向卡片 | 每个方向都有可检验的成功判断，而非“提升体验”一类描述 |
| 三、评估成本、依赖与风险 | 方向卡片、技术现状、资源约束 | 由研发负责人评估工作量区间、架构改造需求、外部依赖与主要风险 | 带评估结论的方向卡片 | 每个方向都有成本量级、依赖项和风险说明 |
| 四、排序并放入时间窗 | 评估后的方向卡片、目标与约束 | 按价值、成本、依赖、风险综合排序，放入季度或半年时间窗，标注承诺或探索状态 | 排序记录与时间窗分配表 | 排序理由可复述，承诺项资源已确认 |
| 五、形成文档并进入评审 | 排序结果、时间窗约定 | 整理成路线图文档，组织评审，记录结论与待决事项 | 路线图文档、评审纪要 | 评审通过，待决事项有责任人和时间 |
排序环节值得单独说明。价值高、成本低、无强依赖的方向优先放入近端时间窗；价值高但依赖架构改造的方向，可以放在较远窗口并提前启动技术预研；价值尚不明确的方向标为探索项，用小范围验证代替直接承诺。排序记录要写清取舍理由，尤其是被推迟的方向为什么推迟，这比排序结果本身更有长期价值。
方向卡片和排序记录需要被持续维护，评审结论也要能回溯到具体方向。在ONES中，可以把每个方向建为工作项，用状态区分承诺与探索，把价值假设、评估结论写在描述或关联文档里，评审纪要作为文档挂接到对应方向，后续调整时能直接看到历史判断依据。
角色分工与各环节交付物
路线图如果只由产品负责人一人完成，执行阶段容易失去共识。合理的分工是：产品负责人主导方向归并与排序主张，其他角色在各自环节提供判断，管理层对目标和承诺项做最终决策。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 产品负责人 | 归并候选方向、撰写价值假设、提出排序主张、维护路线图文档 | 方向卡片、排序记录、路线图文档 |
| 业务与销售 | 提供目标客户诉求、合同与商机相关的方向输入，标注诉求的紧迫程度 | 诉求输入清单 |
| 研发负责人 | 评估成本量级、技术依赖与架构风险，确认承诺项的资源可行性 | 评估结论与风险说明 |
| 管理层 | 确认业务目标与优先级口径，对承诺项做决策，处理跨方向资源冲突 | 目标确认与承诺项决策记录 |
| 评审参与方 | 在评审会上对方向与排序提出意见，确认本角色相关的衔接安排 | 评审纪要 |
交付物清单可以按阶段归拢：制定前有输入清单与时间窗约定；制定中有方向卡片和排序记录；制定后有路线图文档和评审纪要。这些交付物不必是独立文件，关键是每项判断都能找到出处，后续变更时知道改哪里、通知谁。
示例：一条跨版本演进方向如何写进路线图
以下为演示情景，用于说明写法，不代表任何真实产品。假设某协作类产品计划在三个版本内完善组织与权限能力，路线图中可以这样写一条方向：
| 字段 | 内容示例 |
|---|---|
| 方向主题 | 组织与权限体系升级 |
| 目标用户 | 中大型客户的组织管理员与IT负责人 |
| 价值假设 | 支持多层级组织与细粒度角色后，可减少管理员手工维护成本，并满足客户在采购评估中的权限要求 |
| 成功判断 | 目标客户试点中，权限配置耗时下降，权限相关支持工单减少 |
| 时间窗与状态 | 第一个窗口：探索项，完成角色模型设计与试点；第二个窗口：承诺项，完成核心能力上线；第三个窗口：承诺项，补齐迁移工具与批量管理 |
| 依赖与风险 | 依赖统一身份模型改造；风险是存量数据迁移影响现有客户，需要提前准备迁移方案与回滚策略 |
| 排序理由 | 该方向同时支撑多个客户诉求与年度目标中的企业客户拓展，价值明确；因涉及架构改造，先以探索项验证模型，再转为承诺项 |
承诺项与探索项的写法差异主要在确定程度：承诺项写清交付范围、时间窗和资源安排；探索项写清要验证的问题、验证方式和退出条件，例如“若试点中权限配置耗时未达预期改善，则调整方案或推迟”。示例中的排序理由同时说明了价值来源和依赖处理方式，这正是评审时最需要的信息。
评审、变更与完成检查
路线图定稿只是开始。市场变化、客户合同、技术风险都会让原有判断失效，需要一套评审节奏和变更规则来维持它的可信度。
评审节奏。定期评审按季度或半年进行，与时间窗滚动对齐，检查方向进展、状态转换和新增输入。触发式评审用于突发情况，例如关键客户合同变化、重大技术风险暴露、战略目标调整。触发式评审不宜过频，否则路线图会失去稳定性；建议明确触发条件，由产品负责人判断是否召集。
变更规则。时间窗调整和状态转换要有批准人：探索项转承诺项，需要研发确认资源、管理层确认优先级；承诺项延期或移出时间窗，需要说明原因并通知受影响的业务方。变更记录保留在原方向条目上，形成可追溯的历史。
与版本规划的衔接。路线图确定方向和时间窗后，版本规划在每个窗口内把方向拆成具体需求并排优先级；发布管理再按研发节奏安排提测与上线。衔接点是方向条目：版本规划中的需求应能关联回某个路线图方向，无法关联的需求要单独说明来源。
完成检查清单。路线图制定是否完成，可逐项核对：
- 每个方向都能追溯到业务目标或明确的客户诉求；
- 每个方向都有目标用户、价值假设和成功判断；
- 成本、依赖与风险已由研发负责人评估并记录；
- 排序理由可复述，被推迟的方向写明了原因；
- 承诺项与探索项状态标注清楚，承诺项资源已确认；
- 时间窗约定与范围边界已在评审中确认；
- 评审纪要记录了结论、待决事项、责任人和时间；
- 相关干系人已确认各自衔接安排。
这份清单同时可以作为下一次定期评审的检查项，用来判断路线图是否仍然有效，而不只是判断它是否写完。
常见问题
路线图按季度还是半年划分时间窗更合适？
取决于产品所处市场的稳定程度和研发周期。市场变化快、客户需求波动大的产品，按季度划分更容易滚动调整；技术演进周期长、交付节奏稳定的产品，按半年划分可以减少频繁变更带来的沟通成本。无论选哪种，都要在时间窗约定中写清起止时间、承诺项与探索项的判定口径，并在评审时先确认这份约定。
探索项什么时候可以转为承诺项？
通常需要同时满足三个条件：验证问题已有结论，价值假设得到支持；研发负责人确认资源与依赖可行；管理层确认优先级。转换时把验证结论、资源安排和批准记录补充到原方向条目上，便于后续回溯。如果验证结果不支持原假设，应调整方案或推迟，并在排序记录中写明原因。
路线图定稿后，业务方临时提出紧急需求怎么处理？
先判断它属于哪个层次：如果是单版本内的需求调整，走版本规划的优先级流程；如果涉及跨版本方向变化，才进入路线图的触发式评审。触发式评审建议设定明确条件，例如关键客户合同变化或战略目标调整，由产品负责人判断是否召集，避免路线图因零散诉求频繁变动而失去稳定性。
路线图文档需要写到多细？
写到能支撑评审决策即可：每个方向有目标用户、价值假设、成功判断、成本与依赖评估、时间窗和状态，排序理由可复述。具体需求拆分、验收标准和排期属于版本规划的内容，放进路线图会让文档膨胀且难以维护。方向条目保持一页以内，细节通过关联文档承载。
多个方向争抢同一批研发资源时怎么排序？
回到目标和约束做取舍：先看哪个方向对业务目标的支撑更直接，再看成本量级和依赖关系。价值高、成本低、无强依赖的方向优先放入近端时间窗；价值高但依赖架构改造的方向可以放远并提前启动预研。资源冲突无法在产品和研发层面解决时，提交管理层决策，并把决策结论记录到排序记录中。
