roadmap-planning

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Purpose

目标

Guide product managers through strategic roadmap planning by orchestrating prioritization, epic definition, stakeholder alignment, and release sequencing skills into a structured process. Use this to move from disconnected feature requests to a cohesive, outcome-driven roadmap that aligns stakeholders, sequences work logically, and communicates strategic intent—avoiding "feature factory" roadmaps that lack strategic narrative or customer-centric framing.

This is not a Gantt chart—it's a strategic communication tool that shows what you're building, why it matters, and how it ladders up to business outcomes.

通过将优先级排序、Epic定义、利益相关者对齐和发布排序等技能整合为结构化流程，为产品经理提供战略路线图规划指导。借助本指南，你可以从零散的功能请求转变为一个连贯的、以结果为导向的路线图，实现利益相关者对齐、工作逻辑排序，并传达战略意图——避免陷入缺乏战略叙事或以客户为中心框架的“功能工厂”式路线图。

这不是甘特图——它是一种战略沟通工具，展示你正在构建什么、为什么重要，以及如何助力业务成果达成。

Key Concepts

核心概念

What is Strategic Roadmap Planning?

什么是战略路线图规划？

Roadmap planning is the process of:

Gathering inputs — Customer problems, business goals, technical constraints
Defining initiatives — Epics with clear hypotheses and success metrics
Prioritizing — Rank initiatives by impact, effort, strategic fit
Sequencing — Organize into releases/quarters with logical dependencies
Communicating — Present roadmap to stakeholders with strategic narrative

路线图规划是一个包含以下步骤的流程：

收集输入信息 —— 客户问题、业务目标、技术约束
定义举措 —— 带有明确假设和成功指标的Epics
优先级排序 —— 根据影响、投入、战略契合度对举措排名
排序规划 —— 按逻辑依赖关系组织为发布版本/季度
沟通传达 —— 向利益相关者展示带有战略叙事的路线图

Types of Roadmaps

路线图类型

Now/Next/Later Roadmap:

Now: Current quarter (committed)
Next: Following quarter (high confidence)
Later: Future exploration (low confidence)
Best for: Agile teams, uncertainty, continuous discovery

Theme-Based Roadmap:

Organize by strategic themes (e.g., "Retention," "Enterprise Expansion," "Mobile Experience")
Best for: Communicating to execs, showing strategic intent

Timeline Roadmap (Quarters):

Q1: Epics A, B; Q2: Epics C, D; Q3: Epics E, F
Best for: Resource planning, stakeholder communication

Feature-Based Roadmap (Anti-Pattern):

Lists features without context (e.g., "Dark mode," "SSO," "Advanced reporting")
Why it fails: No strategic narrative, no customer problems framed

Now/Next/Later路线图：

Now（当前）： 本季度（已承诺）
Next（下一阶段）： 下一季度（高确定性）
Later（未来）： 未来探索（低确定性）
最佳适用场景： 敏捷团队、不确定性环境、持续探索

基于主题的路线图：

按战略主题组织（例如：“留存”、“企业拓展”、“移动端体验”）
最佳适用场景： 向高管汇报、传达战略意图

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

Q1：Epic A、B；Q2：Epic C、D；Q3：Epic E、F
最佳适用场景： 资源规划、利益相关者沟通

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

仅列出功能而无上下文（例如：“深色模式”、“SSO”、“高级报表”）
失败原因： 缺乏战略叙事，未围绕客户问题构建

Why This Works

本方法的优势

Outcome-driven: Ties initiatives to business/customer outcomes
Stakeholder alignment: Transparent process reduces political friction
Strategic clarity: Shows not just "what" but "why"
Flexible: Adapts as you learn from discovery/delivery

以结果为导向： 将举措与业务/客户成果关联
利益相关者对齐： 透明流程减少政治摩擦
战略清晰： 不仅展示“做什么”，还说明“为什么”
灵活性： 可根据探索/交付中的学习成果调整

Anti-Patterns (What This Is NOT)

反模式（本方法不适用的情况）

Not a commitment: Roadmaps are strategic plans, not contracts
Not a feature list: Roadmaps frame problems, not just solutions
Not waterfall: Roadmaps evolve quarterly based on learning

