pm-roadmap

产品路线图技能

此技能的运作方式（请先阅读）

这是一项生成式技能。默认的失败模式是标注日期的功能列表：按月份列出功能，将其说成承诺，被误认为待办事项，并在一个季度内过时——制造确定性的假象，让每次市场变化都变成一项无法兑现的承诺。路线图是一种战略沟通工具：它以合适的置信度，按顺序回答为什么要做以及预期带来什么结果。此技能会依次把关：

1. 明确战略、受众和规划周期——这些因素决定格式、细节和日期精度。
2. 应用始终适用的核心原则——结果优先于产出，主题优先于功能，与战略关联，并诚实呈现不确定性。
3. 明确格式和流程方面的选择（Now-Next-Later 还是时间线、按季度还是按年度、面向不同受众的视图），并说明取舍。

然后将工作移交给 pm-prioritization-rigor-audit 和 pm-okr-metric-validity-audit 进行验证。

---

步骤 0 — 起草前明确背景

如果尚不清楚，请先询问；如果在没有答案的情况下继续，请说明采用的假设：

• 是否有战略和 OKR？ 路线图将战略转化为按顺序排列的计划。没有战略 → 停下；先帮助明确目标（没有战略的路线图只是愿望清单）。现有的关键结果将构成主线：从每个 KR 倒推，找出预计能推动它实现的计划。
• 受众——内部团队（细节、依赖关系、风险）、高管（主题、里程碑、战略关联），还是客户（价值和方向，不展示日期和内部信息）？每类受众都需要查看同一事实的不同视图——绝不能用一份文档面向所有人。
• 规划周期和节奏——年度（预算规划、方向性下注）还是季度（执行细节）？除了日历安排外，什么情况会触发重新规划？
• 交付背景——有固定日期的承诺（合规、合同）确实需要采用时间线形式；以探索为主的产品则需要基于置信度的结构。

---

始终适用的核心原则（几乎适用于所有情况）

结果优先于产出

• 路线图中的每个条目都要描述问题或预期结果，而不只是交付物。 产出（已发布的功能）衡量的是活动；结果（行为或业务变化）衡量的是价值。
  • ❌ “Q2：AI 助手、深色模式、新仪表板” ✅ “现在：降低第 3 步的引导流程流失率（推动激活 KR）——其下列出候选方案”
• 将业务结果转化为产品结果：“减少客户流失”过于宽泛，无法据此采取行动；“提升新账户在第 1 周对功能的采用率”则是团队可以负责的产品结果。

主题和计划，而非功能目录

• 主题 = 与战略相关的问题领域（“引导流程”“本地化”）；计划 = 主题下的重大工作；功能则作为当前方案列在其下方。这样既能保持方向稳定，也能灵活替换解决方案。
• 每个主题都必须清晰对应一个战略目标——无法说明与战略关联的计划，只是乔装打扮的个人偏好项目（审核时会标记）。

诚实呈现不确定性

• 置信度也是内容的一部分。 近期工作是已承诺的；远期事项则是下注。要明确标示两者的区别——利益相关者会把未作区分的所有事项都视为承诺。
• 不要给出虚假的精确日期。 内部使用排序和依赖关系的时间安排；面向外部时，只说明方向，不给出交付日期。

兼具沟通职能的动态文档

• 路线图是共享工具，而不是文件——而且会逐渐失效：安排定期审查（季度规划 + 事件触发：重大发现、竞争对手动向、战略调整），并将持续发现融入优先级（每周用户洞察；双轨发现与交付）。
• **路线图 ≠ 待办事项列表。**战略方向体现在路线图中；任务、缺陷和工单则归入待办事项列表。如果条目带有故事点，它们就不该出现在这份文档里。
• **呈现方式也是交付内容的一部分：**简短、聚焦、直观（主题／颜色／里程碑），并贯穿叙事主线——呈现挑战 → 成果 → 未来愿景。回答“为什么 X 延期／被排除”时，应说明战略考量，而非表达歉意。

---

取决于具体情境的决策（应呈现，不要自动套用）

