roadmap-planning

目的

通过整合优先级排序、Epic 定义、利益相关方对齐和发布排序技能，指导产品经理开展战略路线图规划，并将这些技能编排成结构化流程。借助此流程，将零散的功能请求转化为连贯、以成果为导向的路线图，使利益相关方达成一致、工作安排合乎逻辑，并清晰传达战略意图——避免路线图沦为缺乏战略叙事或以客户为中心视角的“功能工厂”。

这不是甘特图，而是一种战略沟通工具，用于展示你要构建什么、为何重要，以及如何支撑业务成果。

输入

最适合提供： 产品信息和规划周期（下个季度、明年）。 也很有帮助： 要支撑的战略或 OKR、候选计划清单、团队产能，以及已知的利益相关方压力。

随调用一并提供的任何内容——技能名称后的文本、粘贴的上下文，或追加的 ARGUMENTS: 行——都视为已回答的问题。请使用这些信息，并跳过其中已涵盖的提问。

没有准备任何信息也没关系。 工作流会先建立战略背景，再进行优先级排序、Epic 定义和发布排序。

调用示例： 为我们的移动应用规划一个涵盖 2 个季度的路线图：这是我们的 3 个 OKR 和 12 个候选计划清单。

关键概念

什么是战略路线图规划？

路线图规划是以下过程：

1. 收集输入 — 客户问题、业务目标、技术限制
2. 定义计划 — 制定目标明确且有成功指标的 Epic
3. 确定优先级 — 按影响、投入和战略契合度排列计划
4. 安排顺序 — 根据逻辑依赖关系，将工作安排到各个发布周期或季度
5. 沟通 — 通过战略叙事向利益相关方展示路线图

路线图类型

Now/Next/Later 路线图：

• Now： 当前季度（已承诺）
• Next： 下个季度（把握较高）
• Later： 后续探索（把握较低）
• 最适合： Agile 团队、面临不确定性或持续进行探索的场景

基于主题的路线图：

• 按战略主题组织（例如，“用户留存”“拓展企业市场”“移动体验”）
• 最适合： 向高管沟通、展示战略意图

时间线路线图（按季度）：

• Q1：Epic A、B；Q2：Epic C、D；Q3：Epic E、F
• 最适合： 资源规划、利益相关方沟通

基于功能的路线图（反面模式）：

• 列出功能但不提供背景（例如，“深色模式”“SSO”“高级报告”）
• 失败原因： 缺乏战略叙事，也未围绕客户问题进行阐述

为什么有效

• 以成果为导向： 将计划与业务或客户成果联系起来
• 利益相关方对齐： 透明的流程可减少政治摩擦
• 战略清晰： 不只展示“做什么”，还说明“为什么”
• 灵活： 随着探索和交付中的认知变化而调整

反面模式（这不是）

• 不是承诺： 路线图是战略计划，不是合同
• 不是功能清单： 路线图应阐述问题，而不只是解决方案
• 不是瀑布模式： 路线图会根据学习成果按季度演进

适用场景

• 年度或季度规划周期
• 产品战略会议之后（将战略转化为路线图）
• 新利益相关方入职（就方向达成一致）
• 重新制定现有路线图（从功能驱动转向成果驱动）

不适用场景

• 战术性冲刺规划（改用待办事项列表）
• 战略尚不明确时（先开展 product-strategy-session）
• 利益相关方期望明确的日期承诺时（先管理预期）

---

引导流程的权威依据

以引导式对话运行此工作流时，请将 workshop-facilitation 用作交互协议。

其中定义了：

• 会话提示与进入模式（Guided、Context dump、Best guess）
• 使用通俗语言提示的单问题轮次
• 进度标签（例如，Context Qx/8 和 Scoring Qx/5）
• 中断处理以及暂停／恢复行为
• 决策点处的编号建议
• 常规问题的快速选择编号回复选项（适用时包含 Other (specify)）

此文件定义工作流顺序和特定领域的输出。如有冲突，请遵循此文件中的工作流逻辑。

应用

使用 template.md 获取完整的填写结构。

此工作流通过多个组件和交互式技能，在 1-2 weeks 内协调 5 phases。

---

阶段 1：收集输入（第 1-2 天）

目标： 收集业务目标、客户问题、技术限制和利益相关者请求。

活动

1. 审查业务目标（OKR、战略计划）

• 来源： 公司 OKR、高管战略备忘录、董事会演示文稿
• 问题：
  • 公司今年的 3 项首要任务是什么？
  • 我们必须推动哪些指标？（收入、留存、获客、效率）
  • 是否有战略押注？（新市场、合作伙伴关系、产品线）
