Back to Details

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:
  1. Gathering inputs — Customer problems, business goals, technical constraints
  2. Defining initiatives — Epics with clear hypotheses and success metrics
  3. Prioritizing — Rank initiatives by impact, effort, strategic fit
  4. Sequencing — Organize into releases/quarters with logical dependencies
  5. Communicating — Present roadmap to stakeholders with strategic narrative
路线图规划是一个包含以下步骤的流程：
  1. 收集输入信息 —— 客户问题、业务目标、技术约束
  2. 定义举措 —— 带有明确假设和成功指标的Epics
  3. 优先级排序 —— 根据影响、投入、战略契合度对举措排名
  4. 排序规划 —— 按逻辑依赖关系组织为发布版本/季度
  5. 沟通传达 —— 向利益相关者展示带有战略叙事的路线图

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):
EpicReachImpactConfidenceEffortRICE Score
Guided Onboarding10,000 users3 (massive)80%1 month24,000
Enterprise SSO500 users3 (massive)90%2 months675
Mobile Workflows5,000 users2 (high)60%3 months2,000
Advanced Reporting2,000 users2 (high)50%2 months1,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
企业SSO500用户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)

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

Phase 2:
  • skills/epic-hypothesis/SKILL.md
    (component)
Phase 3:
  • skills/prioritization-advisor/SKILL.md
    (interactive)
Phase 4:
  • (Dependencies mapped manually, no specific skill)
Phase 5:
  • (Presentation created manually, no specific skill)
Optional/Related:
  • skills/product-strategy-session/SKILL.md
    (workflow) — Run before roadmap planning to establish strategy
  • skills/discovery-process/SKILL.md
    (workflow) — Provides customer problem inputs for Phase 1
  • skills/user-story-mapping-workshop/SKILL.md
    (interactive) — For complex epics requiring release planning
阶段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
    （交互式）—— 用于需要发布规划的复杂Epics

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
，以及手动活动