决策	适用情形	应避免／调整的情形	默认建议
现在-接下来-以后	时间不确定、顺序很重要；由发现驱动的团队	存在合同／合规期限	现代格式中的默认选择——按信心程度组织
基于主题的视图	向高管／客户传达方向	团队还需要在其下方安排执行顺序	顶层放主题，主题内放计划，将功能视为押注
时间线／甘特图视图	存在硬性依赖、跨团队交接或固定日期	作为对外展示形式（看起来像承诺）	仅作为内部执行层
年度与季度规划	年度：预算、招聘、方向性押注。季度：执行细节	让一个成果物同时承担这两种职责	两者都要，并相互关联：年度主题 → 季度计划
受众视图	面向内部的详细视图／面向高管的主题视图／面向客户的价值视图	向客户展示内部细节，或向高管展示工单级细节	同一事实来源的三个视图
数据驱动的规模估算	存在分析数据时，用于机会规模、影响估算、历史时间线和成功阈值	在没有数据的情况下编造数字（→ 严谨性审计）	使用真实数据估算规模；将估算标明为估算
依赖关系映射	多团队计划、共享系统、外部合作伙伴	单团队的简单范围	涉及团队边界时都应绘制映射
技术债务资源分配	为债务／平台工作固定分配一定产能	让技术债务逐项与功能竞争（它总会输）	明确并定期分配产能，像其他工作一样设定主题
利益相关者意见征集流程	在注意偏差的前提下，有结构地收集销售／支持／客户的意见	让声音最大的人左右路线图	收集意见，再用战略筛选；在目标设定阶段让利益相关者参与，以建立认同

---

验证结果（编排）

交接时使用各审查视角对应的可安装技能 name。只有在已安装该技能时才调用；如果未安装，本技能的核心本身已包含这些规则，继续执行即可，无需因此阻塞。

完成或修订后，应将内容交给审计视角审查，而不是直接宣布完成。这些都是候选视角——按照 docs/orchestration-policy.md 中的要求决定采取何种方式，或者将整个成果交由 pm-product-review 审查。这里，prioritization-rigor 是始终适用于本成果的视角（自动运行）——路线图的完整性取决于其是否依据战略安排优先顺序；其他视角是可选的，应根据成果实际包含的内容决定是否采用。如果用户调用此技能是为了处理某一具体事项，请遵守该范围。

• pm-prioritization-rigor-audit（自动运行）——排序是否有证据支撑、与战略关联，并明确权衡取舍？评分是否真实？是否有事项仅仅因为有人大声要求就排在前面？
• pm-okr-metric-validity-audit（可选——如果涉及目标/KR）——路线图所针对的目标/KR 本身是否有效（可证伪、非虚荣指标，并设有护栏）？如果路线图瞄准的是糟糕的指标，那也只是有条理地浪费资源。

如果审计发现冲突（例如，利益相关方的承诺与战略契合度不一致），应回到主要任务来解决：路线图的作用是让所有人围绕原因和结果目标达成共识——应优先维护其可信度，而非迁就某个单独事项。

---

常见的应做与不应做模式

❌ 不要	✅ 应当
将功能固定到具体月份，并作为承诺呈现	使用 Now-Next-Later，并明确标注置信度
“Q3：Dashboard v2”	主题 → 计划 → 结果，并注明其服务的 KR
为所有人维护同一份路线图文档	基于同一套事实，分别提供内部版 / 高管版 / 客户版
在路线图条目中列入故事点和 Bug 修复	路线图 = 方向；待办事项 = 任务
制定后便不再调整的年度计划	安排定期审查，并在发现触发条件时重新规划
编造覆盖面/影响力数据，让计划看起来严谨	根据分析数据估算规模；明确标注估算值（→ prioritization-rigor）
对“为何不包含 X”避而不谈	明确说明不做/稍后处理的原因，并关联战略
在评审材料中放入密集的甘特图	采用简短、直观、叙事性的呈现；按需提供详细信息
悄悄让销售交易请求插队	采用结构化的需求收集流程、战略筛选，并明确记录例外
未经检查便发布	交由 prioritization-rigor + okr-metric-validity 审查

---

来源课程（Uxcel）

• 为什么需要路线图
• 从静态转向动态
• 数据驱动的路线图规划
• 运用产品战略制定路线图
• 从战略到故事
• 沟通并推广路线图
• 路线图规划与优先级排序