不是承诺： 路线图是战略规划，而非合同
不是功能列表： 路线图围绕问题构建，而非仅展示解决方案
不是瀑布模式： 路线图会根据季度学习成果不断演进

When to Use This

适用场景

Annual or quarterly planning cycles
After product strategy session (translate strategy to roadmap)
Onboarding new stakeholders (align on direction)
Reframing existing roadmap (shift from feature-driven to outcome-driven)

年度或季度规划周期
产品战略会议之后（将战略转化为路线图）
新利益相关者入职（对齐方向）
重构现有路线图（从功能驱动转向结果驱动）

When NOT to Use This

不适用场景

For tactical sprint planning (use backlog instead)
When strategy is unclear (run product-strategy-session first)
When stakeholders expect date commitments (address expectations first)

战术性冲刺规划（改用待办事项列表）
战略不明确时（先开展产品战略会议）
利益相关者期望明确日期承诺时（先解决期望问题）

Facilitation Source of Truth

引导式沟通的参考标准

When running this workflow as a guided conversation, use

workshop-facilitation

as the interaction protocol.

It defines:

session heads-up + entry mode (Guided, Context dump, Best guess)
one-question turns with plain-language prompts
progress labels (for example, Context Qx/8 and Scoring Qx/5)
interruption handling and pause/resume behavior
numbered recommendations at decision points
quick-select numbered response options for regular questions (include
```
Other (specify)
```
when useful)

This file defines the workflow sequence and domain-specific outputs. If there is a conflict, follow this file's workflow logic.

当以引导式对话形式运行此工作流时，请使用

workshop-facilitation

作为交互协议。

它定义了：

会议提前通知+参与模式（引导式、上下文导入、最佳猜测）
单轮提问，使用通俗易懂的提示语
进度标签（例如：上下文问题 Qx/8、评分问题 Qx/5）
中断处理和暂停/恢复机制
决策点的编号建议
常规问题的快速选择编号响应选项（必要时包含“其他（请说明）”）

本文件定义了工作流序列和特定领域的输出。若存在冲突，请遵循本文件的工作流逻辑。

Application

应用

Use

template.md

for the full fill-in structure.

This workflow orchestrates 5 phases over 1-2 weeks, using multiple component and interactive skills.

使用

template.md

获取完整的填充式结构。

此工作流在1-2周内分为5个阶段，整合了多个组件和交互式技能。

Phase 1: Gather Inputs (Day 1-2)

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

Goal: Collect business goals, customer problems, technical constraints, stakeholder requests.

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

Activities

活动

1. Review Business Goals (OKRs, Strategic Initiatives)

Source: Company OKRs, exec strategy memos, board decks
Questions:
- What are the company's top 3 priorities this year?
- What metrics must we move? (revenue, retention, acquisition, efficiency)
- Are there strategic bets? (new markets, partnerships, product lines)
Output: 3-5 business outcomes to optimize for

2. Review Customer Problems (Discovery Insights)

Source: Discovery interviews, support tickets, NPS feedback, churn surveys
Use: Insights from
```
skills/discovery-process/SKILL.md
```
(if recently completed)
Questions:
- What are the top 3-5 customer pain points?
- Which problems affect the most customers?
- Which problems have highest intensity?
Output: 3-5 validated customer problems

3. Review Technical Constraints & Opportunities

Source: Engineering leadership, tech debt assessments
Questions:
- Are there technical blockers? (scaling, performance, security)
- Are there enabling investments? (platform upgrades, API rewrites)
- What's the technical roadmap? (migrations, deprecations)
Output: List of technical investments required

4. Review Stakeholder Requests

Source: Sales, marketing, customer success, execs
Questions:
- What are sales asking for? (enterprise features, integrations)
- What's marketing requesting? (growth initiatives, positioning)
- What's customer success flagging? (churn risks, expansion blockers)
Output: List of stakeholder requests (not yet committed)

1. 回顾业务目标（OKRs、战略举措）

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

2. 回顾客户问题（探索洞察）

来源： 探索性访谈、支持工单、NPS反馈、流失调查
参考：
```
skills/discovery-process/SKILL.md
```
的洞察（如果近期已完成）
问题：
- 前3-5个客户痛点是什么？
- 哪些问题影响最多客户？
- 哪些问题的影响程度最高？
输出： 3-5个经过验证的客户问题

