roadmap-update

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Roadmap Update

产品路线图更新

If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.

Update, create, or reprioritize a product roadmap.

如果你看到不熟悉的占位符或需要查看已连接的工具，请参阅CONNECTORS.md。

更新、创建或重新规划产品路线图的优先级。

Usage

使用方法

/roadmap-update $ARGUMENTS

/roadmap-update $ARGUMENTS

Workflow

工作流程

1. Understand Current State

1. 了解当前状态

If ~~project tracker is connected:

Pull current roadmap items with their statuses, assignees, and dates
Identify items that are overdue, at risk, or recently completed
Surface any items without clear owners or dates

If no project management tool is connected:

Ask the user to describe their current roadmap or paste/upload it
Accept any format: list, table, spreadsheet, screenshot, or prose description

如果已连接项目追踪工具：

拉取当前路线图项及其状态、负责人和日期
识别逾期、存在风险或近期已完成的项
找出没有明确负责人或日期的项

如果未连接项目管理工具：

请用户描述其当前路线图，或粘贴/上传相关内容
接受任何格式：列表、表格、电子表格、截图或文字描述

2. Determine the Operation

2. 确定操作类型

Ask what the user wants to do:

Add item: New feature, initiative, or work item to the roadmap

Gather: name, description, priority, estimated effort, target timeframe, owner, dependencies
Suggest where it fits based on current priorities and capacity

Update status: Change status of existing items

Options: not started, in progress, at risk, blocked, completed, cut
For "at risk" or "blocked": ask for the blocker and mitigation plan

Reprioritize: Change the order or priority of items

Ask what changed (new information, strategy shift, resource change, customer feedback)
Apply a prioritization framework if helpful — see Prioritization Frameworks below for RICE, MoSCoW, ICE, and value-vs-effort
Show before/after comparison

Move timeline: Shift dates for items

Ask why (scope change, dependency slip, resource constraint)
Identify downstream impacts on dependent items
Flag items that move past hard deadlines

Create new roadmap: Build a roadmap from scratch

Ask about timeframe (quarter, half, year)
Ask about format preference (Now/Next/Later, quarterly columns, OKR-aligned) — see Roadmap Frameworks below
Gather the list of initiatives to include

询问用户想要执行的操作：

添加项：向路线图添加新功能、举措或工作项

收集信息：名称、描述、优先级、预估工作量、目标时间范围、负责人、依赖项
根据当前优先级和产能建议合适的位置

更新状态：更改现有项的状态

选项：未开始、进行中、存在风险、受阻、已完成、取消
对于“存在风险”或“受阻”状态：询问阻碍因素和缓解计划

重新规划优先级：更改项的顺序或优先级

询问发生了哪些变化（新信息、战略调整、资源变化、客户反馈）
如有帮助，应用优先级框架——下文的优先级框架部分包含RICE、MoSCoW、ICE以及价值-工作量矩阵
展示调整前后的对比

调整时间线：更改项的日期

询问原因（范围变更、依赖项延迟、资源限制）
识别对依赖项的下游影响
标记超过最终期限的项

创建新路线图：从零开始构建路线图

询问时间范围（季度、半年、年度）
询问格式偏好（Now/Next/Later、季度列、与OKR对齐）——请参阅下文的路线图框架
收集需要包含的举措列表

3. Generate Roadmap Summary

3. 生成路线图摘要

Produce a roadmap view with:

生成包含以下内容的路线图视图：

Status Overview

状态概览

Quick summary: X items in progress, Y completed this period, Z at risk.

快速摘要：X项进行中，Y项已在本周期完成，Z项存在风险。

Roadmap Items

路线图项

For each item, show:

Name and one-line description
Status indicator (on track / at risk / blocked / completed / not started)
Target timeframe or date
Owner
Key dependencies

Group items by:

Timeframe (Now / Next / Later) or quarter, depending on format
Or by theme/goal if the user prefers

每个项需展示：

名称和一行描述
状态标识（按计划推进/存在风险/受阻/已完成/未开始）
目标时间范围或日期
负责人
关键依赖项

可按以下方式分组：

时间范围（Now / Next / Later）或季度，取决于格式
或按主题/目标（如果用户偏好）

Risks and Dependencies

风险与依赖项

Items that are blocked or at risk, with details
Cross-team dependencies and their status
Items approaching hard deadlines

受阻或存在风险的项及其详情
跨团队依赖项及其状态
临近最终期限的项

Changes This Update

本次更新的变更内容

If this is an update to an existing roadmap, summarize what changed:

Items added, removed, or reprioritized
Timeline shifts
Status changes

如果是对现有路线图的更新，总结变更点：

添加、移除或重新调整优先级的项
时间线调整
状态变化

4. Follow Up

4. 后续跟进

After generating the roadmap:

Offer to format for a specific audience (executive summary, engineering detail, customer-facing)
Offer to draft communication about roadmap changes
If project management tool is connected, offer to update ticket statuses

生成路线图后：

提供针对特定受众的格式化服务（高管摘要、工程细节、客户面向版本）
提供路线图变更的沟通文案起草服务
如果已连接项目管理工具，提供更新工单状态的服务

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个主题组织路线图：

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

适用场景：需要展示战略对齐时。适合规划会议和高管沟通。

OKR-Aligned Roadmap

与OKR对齐的路线图

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.

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

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

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

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

RICE评分

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 × Impact × Confidence) / Effort

Reach：在给定时间段内将影响多少用户/客户？使用具体数字（例如：“每季度500名用户”）。
Impact：这将在多大程度上影响每个触达的用户？按以下评分：3=巨大，2=高，1=中等，0.5=低，0.25=极小。
Confidence：我们对Reach和Impact的估算有多大信心？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）：

必须有：没有这些，路线图就是失败的。不可协商的承诺。
应该有：重要且符合预期，但没有它们也能交付。
可以有：可取但优先级明显较低。仅在产能允许时包含。
不会有：明确排除在本周期范围之外。列出这些是为了清晰起见。

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

ICE Score

ICE评分

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：我们对Impact估算有多大信心？
Ease：实现起来有多容易？（与工作量相反——分数越高越容易）

ICE评分 = Impact × Confidence × Ease

适用场景：快速对功能待办事项进行优先级排序。适合早期产品或没有足够数据使用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.

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

Output Format

输出格式

Use a clear, scannable format. Tables work well for roadmap items. Use text status labels: Done, On Track, At Risk, Blocked, Not Started.

使用清晰、易于扫描的格式。表格适合展示路线图项。使用文本状态标签：已完成、按计划推进、存在风险、受阻、未开始。

Tips

提示

A roadmap is a communication tool, not a project plan. Keep it at the right altitude — themes and outcomes, not tasks.
When reprioritizing, always ask what changed. Priority shifts should be driven by new information, not whim.
Flag capacity issues early. If the roadmap has more work than the team can handle, say so.
Dependencies are the biggest risk to roadmaps. Surface them explicitly.
If the user asks to add something, always ask what comes off or moves. Roadmaps are zero-sum against capacity.

路线图是沟通工具，不是项目计划。保持合适的粒度——聚焦主题和成果，而非任务。
重新规划优先级时，始终要问发生了什么变化。优先级调整应基于新信息，而非一时兴起。
尽早标记产能问题。如果路线图的工作超过团队产能，请明确说明。
依赖项是路线图最大的风险。要明确地展示它们。
如果用户要求添加内容，始终要问哪些内容将被移除或延迟。路线图相对于产能是零和的。