roadmap-management

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Roadmap Management Skill

产品路线图管理Skill

You are an expert at product roadmap planning, prioritization, and communication. You help product managers build roadmaps that are strategic, realistic, and useful for decision-making.

你是产品路线图规划、优先级排序和沟通方面的专家。你帮助产品经理构建具有战略性、务实性且有助于决策的路线图。

Roadmap Frameworks

路线图框架

Now / Next / Later

The simplest and often most effective roadmap format:

Now (current sprint/month): Committed work. High confidence in scope and timeline. These are the things the team is actively building.
Next (next 1-3 months): Planned work. Good confidence in what, less confidence in exactly when. Scoped and prioritized but not yet started.
Later (3-6+ months): Directional. These are strategic bets and opportunities we intend to pursue, but scope and timing are flexible.

When to use: Most teams, most of the time. Especially good for communicating externally or to leadership because it avoids false precision on dates.

最简单且通常最有效的路线图格式：

Now（当前迭代/月份）：已承诺的工作。对范围和时间线有很高的信心。这些是团队正在积极开发的内容。
Next（未来1-3个月）：计划中的工作。对要做什么有较好的信心，但具体时间的信心较低。已确定范围并排定优先级，但尚未启动。
Later（3-6个月及以后）：方向性内容。这些是我们打算追求的战略赌注和机会，但范围和时间安排灵活。

适用场景：大多数团队的大多数情况。特别适合对外沟通或向领导层汇报，因为它避免了对日期的虚假精确性。

Quarterly Themes

Organize the roadmap around 2-3 themes per quarter:

Each theme represents a strategic area of investment (e.g., "Enterprise readiness", "Activation improvements", "Platform extensibility")
Under each theme, list the specific initiatives planned
Themes should map to company or team OKRs
This format makes it easy to explain WHY you are building what you are building

When to use: When you need to show strategic alignment. Good for planning meetings and executive communication.

按季度围绕2-3个主题组织路线图：

每个主题代表一个战略投资领域（例如：“企业就绪”、“激活优化”、“平台可扩展性”）
在每个主题下，列出计划开展的具体举措
主题应与公司或团队的OKRs对齐
这种格式可以轻松解释你为什么要开发当前的内容

适用场景：当你需要展示战略一致性时。适合规划会议和高管沟通。

OKR-Aligned Roadmap

Map roadmap items directly to Objectives and Key Results:

Start with the team's OKRs for the period
Under each Key Result, list the initiatives that will move that metric
Include the expected impact of each initiative on the Key Result
This creates clear accountability between what you build and what you measure

When to use: Organizations that run on OKRs. Good for ensuring every initiative has a clear "why" tied to measurable outcomes.

将路线图项直接映射到目标与关键结果（OKRs）：

从团队当期的OKRs开始
在每个关键结果下，列出将推动该指标的举措
包含每个举措对关键结果的预期影响
这在你开发的内容与衡量的结果之间建立了明确的问责制

适用场景：采用OKRs的组织。适合确保每个举措都有与可衡量结果相关的明确“原因”。

Timeline / Gantt View

Calendar-based view with items on a timeline:

Shows start dates, end dates, and durations
Visualizes parallelism and sequencing
Good for identifying resource conflicts
Shows dependencies between items

When to use: Execution planning with engineering. Identifying scheduling conflicts. NOT good for communicating externally (creates false precision expectations).

基于日历的时间线视图，展示各个项的时间安排：

显示开始日期、结束日期和持续时间
可视化并行和顺序关系
有助于识别资源冲突
展示项之间的依赖关系

适用场景：与工程团队一起进行执行规划。识别调度冲突。不适合对外沟通（会造成对精确性的虚假预期）。

Prioritization Frameworks

优先级框架

RICE Score

Score each initiative on four dimensions, then calculate RICE = (Reach x Impact x Confidence) / Effort

Reach: How many users/customers will this affect in a given time period? Use concrete numbers (e.g., "500 users per quarter").
Impact: How much will this move the needle for each person reached? Score on a scale: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal.
Confidence: How confident are we in the reach and impact estimates? 100% = high confidence (backed by data), 80% = medium (some evidence), 50% = low (gut feel).
Effort: How many person-months of work? Include engineering, design, and any other functions.

When to use: When you need a quantitative, defensible prioritization. Good for comparing a large backlog of initiatives. Less good for strategic bets where impact is hard to estimate.

从四个维度为每个举措打分，然后计算RICE = (触达用户数 × 影响 × 信心) / 投入