3. 回顾技术约束与机遇

来源： 工程负责人、技术债务评估
问题：
- 是否存在技术障碍？（扩展性、性能、安全）
- 是否有赋能型投入？（平台升级、API重写）
- 技术路线图是什么？（迁移、弃用）
输出： 所需技术投入列表

4. 回顾利益相关者请求

来源： 销售、营销、客户成功、高管
问题：
- 销售团队的需求是什么？（企业功能、集成）
- 营销团队的请求是什么？（增长举措、定位）
- 客户成功团队标记了什么问题？（流失风险、拓展障碍）
输出： 利益相关者请求列表（尚未承诺）

Outputs from Phase 1

阶段1输出

Business outcomes: 3-5 OKRs or strategic goals
Customer problems: 3-5 validated pain points
Technical investments: Platform/tech debt items
Stakeholder requests: Feature requests from internal teams

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

Phase 2: Define Initiatives (Epics) (Day 3-4)

阶段2：定义举措（Epics）（第3-4天）

Goal: Turn inputs into epics with hypotheses, success metrics, and effort estimates.

目标： 将输入信息转化为带有假设、成功指标和投入估算的Epics。

Activities

活动

1. Define Epic Hypotheses

Use:
```
skills/epic-hypothesis/SKILL.md
```
(component)
For each initiative: Write hypothesis statement
Format: "We believe that [building X] for [persona] will achieve [outcome] because [assumption]."
Participants: PM
Duration: 60 minutes per epic
Output: 10-15 epic hypotheses

Example Epics (SaaS Product):

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. Estimate Effort (T-Shirt Sizing)

Participants: PM + engineering lead
Duration: 90 minutes
Method:
- Small (S): 1-2 weeks (1-2 engineers)
- Medium (M): 3-4 weeks (2-3 engineers)
- Large (L): 2-3 months (3-5 engineers)
- Extra Large (XL): 3+ months (5+ engineers)
Output: Effort estimate per epic

3. Map to Business Outcomes

For each epic: Tag with primary business outcome
Example:
- Epic 1 (Guided Onboarding) → Retention
- Epic 2 (Enterprise SSO) → Acquisition (enterprise)
- Epic 3 (Mobile Workflows) → Engagement

1. 定义Epic假设

参考：
```
skills/epic-hypothesis/SKILL.md
```
（组件）
针对每个举措： 撰写假设陈述
格式： “我们认为，为[用户角色]构建[X]将实现[成果]，因为[假设依据]。”
参与者： 产品经理
时长： 每个Epic 60分钟
输出： 10-15个Epic假设

示例Epics（SaaS产品）：

Epic 1：引导式入职
假设：我们认为，为非技术用户添加分步入职清单将使激活率从40%提升至60%，因为当前用户因缺乏指导而流失。

成功指标：激活率（24小时内完成首次操作的用户占比）
目标：40% → 60%

Epic 2：企业SSO
假设：我们认为，为企业账户添加SSO将使每季度完成的企业交易从2笔提升至5笔，因为企业买家需要SSO以满足安全合规要求。

成功指标：每季度完成的企业交易数
目标：2 → 5

Epic 3：移动端优化工作流
假设：我们认为，针对移动端优化核心工作流将使移动端日活跃用户占比从5%提升至20%，因为移动优先用户目前无法在移动端完成工作流。

成功指标：移动端日活跃用户占总日活跃用户的比例
目标：5% → 20%

2. 投入估算（T恤尺码法）

参与者： 产品经理 + 工程负责人
时长： 90分钟
方法：
- 小（S）： 1-2周（1-2名工程师）
- 中（M）： 3-4周（2-3名工程师）
- 大（L）： 2-3个月（3-5名工程师）
- 超大（XL）： 3个月以上（5名以上工程师）
输出： 每个Epic的投入估算

3. 关联业务成果

针对每个Epic： 标记其对应的核心业务成果
示例：
- Epic 1（引导式入职）→ 留存
- Epic 2（企业SSO）→ 获客（企业端）
- Epic 3（移动端工作流）→ 参与度

