Back to Details

roadmap-planning

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Roadmap Planning

路线图规划

Take a pile of ideas, requests, and ongoing work. Produce a defensible plan for what to ship, when, and why. The output is a roadmap document plus the prioritization work that made it credible.
将零散的创意、需求和正在开展的工作整合起来，产出一份关于交付内容、时间及原因的可信计划。输出物为路线图文档，以及支撑其可信度的优先级划分依据。

When to use

使用场景

  • Planning the next quarter or the next year
  • Sequencing work where some items depend on others
  • Balancing new builds, improvements, and maintenance
  • Saying no (or "not yet") to specific requests with a defensible reason
  • Aligning a team around a single shared plan
  • Communicating the plan to stakeholders outside the team
  • Replanning after a strategy shift, a missed quarter, or new constraints
  • 规划下一季度或下一年度工作
  • 对存在依赖关系的工作进行排序
  • 平衡新功能开发、优化与维护工作
  • 以可信理由拒绝（或推迟）特定需求
  • 让团队围绕统一计划达成共识
  • 向团队外部的利益相关方传达计划
  • 战略调整、季度目标未达成或出现新约束时重新规划

When NOT to use

不适用于以下场景

  • Specifying a single feature for development (use 
    pm-spec-writing
    )
  • Validating whether the idea is worth building (use 
    ux-research
    )
  • Designing the feature itself (use 
    design-standards
    )
  • Writing the launch plan for a single initiative (use 
    launch-runbook
    )
  • Reviewing what shipped vs what was promised (use 
    after-action-report
    )
  • 制定单个功能的开发规范（使用
    pm-spec-writing
    ）
  • 验证创意是否值得开发（使用
    ux-research
    ）
  • 功能设计本身（使用
    design-standards
    ）
  • 编写单个项目的发布计划（使用
    launch-runbook
    ）
  • 复盘已交付内容与承诺内容的差异（使用
    after-action-report
    ）

Required inputs

必要输入

  • The team's strategy or top-level goals (1 to 5 OKRs, themes, or pillars)
  • The backlog: every candidate item, with at least a one-sentence description
  • The team's capacity (people × time)
  • Known constraints (deadlines, dependencies, hiring, budget)
  • The planning horizon (a quarter, two quarters, a year)
If the strategy is missing, the roadmap will be a list of features, not a plan. Push back and get the strategy first. A roadmap without strategy is just a queue.
  • 团队的战略或顶层目标（1-5个OKR、主题或核心方向）
  • 待办清单：所有候选项目，至少包含一句话描述
  • 团队产能（人员×时间）
  • 已知约束（截止日期、依赖关系、招聘计划、预算）
  • 规划周期（一个季度、两个季度或一年）
若缺少战略方向，路线图将只是功能列表而非计划。需先获取明确的战略方向再推进。没有战略支撑的路线图只是一个待办队列。

The framework: 5 layers

框架：5个层级

Roadmaps fail at five different layers. A roadmap is only as good as its weakest one.
路线图的失败可能发生在五个不同层级，其质量取决于最薄弱的那个层级。

Layer 1: Themes (the WHY)

层级1：主题（核心目标）

Top-level groupings tied to strategy. Every theme answers: "If we do nothing else this period, this is the outcome we want."
Good themes are:
  • Outcome-shaped, not feature-shaped ("Reduce time-to-first-value" beats "Build onboarding")
  • Limited (3 to 5 max)
  • Defensible (you can explain why this and not something else)
  • Measurable (each maps to one or two metrics)
Bad themes look like a junk drawer: "Improvements," "Tech debt," "Misc." If it can't be defended in one sentence, it isn't a theme.
与战略绑定的顶层分类。每个主题都要回答：“如果本周期内我们只能完成一件事，这就是我们想要达成的结果。”
优质主题的特点：
  • 以结果为导向而非功能（如“缩短首次价值交付时间”优于“搭建新用户引导”）
  • 数量有限（最多3-5个）
  • 具备说服力（能解释为何选择这些而非其他）
  • 可衡量（每个主题对应1-2个指标）
劣质主题类似“杂物抽屉”：如“优化项”、“技术债务”、“其他”。如果无法用一句话证明其合理性，那就不能称之为主题。

Layer 2: Initiatives (the WHAT)

层级2：项目（具体内容）

Multi-week or multi-month efforts that ladder up to a theme. Each initiative is bigger than a feature but smaller than a theme. Initiatives have:
  • A clear outcome (the metric or result it should produce)
  • A rough size (S / M / L / XL)
  • A confidence rating (how sure are we this is the right initiative?)
  • A dependency map (what has to happen first)