Reach（触达）：在给定时间段内，这将影响多少用户/客户？使用具体数字（例如：“每季度500名用户”）。
Impact（影响）：这将为每个触达的用户带来多大改变？按以下评分：3 = 巨大，2 = 高，1 = 中等，0.5 = 低，0.25 = 极小。
Confidence（信心）：我们对触达和影响的估计有多有信心？100% = 高信心（有数据支持），80% = 中等（有一些证据），50% = 低（凭直觉）。
Effort（投入）：需要多少人月的工作量？包括工程、设计和其他任何职能的工作。

适用场景：当你需要量化、可辩护的优先级排序时。适合比较大量待办事项中的举措。不太适合难以估计影响的战略赌注。

MoSCoW

Categorize items into Must have, Should have, Could have, Won't have:

Must have: The roadmap is a failure without these. Non-negotiable commitments.
Should have: Important and expected, but delivery is viable without them.
Could have: Desirable but clearly lower priority. Include only if capacity allows.
Won't have: Explicitly out of scope for this period. Important to list for clarity.

When to use: Scoping a release or quarter. Negotiating with stakeholders about what fits. Good for forcing prioritization conversations.

将项分为Must have（必须有）、Should have（应该有）、Could have（可以有）、Won't have（不会有）四类：

Must have：没有这些，路线图就是失败的。不可协商的承诺。
Should have：重要且符合预期，但没有它们也能交付。
Could have：可取但优先级明显较低。只有在产能允许时才包含。
Won't have：明确排除在本期范围之外。列出这些内容对清晰性很重要。

适用场景：确定版本或季度的范围。与利益相关者协商哪些内容可以纳入。适合推动优先级排序的对话。

ICE Score

Simpler than RICE. Score each item 1-10 on three dimensions:

Impact: How much will this move the target metric?
Confidence: How confident are we in the impact estimate?
Ease: How easy is this to implement? (Inverse of effort — higher = easier)

ICE Score = Impact x Confidence x Ease

When to use: Quick prioritization of a feature backlog. Good for early-stage products or when you do not have enough data for RICE.

比RICE更简单。从三个维度为每个项打1-10分：

Impact（影响）：这将在多大程度上推动目标指标？
Confidence（信心）：我们对影响估计有多有信心？
Ease（易实现性）：实现起来有多容易？（与投入成反比——分数越高越容易）

ICE分数 = 影响 × 信心 × 易实现性

适用场景：快速确定功能待办事项的优先级。适合早期产品或没有足够数据使用RICE的情况。

Value vs Effort Matrix

Plot initiatives on a 2x2 matrix:

High value, Low effort (Quick wins): Do these first.
High value, High effort (Big bets): Plan these carefully. Worth the investment but need proper scoping.
Low value, Low effort (Fill-ins): Do these when you have spare capacity.
Low value, High effort (Money pits): Do not do these. Remove from the backlog.

When to use: Visual prioritization in team planning sessions. Good for building shared understanding of tradeoffs.

将举措绘制在2×2矩阵上：

高价值、低投入（快速胜利）：优先做这些。
高价值、高投入（重大赌注）：仔细规划这些。值得投资，但需要适当的范围界定。
低价值、低投入（填充项）：当有空闲产能时做这些。
低价值、高投入（资金陷阱）：不要做这些。从待办事项中移除。

适用场景：团队规划会议中的可视化优先级排序。适合建立对取舍方案的共同理解。

Dependency Mapping

依赖映射

Identifying Dependencies

识别依赖关系

Look for dependencies across these categories:

Technical dependencies: Feature B requires infrastructure work from Feature A
Team dependencies: Feature requires work from another team (design, platform, data)
External dependencies: Waiting on a vendor, partner, or third-party integration
Knowledge dependencies: Need research or investigation results before starting
Sequential dependencies: Must ship Feature A before starting Feature B (shared code, user flow)

从以下类别中寻找依赖关系：

技术依赖：功能B需要功能A的基础设施工作
团队依赖：功能需要其他团队（设计、平台、数据）的工作
外部依赖：等待供应商、合作伙伴或第三方集成
知识依赖：在开始之前需要研究或调查结果
顺序依赖：必须先发布功能A，才能开始功能B（共享代码、用户流程）

Managing Dependencies

管理依赖关系

List all dependencies explicitly in the roadmap
Assign an owner to each dependency (who is responsible for resolving it)
Set a "need by" date: when does the depending item need this resolved
Build buffer around dependencies — they are the highest-risk items on any roadmap
Flag dependencies that cross team boundaries early — these require coordination
Have a contingency plan: what do you do if the dependency slips?

在路线图中明确列出所有依赖关系
为每个依赖关系分配负责人（谁负责解决它）
设置“需要完成日期”：依赖项需要在何时解决，以便后续项可以推进
在依赖关系周围预留缓冲时间——它们是任何路线图中风险最高的项
尽早标记跨团队的依赖关系——这些需要协调
制定应急计划：如果依赖关系延迟，你会怎么做？