Outputs from Phase 2

阶段2输出

10-15 epics: Each with hypothesis, success metric, effort estimate
Business outcome mapping: Which epics drive which OKRs

10-15个Epics： 每个都包含假设、成功指标、投入估算
业务成果映射： 哪些Epics推动哪些OKRs

Phase 3: Prioritize Initiatives (Day 5)

阶段3：优先级排序举措（第5天）

Goal: Rank epics by impact, effort, and strategic fit.

目标： 根据影响、投入和战略契合度对Epics排名。

Activities

活动

1. Choose Prioritization Framework

Use:
```
skills/prioritization-advisor/SKILL.md
```
(interactive)
Participants: PM
Duration: 30 minutes
Output: Recommended framework (RICE, ICE, Value/Effort, etc.)

2. Score Epics

Participants: PM, engineering lead, product leadership
Duration: 120 minutes
Method: Apply framework to all epics
Example (RICE scoring):

Epic	Reach	Impact	Confidence	Effort	RICE Score
Guided Onboarding	10,000 users	3 (massive)	80%	1 month	24,000
Enterprise SSO	500 users	3 (massive)	90%	2 months	675
Mobile Workflows	5,000 users	2 (high)	60%	3 months	2,000
Advanced Reporting	2,000 users	2 (high)	50%	2 months	1,000

3. Adjust for Strategic Fit

Review scores: Do they align with business goals?
Strategic overrides: Promote epics that align with strategic bets (even if score is lower)
Example: Enterprise SSO scores lower, but it's critical for enterprise expansion strategy → boost priority

1. 选择优先级排序框架

参考：
```
skills/prioritization-advisor/SKILL.md
```
（交互式）
参与者： 产品经理
时长： 30分钟
输出： 推荐框架（RICE、ICE、价值/投入等）

2. 为Epics评分

参与者： 产品经理、工程负责人、产品领导层
时长： 120分钟
方法： 将框架应用于所有Epics
示例（RICE评分）：

Epic	覆盖用户数	影响	置信度	投入	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. 基于战略契合度调整

回顾评分： 评分是否与业务目标对齐？
战略调整： 优先推进与战略赌注契合的Epics（即使评分较低）
示例： 企业SSO评分较低，但对企业拓展战略至关重要 → 提升优先级

Outputs from Phase 3

阶段3输出

Ranked backlog: Epics sorted by priority (RICE score + strategic adjustments)
Top 10 epics: Highest-priority initiatives for roadmap

排序后的待办事项列表： 按优先级排序的Epics（RICE评分 + 战略调整）
前10个Epics： 路线图的最高优先级举措

Phase 4: Sequence Roadmap (Day 6-7)

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

Goal: Organize epics into quarters/releases with logical dependencies.

目标： 按季度/发布版本组织Epics，考虑逻辑依赖关系。

Activities

活动

1. Map Dependencies

Questions:
- Does Epic B depend on Epic A? (e.g., "Advanced Reporting" requires "Data Pipeline Upgrade")
- Are there technical blockers? (e.g., "Mobile App" requires "API Redesign")
Output: Dependency graph (Epic A → Epic B → Epic C)

2. Sequence by Quarter (or Release)

Now (Q1): Top 3-5 epics, no dependencies
Next (Q2): Next 3-5 epics, may depend on Q1 completion
Later (Q3+): Remaining epics, lower confidence

Example Roadmap (Timeline-Based):

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

Alternative: Now/Next/Later Roadmap

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. Validate with Engineering

Participants: PM + engineering lead
Questions:
- Is sequencing realistic? (capacity, dependencies)
- Are there hidden technical blockers?
- Do we need to adjust scope?
Output: Validated roadmap sequence

1. 映射依赖关系

问题：
- Epic B是否依赖Epic A？（例如：“高级报表”依赖“数据管道升级”）
- 是否存在技术障碍？（例如：“移动端应用”依赖“API重设计”）
输出： 依赖关系图（Epic A → Epic B → Epic C）

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

Now（Q1）： 前3-5个无依赖的Epics
Next（Q2）： 接下来3-5个Epics，可能依赖Q1的完成情况
Later（Q3+）： 剩余Epics，确定性较低

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