Initiatives are where stakeholders push hard. Resist the urge to commit to dates here. Commit to outcomes and rough sizes.
需数周或数月完成、支撑主题的工作。每个项目比单个功能大，但比主题小。项目需包含：
  • 明确的结果（应达成的指标或成果）
  • 大致规模（S/M/L/XL）
  • 置信度评分（我们对该项目的正确性有多确定？）
  • 依赖关系图（哪些工作必须先完成）
利益相关方往往会在项目层面施压。在此阶段切勿承诺具体日期，应聚焦于结果和大致规模。

Layer 3: Sequencing (the WHEN)

层级3：排序（时间安排）

The order things happen. Sequencing is constrained by:
  • Dependencies (X must finish before Y can start)
  • Capacity (the team can do N things at once)
  • Calendar reality (Q4 has fewer working days, certain teams have hiring gaps)
  • Strategic windows (some launches need to land before a season, conference, or competitive moment)
Build the sequence after the prioritization. Putting things in time-order before deciding what matters produces a plan optimized for calendar fit, not impact.
工作开展的顺序。排序受以下因素约束：
  • 依赖关系（X完成后Y才能启动）
  • 产能（团队同一时间可开展N项工作）
  • 日历实际情况（第四季度工作日更少，部分团队存在招聘缺口）
  • 战略窗口期（部分发布需赶在特定季节、会议或竞品动作前完成）
应在优先级划分完成后再确定顺序。先按时间排序再确定重要性，会导致计划仅适配日历而非聚焦影响。

Layer 4: Capacity reality (the HOW MUCH)

层级4：产能实际情况（可承载量）

Most roadmaps fail here. The plan looks good on paper but assumes 100% of every person's time on roadmap work. Real capacity is much lower.
Default capacity assumptions:
  • Engineers: 60-70% of time on roadmap initiatives. The rest is meetings, reviews, on-call, support, interviews, debugging, ramp-up.
  • Designers: 50-60%. Same reasons plus more cross-team support.
  • PMs: 40-50%. The rest is planning, comms, stakeholder management, async writing.
  • New hires: assume 50% of full capacity for the first quarter, 75% for the second, 100% from Q3 on.
  • On-call rotations, leave, holidays: subtract before sizing.
If the math says the plan needs 100% of the team, the plan is wrong. Cut.
大多数路线图在此层级失败。纸面计划看似完美，但假设团队每个人100%的时间都投入到路线图工作中，而实际产能远低于此。
默认产能假设：
  • 工程师：60-70%的时间投入路线图项目，其余时间用于会议、评审、值班、支持、面试、调试、新员工培训。
  • 设计师：50-60%的时间投入路线图项目，原因同上，且需更多跨团队支持。
  • PM：40-50%的时间投入路线图项目，其余时间用于规划、沟通、利益相关方管理、异步文档撰写。
  • 新员工：入职第一季度产能为全职的50%，第二季度75%，第三季度起达到100%。
  • 值班轮次、休假、节假日：计算产能前需扣除这些时间。
如果计算显示计划需要团队100%投入，那这份计划就是错误的，必须削减内容。

Layer 5: Trade-off communication (the WHY NOT)

层级5：取舍沟通（为何不做）

Every roadmap has a "Not now" list as important as the "Doing" list. The "Not now" is what makes the plan defensible.
Include:
  • The top requests you considered and rejected
  • The reason for each rejection (not the right time, not the right size, conflicts with theme, lower expected impact)
  • The condition that would make it move into "Doing" (a metric, a date, a finished prerequisite)
Stakeholders pushing for cut items can argue against the rejection criteria, not the omission. That's a productive argument.
每份路线图的“暂不开展”列表与“正在开展”列表同样重要，正是“暂不开展”的内容让计划具备说服力。
需包含：
  • 考虑过但被拒绝的核心需求
  • 每项拒绝的原因（时机不对、规模不符、与主题冲突、预期影响较低）
  • 使其转入“正在开展”的触发条件（某指标达成、某日期到来、某前置工作完成）
利益相关方若为被削减的项目争取，可针对拒绝标准而非项目本身进行讨论，这是更具建设性的沟通。

Workflow

工作流程

Step 1: Anchor the strategy

步骤1：锚定战略方向

Before touching the backlog, write down 3 to 5 themes. If the team's OKRs or strategy doc gives you these, copy them. If not, draft them and validate with the people who own strategy.
If the strategy is missing or vague, stop. Producing a roadmap against an unclear strategy is worse than producing nothing. Surface the gap.
处理待办清单前，先确定3-5个主题。若团队已有OKRs或战略文档，直接沿用；若没有，先草拟并与战略负责人确认。
若战略方向缺失或模糊，应暂停推进。基于模糊战略制定路线图比不制定更糟糕，需明确指出这一缺口。

Step 2: Catalog the backlog