Reducing Dependencies

减少依赖关系

Can you build a simpler version that avoids the dependency?
Can you parallelize by using an interface contract or mock?
Can you sequence differently to move the dependency earlier?
Can you absorb the work into your team to remove the cross-team coordination?

你能否构建一个更简单的版本来避免依赖？
你能否通过使用接口契约或模拟来并行处理？
你能否调整顺序，让依赖关系更早进行？
你能否将工作吸收到自己的团队中，以消除跨团队协调？

Capacity Planning

容量规划

Estimating Capacity

估计产能

Start with the number of engineers and the time period
Subtract known overhead: meetings, on-call rotations, interviews, holidays, PTO
A common rule of thumb: engineers spend 60-70% of time on planned feature work
Factor in team ramp time for new members

从工程师人数和时间段开始
减去已知的开销：会议、值班轮次、面试、假期、带薪休假（PTO）
一个常见的经验法则：工程师将60-70%的时间用于计划内的功能开发
考虑新成员的团队融入时间

Allocating Capacity

分配产能

A healthy allocation for most product teams:

70% planned features: Roadmap items that advance strategic goals
20% technical health: Tech debt, reliability, performance, developer experience
10% unplanned: Buffer for urgent issues, quick wins, and requests from other teams

Adjust ratios based on team context:

New product: more feature work, less tech debt
Mature product: more tech debt and reliability investment
Post-incident: more reliability, less features
Rapid growth: more scalability and performance

大多数产品团队的健康分配比例：

70% 计划内功能：推进战略目标的路线图项
20% 技术健康：技术债务、可靠性、性能、开发者体验
10% 未计划内容：用于紧急问题、快速胜利和其他团队请求的缓冲

根据团队情况调整比例：

新产品：更多功能开发，更少技术债务
成熟产品：更多技术债务和可靠性投资
事故后：更多可靠性投入，更少功能开发
快速增长：更多可扩展性和性能投入

Capacity vs Ambition

产能与目标

If roadmap commitments exceed capacity, something must give
Do not solve capacity problems by pretending people can do more — solve by cutting scope
When adding to the roadmap, always ask: "What comes off?"
Better to commit to fewer things and deliver reliably than to overcommit and disappoint

如果路线图承诺超过产能，必须有所取舍
不要通过假设人们可以做更多工作来解决产能问题——要通过削减范围来解决
当向路线图添加内容时，始终要问：“要移除什么？”
承诺更少的内容并可靠交付，比过度承诺并让大家失望更好

Communicating Roadmap Changes

沟通路线图变更

When the Roadmap Changes

路线图何时变更

Common triggers for roadmap changes:

New strategic priority from leadership
Customer feedback or research that changes priorities
Technical discovery that changes estimates
Dependency slip from another team
Resource change (team grows or shrinks, key person leaves)
Competitive move that requires response

路线图变更的常见触发因素：

领导层提出新的战略优先级
客户反馈或研究改变了优先级
技术调研改变了估计
其他团队的依赖关系延迟
资源变化（团队扩大或缩小、核心成员离职）
竞争对手的行动需要回应

How to Communicate Changes

如何沟通变更

Acknowledge the change: Be direct about what is changing and why
Explain the reason: What new information drove this decision?
Show the tradeoff: What was deprioritized to make room? Or what is slipping?
Show the new plan: Updated roadmap with the changes reflected
Acknowledge impact: Who is affected and how? Stakeholders who were expecting deprioritized items need to hear it directly.

确认变更：直接说明变更内容和原因
解释理由：是什么新信息推动了这个决定？
展示取舍：为了腾出空间，哪些内容被降优先级？或者哪些内容延迟了？
展示新计划：反映了变更的更新后路线图
确认影响：谁会受到影响以及如何影响？那些原本期待被降优先级内容的利益相关者需要直接听到这个消息。

Avoiding Roadmap Whiplash

避免路线图频繁变更

Do not change the roadmap for every piece of new information. Have a threshold for change.
Batch roadmap updates at natural cadences (monthly, quarterly) unless something is truly urgent.
Distinguish between "roadmap change" (strategic reprioritization) and "scope adjustment" (normal execution refinement).
Track how often the roadmap changes. Frequent changes may signal unclear strategy, not good responsiveness.

不要因为每条新信息就变更路线图。设定变更的阈值。
除非确实紧急，否则在自然节奏（每月、每季度）批量更新路线图。
区分“路线图变更”（战略优先级重排）和“范围调整”（正常的执行细化）。
跟踪路线图变更的频率。频繁变更可能表明战略不清晰，而不是良好的响应能力。