2026年Q1（Now - 已承诺）：
├─ 引导式入职（留存）
├─ 企业SSO（获客）
└─ 移动端优化工作流（参与度）

2026年Q2（Next - 高确定性）：
├─ 高级报表（依赖Q1的数据管道）
├─ Slack集成（参与度）
└─ 定价页面重设计（获客）

2026年Q3（Later - 低确定性）：
├─ 移动端应用（依赖API重设计）
├─ AI驱动推荐
└─ 多语言支持

2026年Q4（探索）：
├─ 市场/插件生态系统
└─ 企业入职 concierge

替代方案：Now/Next/Later路线图

NOW（当前季度）：
- 引导式入职
- 企业SSO
- 移动端优化工作流

NEXT（下一季度）：
- 高级报表
- Slack集成
- 定价页面重设计

LATER（未来）：
- 移动端应用
- AI推荐
- 多语言支持

3. 与工程团队验证

参与者： 产品经理 + 工程负责人
问题：
- 排序是否现实？（产能、依赖关系）
- 是否存在隐藏的技术障碍？
- 是否需要调整范围？
输出： 验证后的路线图排序

Outputs from Phase 4

阶段4输出

Sequenced roadmap: Epics organized by Q1, Q2, Q3
Dependency map: What depends on what
Capacity check: Engineering agrees sequence is feasible

排序后的路线图： 按Q1、Q2、Q3组织的Epics
依赖关系图： 各Epics之间的依赖关系
产能确认： 工程团队认可排序的可行性

Phase 5: Communicate Roadmap (Week 2)

阶段5：沟通路线图（第2周）

Goal: Present roadmap to stakeholders, gather feedback, build alignment.

目标： 向利益相关者展示路线图，收集反馈，建立对齐。

Activities

活动

1. Create Roadmap Presentation

Format: 30-45 min presentation
Structure:
- Slide 1: Strategic context (business goals, customer problems)
- Slide 2-3: Roadmap overview (Q1, Q2, Q3)
- Slide 4-6: Deep dive per quarter (epics, hypotheses, success metrics)
- Slide 7: What's NOT on roadmap (and why)
- Slide 8: Dependencies and risks
Participants: PM, design
Duration: 2-3 hours to prepare

2. Present to Stakeholders

Audience: Execs, product leadership, engineering, sales, marketing, CS
Duration: 45 min presentation + 15 min Q&A
Focus:
- Strategic narrative: "Here's why we're prioritizing X over Y"
- Outcome focus: "Each epic drives [business outcome]"
- Flexibility: "This roadmap is a plan, not a commitment; we'll adjust as we learn"

3. Gather Feedback

Questions to ask:
- Do these priorities align with business goals?
- Are we missing critical customer problems?
- Are dependencies clear?
- What concerns do you have?
Output: List of feedback, concerns, questions

4. Refine Roadmap

Based on feedback: Adjust priorities, add missing epics, clarify dependencies
Duration: 1-2 days
Output: Final roadmap v1.0

5. Publish Roadmap

Internal: Share with team (Confluence, Notion, Productboard, etc.)
External (Optional): Public roadmap for customers (use Now/Next/Later format)
Format: Visual roadmap + narrative doc

1. 创建路线图演示文稿

格式： 30-45分钟演示
结构：
- 第1页： 战略背景（业务目标、客户问题）
- 第2-3页： 路线图概述（Q1、Q2、Q3）
- 第4-6页： 各季度深入讲解（Epics、假设、成功指标）
- 第7页： 路线图中未包含的内容（及原因）
- 第8页： 依赖关系和风险
参与者： 产品经理、设计师
时长： 2-3小时准备

2. 向利益相关者展示

受众： 高管、产品领导层、工程团队、销售、营销、客户成功
时长： 45分钟演示 + 15分钟问答
重点：
- 战略叙事：“我们为什么优先选择X而非Y”
- 结果导向：“每个Epic都推动[业务成果]”
- 灵活性：“本路线图是规划而非承诺；我们会根据学习成果调整”

3. 收集反馈

提问：
- 这些优先级是否与业务目标对齐？
- 我们是否遗漏了关键客户问题？
- 依赖关系是否清晰？
- 你有哪些顾虑？
输出： 反馈、顾虑、问题列表