• 输出： 3-5 项需优化的业务成果

2. 审查客户问题（探索洞察）

• 来源： 探索访谈、支持工单、NPS 反馈、客户流失调查
• 使用： skills/discovery-process/SKILL.md 中的洞察（如近期已完成）
• 问题：
  • 客户最主要的 3-5 个痛点是什么？
  • 哪些问题影响的客户最多？
  • 哪些问题的影响最严重？
• 输出： 3-5 个经过验证的客户问题

3. 审查技术限制与机遇

• 来源： 工程领导层、技术债务评估
• 问题：
  • 是否存在技术阻碍？（扩展性、性能、安全性）
  • 是否有可赋能的投资？（平台升级、API 重写）
  • 技术路线图是什么？（迁移、弃用）
• 输出： 所需技术投资清单

4. 审查利益相关者请求

• 来源： 销售、市场营销、客户成功、高管
• 问题：
  • 销售团队提出了哪些需求？（企业功能、集成）
  • 市场营销团队提出了哪些请求？（增长计划、定位）
  • 客户成功团队指出了哪些问题？（流失风险、扩展阻碍）
• 输出： 利益相关者请求清单（尚未承诺）

阶段 1 的输出

• 业务成果： 3-5 项 OKR 或战略目标
• 客户问题： 3-5 个经过验证的痛点
• 技术投资： 平台／技术债务事项
• 利益相关者请求： 内部团队提出的功能请求

---

阶段 2：定义计划（Epic）（第 3-4 天）

目标： 将输入转化为 Epic，并为其制定假设、成功指标和工作量估算。

活动

1. 定义史诗假设

• 使用： skills/epic-hypothesis/SKILL.md（组件）
• 每项计划： 撰写假设陈述
• 格式：“我们相信，为 [用户角色] [构建 X] 将实现 [结果]，因为 [假设]。”
• **参与者：**PM
• **时长：**每个史诗 60 分钟
• **产出：**10-15 个史诗假设

SaaS 产品史诗示例：

Epic 1: Guided Onboarding
Hypothesis: We believe that adding a step-by-step onboarding checklist for non-technical users will increase activation rate from 40% to 60% because users currently drop off due to lack of guidance.

Success Metric: Activation rate (% completing first action within 24 hours)
Target: 40% → 60%

Epic 2: Enterprise SSO
Hypothesis: We believe that adding SSO for enterprise accounts will increase enterprise deals closed from 2/quarter to 5/quarter because enterprise buyers require SSO for security compliance.

Success Metric: Enterprise deals closed per quarter
Target: 2 → 5

Epic 3: Mobile-Optimized Workflows
Hypothesis: We believe that optimizing core workflows for mobile will increase mobile DAU from 5% to 20% because mobile-first users currently can't complete workflows on the go.

Success Metric: Mobile DAU as % of total DAU
Target: 5% → 20%

2. 估算工作量（T 恤尺码法）

• **参与者：**PM + 工程负责人
• **时长：**90 分钟
• 方法：
  • **小（S）：**1-2 周（1-2 名工程师）
  • **中（M）：**3-4 周（2-3 名工程师）
  • **大（L）：**2-3 个月（3-5 名工程师）
  • **特大（XL）：**3+ 个月（5+ 名工程师）
• **产出：**每个史诗的工作量估算

3. 映射到业务成果

• **每个史诗：**标记其主要业务成果
• 示例：
  • 史诗 1（引导式入门）→ 留存
  • 史诗 2（企业 SSO）→ 获客（企业）
  • 史诗 3（移动工作流）→ 参与度

第 2 阶段的产出

• **10-15 个史诗：**每个都包含假设、成功指标和工作量估算
• **业务成果映射：**哪些史诗推动哪些 OKR

---

第 3 阶段：确定计划优先级（第 5 天）

**目标：**根据影响、工作量和战略契合度对史诗进行排序。

活动

1. 选择优先级排序框架

• 使用： skills/prioritization-advisor/SKILL.md（交互式）
• **参与者：**PM
• **时长：**30 分钟
• **产出：**推荐框架（RICE、ICE、价值/工作量等）

2. 为史诗评分

• **参与者：**PM、工程负责人、产品领导层
• **时长：**120 分钟
• **方法：**对所有史诗应用该框架
• 示例（RICE 评分）：

史诗	覆盖人数	影响	信心	工作量	RICE 分数
引导式入门	10,000 名用户	3（巨大）	80%	1 个月	24,000
企业 SSO	500 名用户	3（巨大）	90%	2 个月	675
移动工作流	5,000 名用户	2（高）	60%	3 个月	2,000
高级报告	2,000 名用户	2（高）	50%	2 个月	1,000