步骤2：梳理待办清单

Every candidate gets:
  • Name (one phrase)
  • Theme it ladders up to (or "no theme" - flag for later)
  • Source (request, OKR, retro, customer feedback, leadership ask, technical need)
  • Rough size (S / M / L / XL)
  • Owner or proposed owner
  • Status (idea, validated, scoped, ready)
Items with "no theme" are warning flags. Either the theme list is incomplete, or the item should be cut.
每个候选项目需包含：
  • 名称（一句话）
  • 所属主题（或“无对应主题”——后续需重点关注）
  • 来源（需求、OKR、复盘、客户反馈、领导层要求、技术需求）
  • 大致规模（S/M/L/XL）
  • 负责人或拟议负责人
  • 状态（创意、已验证、已梳理、就绪）
标注“无对应主题”的项目是预警信号：要么主题列表不完整，要么该项目应被削减。

Step 3: Prioritize within each theme

步骤3：主题内优先级划分

Inside each theme, rank the initiatives. Use one prioritization framework consistently. Common ones:
  • RICE (Reach × Impact × Confidence ÷ Effort): good for feature-heavy roadmaps
  • MoSCoW (Must / Should / Could / Won't): good for fixed-deadline projects
  • Kano (Threshold / Performance / Excitement): good for product investment decisions
  • Cost of delay: good when timing matters more than effort
  • Strategic alignment + impact: good for executive-facing roadmaps
The framework matters less than the consistency. Pick one. Use it the same way for every initiative. Document the math.
See 
references/prioritization-frameworks.md
 for the full breakdown.
在每个主题内对项目进行排名，需持续使用同一优先级划分框架。常用框架：
  • RICE（触达用户数×影响×置信度÷投入）：适用于以功能为主的路线图
  • MoSCoW（必须做/应该做/可以做/不做）：适用于固定截止日期的项目
  • Kano（基础需求/性能需求/兴奋需求）：适用于产品投资决策
  • 延迟成本：适用于时间比投入更重要的场景
  • 战略对齐+影响：适用于面向管理层的路线图
框架本身不如一致性重要。选择一个框架，对所有项目统一应用，并记录计算过程。
详见
references/prioritization-frameworks.md
的完整说明。

Step 4: Build the dependency map

步骤4：绘制依赖关系图

For every "Doing" initiative, list what must happen first:
  • Other initiatives
  • Hiring
  • External dependencies (vendor delivery, partner readiness)
  • Research or validation work
  • Infrastructure or platform readiness
Visualize as a graph or a Gantt-style sequence. Items with no dependencies can start immediately. Items with multiple unmet dependencies are warning flags.
针对每个“正在开展”的项目，列出必须先完成的事项：
  • 其他项目
  • 招聘
  • 外部依赖（供应商交付、合作伙伴就绪）
  • 调研或验证工作
  • 基础设施或平台就绪
可绘制成图表或甘特图式的序列。无依赖的项目可立即启动，存在多个未满足依赖的项目是预警信号。

Step 5: Lay out the sequence

步骤5：确定时间序列

Now place initiatives in time. Use the dependency map. Use the capacity math. Match initiatives to people who can actually do them.
Default cadence: month-by-month for one quarter, quarter-by-quarter beyond that. Weekly is too granular for most roadmaps. Half-year buckets are too vague to commit to.
现在将项目安排到时间节点上，需结合依赖关系图、产能计算，并匹配实际可执行的人员。
默认节奏：一个季度内按月划分，超过一个季度按季度划分。周度划分对大多数路线图来说过于精细，半年划分则模糊到无法承诺。

Step 6: Validate with the team

步骤6：团队验证

Before sharing externally, validate with the people doing the work:
  • Are the size estimates realistic?
  • Are the dependencies correctly mapped?
  • Are the capacity assumptions accurate?
  • Is anyone overcommitted?
If the team says the plan is impossible, the plan is impossible. Adjust. Going to leadership with a plan the team disagrees with is how trust gets broken.
对外分享前，需与执行人员验证：
  • 规模估算是否合理？
  • 依赖关系是否正确映射？
  • 产能假设是否准确？
  • 是否有人过度承诺？
如果团队认为计划不可行，那它就是不可行的，需调整。带着团队不认可的计划向管理层汇报会破坏信任。

Step 7: Write the "Not now" list

步骤7：编写“暂不开展”列表

For every "Doing" item, name what got cut to make room. Document why. Document the trigger that would move it to "Doing" later.
针对每个“正在开展”的项目，列出为其腾出空间而被削减的内容，记录原因，以及使其后续转入“正在开展”的触发条件。

Step 8: Communicate

步骤8：沟通计划

Different audiences need different views:
  • Team: detailed sequence, owners, dependencies, sizes
  • Cross-functional partners: themes, initiatives, rough timing, what they need to provide
  • Leadership: themes, expected outcomes, key initiatives, top trade-offs
  • Public or customer-facing: themes, no specific dates, "what to expect"
The same roadmap should produce all four. If it can't, the roadmap is incomplete.
不同受众需要不同视角：
  • 团队：详细序列、负责人、依赖关系、规模
  • 跨职能合作伙伴：主题、项目、大致时间、他们需提供的支持
  • 领导层：主题、预期成果、核心项目、关键取舍
  • 公开或面向客户：主题、无具体日期、“预期内容”
同一份路线图应能衍生出这四种视角，若无法做到，说明路线图不完整。

Failure patterns

失败模式

A list of features instead of a plan. Themes are missing. The roadmap is a backlog with months attached. Fix: start over from strategy.
Date-driven thinking. "What can we ship by end of Q2?" instead of "What is the most important thing to do in Q2?" Dates are constraints, not goals.
Capacity fantasy. The plan adds up to 100% of every person's time. No room for support, interrupts, planning, or unknown unknowns. Roadmap dies in week three.
Stakeholder pressure overrides strategy. A loud customer or executive request gets prioritized because they pushed hard, not because it ladders up. The "Not now" list saves you here.
Missing dependencies. Initiative B depends on initiative A, but A is scheduled later. Or A depends on a hire that hasn't happened. The plan looks fine until execution starts.
Too far out. Specific commitments six months out create promises the team can't keep. Use ranges or themes for far horizons, specifics for near horizons.
One framework for every level. RICE for the whole roadmap including platform work, infra, and exploration. RICE is great for features, weak for foundational work. Use different lenses for different initiative types.
No "Not now." Stakeholders rediscover their cut requests every two weeks because there's no record of why they were cut. Document once, point to it forever.
仅为功能列表而非计划：缺少主题，路线图只是附加了时间的待办清单。解决方法：从战略方向重新开始。
日期驱动思维：关注“到Q2末能交付什么”而非“Q2最重要的工作是什么”。日期是约束而非目标。
产能幻想：计划要求团队每个人100%投入，未预留支持、突发事项、规划或未知风险的时间。路线图会在第三周就失效。
利益相关方压力凌驾于战略之上：因客户或高管施压而优先推进某需求，而非因其符合战略方向。“暂不开展”列表可避免此问题。
依赖关系缺失：项目B依赖项目A，但A的安排晚于B；或A依赖尚未完成的招聘。计划在执行前看似没问题，启动后就会出问题。
规划周期过长：对六个月后的工作做出具体承诺，会让团队无法兑现。远期规划使用范围或主题，近期规划使用具体内容。
单一框架套用所有层级：对平台工作、基础设施和探索性工作全部使用RICE框架。RICE适用于功能，但对基础工作效果不佳。不同类型的项目需使用不同视角。
无“暂不开展”列表：利益相关方每隔两周就会重新提出被削减的需求，因为没有记录拒绝原因。只需记录一次，后续可直接引用。

Output format

输出格式

The roadmap document includes:
  • Strategy summary (1 page or section): themes, why these themes, how they ladder to top-level goals
  • The plan (the visual): a quarter-by-quarter or month-by-month view, color-coded by theme
  • Initiative briefs (one per initiative): outcome, size, owner, dependencies, success metric
  • Capacity model: who is doing what, with utilization math
  • Trade-offs and "Not now": top items considered and rejected, with reasons
  • Risks and assumptions: what could derail the plan
  • Update cadence: when the roadmap will be revisited (monthly is typical)
The roadmap is a living document. Plan to revisit it monthly. Replan it formally each quarter. Do not treat it as a contract.
路线图文档需包含：
  • 战略摘要（1页或1小节）：主题、选择这些主题的原因、如何支撑顶层目标
  • 计划可视化：按季度或月度划分的视图，按主题配色
  • 项目简介（每个项目一份）：成果、规模、负责人、依赖关系、成功指标
  • 产能模型：人员分工及利用率计算
  • 取舍与“暂不开展”列表：考虑过但被拒绝的核心项目及原因
  • 风险与假设：可能导致计划失败的因素
  • 更新节奏：路线图的复盘频率（通常为月度）
路线图是一份动态文档，计划每月复盘，每季度正式重新规划，切勿将其视为合同。

Reference files

参考文件

  • references/prioritization-frameworks.md
     - Detailed breakdown of RICE, MoSCoW, Kano, Cost of Delay, and Strategic Alignment frameworks. When to use each, how to apply them, common mistakes.
  • references/prioritization-frameworks.md
     - RICE、MoSCoW、Kano、延迟成本及战略对齐框架的详细说明，包括适用场景、应用方法及常见误区。