4. 优化路线图

基于反馈： 调整优先级、添加遗漏的Epics、明确依赖关系
时长： 1-2天
输出： 最终路线图v1.0

5. 发布路线图

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

Outputs from Phase 5

阶段5输出

Roadmap presentation: 30-45 min deck
Stakeholder alignment: Feedback incorporated, concerns addressed
Published roadmap: Accessible to team (internal) or customers (external)

路线图演示文稿： 30-45分钟的演示文稿
利益相关者对齐： 已整合反馈、解决顾虑
已发布路线图： 团队可访问（内部）或客户可访问（外部）

Complete Workflow: End-to-End Summary

完整工作流：端到端总结

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

Total Time Investment:

Fast track: 1 week (existing epics, quick alignment)
Typical: 1.5-2 weeks (define epics, stakeholder review)

第1周：
├─ 第1-2天：收集输入信息
│  ├─ 回顾业务目标（OKRs）
│  ├─ 回顾客户问题（探索洞察）
│  ├─ 回顾技术约束
│  └─ 回顾利益相关者请求
│
├─ 第3-4天：定义举措（Epics）
│  ├─ skills/epic-hypothesis/SKILL.md（每个Epic 60分钟）
│  ├─ 投入估算（90分钟）
│  └─ 关联业务成果
│
├─ 第5天：优先级排序举措
│  ├─ skills/prioritization-advisor/SKILL.md（30分钟）
│  ├─ 为Epics评分（120分钟）
│  └─ 基于战略契合度调整
│
└─ 第6-7天：路线图排序规划
   ├─ 映射依赖关系
   ├─ 按季度排序（Q1、Q2、Q3）
   └─ 与工程团队验证

第2周：
└─ 沟通路线图
   ├─ 创建演示文稿（2-3小时）
   ├─ 向利益相关者展示（60分钟）
   ├─ 收集反馈
   ├─ 优化路线图（1-2天）
   └─ 发布路线图

总时间投入：

快速通道： 1周（已有Epics、快速对齐）
典型情况： 1.5-2周（定义Epics、利益相关者评审）

Examples

示例

See

examples/sample.md

for full roadmap examples.

Mini example excerpt:

markdown

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

查看

examples/sample.md

获取完整路线图示例。

迷你示例节选：

markdown

Now：引导式入职（激活率提升20%）
Next：企业SSO（交易速度提升）
Later：移动端工作流（日活跃用户提升）

Common Pitfalls

常见陷阱

Pitfall 1: Feature-Driven Roadmap (No Outcomes)

陷阱1：功能驱动的路线图（无成果关联）

Symptom: Roadmap lists features ("Dark mode," "SSO," "Advanced filters") with no context

Consequence: No strategic clarity, stakeholders don't understand "why"

Fix: Frame epics as hypotheses with success metrics (not just feature names)

症状： 路线图仅列出功能（“深色模式”、“SSO”、“高级筛选”）而无上下文

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

解决方案： 将Epics构建为带有成功指标的假设（而非仅功能名称）