3. 根据战略契合度调整

• **审查评分：**是否与业务目标一致？
• **战略性调整：**提高与战略重点一致的史诗优先级（即使分数较低）
• **示例：**企业 SSO 的评分较低，但它对企业扩张战略至关重要 → 提高优先级

第 3 阶段的产出

• **已排序的待办事项：**按优先级排列的史诗（RICE 分数 + 战略调整）
• **前 10 个史诗：**路线图中优先级最高的计划

---

第 4 阶段：排列路线图顺序（第 6-7 天）

**目标：**将史诗按逻辑依赖关系安排到各季度/版本中。

活动

1. 映射依赖关系

• 问题：
  • 史诗 B 是否依赖史诗 A？（例如，“高级报告”需要“数据管道升级”）
  • 是否存在技术阻碍？（例如，“移动应用”需要“API 重新设计”）
• **产出：**依赖关系图（史诗 A → 史诗 B → 史诗 C）

2. 按季度（或版本）排序

• **现在（Q1）：**优先级最高的 3-5 个史诗，无依赖关系
• **接下来（Q2）：**之后的 3-5 个史诗，可能依赖 Q1 完成
• **稍后（Q3+）：**其余史诗，信心较低

路线图示例（基于时间线）：

Q1 2026 (Now - Committed):
├─ Guided Onboarding (Retention)
├─ Enterprise SSO (Acquisition)
└─ Mobile-Optimized Workflows (Engagement)

Q2 2026 (Next - High Confidence):
├─ Advanced Reporting (depends on Data Pipeline, Q1)
├─ Slack Integration (Engagement)
└─ Pricing Page Redesign (Acquisition)

Q3 2026 (Later - Lower Confidence):
├─ Mobile App (depends on API Redesign)
├─ AI-Powered Recommendations
└─ Multi-Language Support

Q4 2026 (Exploration):
├─ Marketplace/Plugin Ecosystem
└─ Enterprise Onboarding Concierge

替代方案：现在/接下来/稍后路线图

NOW (Current Quarter):
- Guided Onboarding
- Enterprise SSO
- Mobile-Optimized Workflows

NEXT (Following Quarter):
- Advanced Reporting
- Slack Integration
- Pricing Page Redesign

LATER (Future):
- Mobile App
- AI Recommendations
- Multi-Language Support

3. 与工程团队验证

• **参与者：**PM + 工程负责人
• 问题：
  • 排序是否现实？（产能、依赖关系）
  • 是否存在未发现的技术阻碍？
  • 是否需要调整范围？
• **产出：**已验证的路线图顺序

第 4 阶段的产出

• **已排序的路线图：**按 Q1、Q2、Q3 安排的史诗
• **依赖关系图：**各项之间的依赖关系
• **产能检查：**工程团队确认该顺序可行

---

第 5 阶段：传达路线图（第 2 周）

**目标：**向利益相关者展示路线图、收集反馈并达成共识。

活动

1. 创建路线图演示文稿

• 形式： 30-45 分钟的演示
• 结构：
  • 幻灯片 1： 战略背景（业务目标、客户问题）
  • 幻灯片 2-3： 路线图概览（Q1、Q2、Q3）
  • 幻灯片 4-6： 深入介绍各季度（史诗级项目、假设、成功指标）
  • 幻灯片 7： 路线图中不包含的内容（及原因）
  • 幻灯片 8： 依赖关系和风险
• 参与者： PM、设计
• 准备时长： 2-3 小时

2. 向利益相关者演示

• 受众： 高管、产品负责人、工程、销售、营销、客户成功（CS）
• 时长： 45 分钟演示 + 15 分钟问答
• 重点：
  • 战略叙述：“这就是我们优先选择 X 而非 Y 的原因”
  • 关注结果：“每个史诗级项目都会带来[业务成果]”
  • 保持灵活：“这份路线图是计划，而非承诺；我们会根据学习情况进行调整”

3. 收集反馈

• 要提出的问题：
  • 这些优先事项是否符合业务目标？
  • 我们是否遗漏了关键的客户问题？
  • 依赖关系是否清晰？
  • 你有哪些顾虑？
• 产出： 反馈、顾虑和问题清单

4. 完善路线图

• 根据反馈： 调整优先级、添加遗漏的史诗级项目、明确依赖关系
• 时长： 1-2 天
• 产出： 最终路线图 v1.0

5. 发布路线图

• 内部： 与团队分享（Confluence、Notion、Productboard 等）
• 外部（可选）： 面向客户的公开路线图（采用 Now/Next/Later 格式）
• 形式： 可视化路线图 + 说明文档

阶段 5 的产出

• 路线图演示文稿： 30-45 分钟的演示文稿
• 利益相关者达成共识： 已纳入反馈并解决顾虑
• 已发布的路线图： 团队（内部）或客户（外部）可访问

---

完整工作流：端到端总结

Week 1:
├─ Day 1-2: Gather Inputs
│  ├─ Review business goals (OKRs)
│  ├─ Review customer problems (discovery insights)
│  ├─ Review technical constraints
│  └─ Review stakeholder requests
│
├─ Day 3-4: Define Initiatives (Epics)
│  ├─ skills/epic-hypothesis/SKILL.md (60 min per epic)
│  ├─ Estimate effort (90 min)
│  └─ Map to business outcomes
│
├─ Day 5: Prioritize Initiatives
│  ├─ skills/prioritization-advisor/SKILL.md (30 min)
│  ├─ Score epics (120 min)
│  └─ Adjust for strategic fit
│
└─ Day 6-7: Sequence Roadmap
   ├─ Map dependencies
   ├─ Sequence by quarter (Q1, Q2, Q3)
   └─ Validate with engineering

Week 2:
└─ Communicate Roadmap
   ├─ Create presentation (2-3 hours)
   ├─ Present to stakeholders (60 min)
   ├─ Gather feedback
   ├─ Refine roadmap (1-2 days)
   └─ Publish roadmap

总投入时间：

• 快速推进： 1 周（已有史诗级项目，快速达成共识）
• 通常情况： 1.5-2 周（定义史诗级项目，进行利益相关者评审）

---

示例

完整路线图示例请参阅 examples/sample.md。

迷你示例摘录：

Now: Guided onboarding (activation +20%)
Next: Enterprise SSO (deal velocity)
Later: Mobile workflows (DAU lift)

常见陷阱

陷阱 1：以功能为导向的路线图（没有成果）

症状： 路线图只列出功能（“深色模式”“SSO”“高级筛选”），没有背景说明

后果： 缺乏战略清晰度，利益相关者不理解“为什么”

解决方法： 将史诗级项目描述为带有成功指标的假设（而不只是功能名称）

---

陷阱 2：按 HiPPO（薪酬最高者的意见）确定优先级

症状： 高管指定路线图，没有基于数据确定优先级

后果： 做错事情，忽视客户问题

解决方法： 使用优先级框架（RICE、ICE）对史诗级项目进行透明评分

---

陷阱 3：把路线图当作承诺（瀑布式思维）

症状： 把路线图视为合同，没有调整的灵活性

后果： 获得新信息后无法转向

解决方法： 将路线图描述为“战略计划，并会根据学习情况进行调整”

---

陷阱 4：没有梳理依赖关系

症状： 排列史诗级项目的顺序时，没有检查技术依赖关系

后果： Q1 的依赖项未完成，导致 Q2 的史诗级项目受阻

解决方法： 在阶段 4 明确梳理依赖关系，并与工程团队确认

---

陷阱 5：PM 独自制定路线图（没有利益相关者参与）

症状： PM 独自创建路线图，然后展示已完成的计划

后果： 无法获得支持，利益相关者感到被排除在外

解决方法： 在阶段 1 收集所有利益相关者的意见，并在阶段 5 展示草案以征求反馈

---

参考资料

相关技能（由此工作流编排）

阶段 2：

• skills/epic-hypothesis/SKILL.md（组件）

阶段 3：

• skills/prioritization-advisor/SKILL.md（交互式）

阶段 4：

• （手动梳理依赖项，无特定技能）

阶段 5：

• （手动创建演示文稿，无特定技能）

可选/相关：

• skills/product-strategy-session/SKILL.md（工作流）— 在路线图规划前运行，以确立策略
• skills/discovery-process/SKILL.md（工作流）— 为阶段 1 提供客户问题输入
• skills/user-story-mapping-workshop/SKILL.md（交互式）— 适用于需要发布规划的复杂 Epic

外部框架

• Bruce McCarthy，《Product Roadmaps Relaunched》（2017）— 以结果为导向的路线图
• C. Todd Lombardo，《Product Roadmaps Relaunched》（2017）— Now/Next/Later 框架
• Intercom，“RICE Prioritization”（2016）— 优先级排序框架

Dean 的工作

• [如果 Dean 有路线图规划资源，请在此添加链接]

---

技能类型： 工作流 建议文件名： roadmap-planning.md 建议位置： /skills/workflows/ 依赖项： 编排 skills/epic-hypothesis/SKILL.md、skills/prioritization-advisor/SKILL.md，以及手动活动