Pitfall 2: Prioritizing by HiPPO (Highest Paid Person's Opinion)

陷阱2：按HiPPO（最高薪酬人员意见）优先级排序

Symptom: Execs dictate roadmap, no data-driven prioritization

Consequence: Build wrong things, ignore customer problems

Fix: Use prioritization framework (RICE, ICE) to transparently score epics

症状： 高管主导路线图，无数据驱动的优先级排序

后果： 构建错误的功能，忽略客户问题

解决方案： 使用优先级排序框架（RICE、ICE）透明地为Epics评分

Pitfall 3: Roadmap as Commitment (Waterfall Thinking)

陷阱3：将路线图视为承诺（瀑布思维）

Symptom: Roadmap treated as contract, no flexibility to adjust

Consequence: Can't pivot when you learn new information

Fix: Communicate roadmap as "strategic plan, subject to change based on learning"

症状： 路线图被视为合同，无调整灵活性

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

解决方案： 传达路线图是“基于学习成果可调整的战略规划”

Pitfall 4: No Dependencies Mapped

陷阱4：未映射依赖关系

Symptom: Sequence epics without checking technical dependencies

Consequence: Q2 epic blocked because Q1 dependency didn't finish

Fix: Map dependencies explicitly in Phase 4, validate with engineering

症状： 排序Epics时未检查技术依赖关系

后果： Q2的Epic因Q1的依赖项未完成而受阻

解决方案： 在阶段4中明确映射依赖关系，并与工程团队验证

Pitfall 5: Solo PM Roadmap (No Stakeholder Input)

陷阱5：产品经理独自制定路线图（无利益相关者输入）

Symptom: PM creates roadmap alone, presents finished plan

Consequence: No buy-in, stakeholders feel excluded

Fix: Gather inputs (Phase 1) from all stakeholders, present draft (Phase 5) for feedback

症状： 产品经理独自创建路线图，展示成品计划

后果： 缺乏认可，利益相关者感到被排除在外

解决方案： 在阶段1中收集所有利益相关者的输入，在阶段5中展示草稿以获取反馈

References

参考

Related Skills (Orchestrated by This Workflow)

External Frameworks

外部框架

Bruce McCarthy, Product Roadmaps Relaunched (2017) — Outcome-driven roadmaps
C. Todd Lombardo, Product Roadmaps Relaunched (2017) — Now/Next/Later framework
Intercom, "RICE Prioritization" (2016) — Prioritization framework

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

Dean's Work

Dean的相关工作

[If Dean has roadmap planning resources, link here]

Skill type: Workflow Suggested filename:

roadmap-planning.md

Suggested placement:

/skills/workflows/

Dependencies: Orchestrates

skills/epic-hypothesis/SKILL.md

skills/prioritization-advisor/SKILL.md

, plus manual activities

[若Dean有路线图规划资源，请在此处链接]

技能类型： 工作流 建议文件名：

roadmap-planning.md

建议存放位置：

/skills/workflows/

依赖： 整合

skills/epic-hypothesis/SKILL.md

、

skills/prioritization-advisor/SKILL.md

，以及手动活动

roadmap-planning

Original

Translation

Purpose

目标

Key Concepts

核心概念

What is Strategic Roadmap Planning?

什么是战略路线图规划？

Types of Roadmaps

路线图类型

Why This Works

本方法的优势

Anti-Patterns (What This Is NOT)

反模式（本方法不适用的情况）

When to Use This

适用场景

When NOT to Use This

不适用场景

Facilitation Source of Truth

引导式沟通的参考标准

Application

应用

Phase 1: Gather Inputs (Day 1-2)

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

Activities

活动

Outputs from Phase 1

阶段1输出

Phase 2: Define Initiatives (Epics) (Day 3-4)

阶段2：定义举措（Epics）（第3-4天）

Activities

活动

Outputs from Phase 2

阶段2输出

Phase 3: Prioritize Initiatives (Day 5)

阶段3：优先级排序举措（第5天）

Activities

活动

Outputs from Phase 3

阶段3输出

Phase 4: Sequence Roadmap (Day 6-7)

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

Activities

活动

Outputs from Phase 4

阶段4输出

Phase 5: Communicate Roadmap (Week 2)

阶段5：沟通路线图（第2周）

Activities

活动

Outputs from Phase 5

阶段5输出

Complete Workflow: End-to-End Summary

完整工作流：端到端总结

Examples

示例

Common Pitfalls

常见陷阱

Pitfall 1: Feature-Driven Roadmap (No Outcomes)

陷阱1：功能驱动的路线图（无成果关联）

Pitfall 2: Prioritizing by HiPPO (Highest Paid Person's Opinion)

陷阱2：按HiPPO（最高薪酬人员意见）优先级排序

Pitfall 3: Roadmap as Commitment (Waterfall Thinking)

陷阱3：将路线图视为承诺（瀑布思维）

Pitfall 4: No Dependencies Mapped

陷阱4：未映射依赖关系

Pitfall 5: Solo PM Roadmap (No Stakeholder Input)

陷阱5：产品经理独自制定路线图（无利益相关者输入）

References

参考

Related Skills (Orchestrated by This Workflow)

相关技能（本工作流整合）

External Frameworks

外部框架

Dean's Work

Dean的相关工作