产品路线图示例：六种格式，以及各自是怎样失效的

值得参考的产品路线图示例可以归为六种格式：Now/Next/Later、季度时间线、主题式路线图、结果式路线图、公开路线图，以及内部发布路线图。每一种回答的是不同读者的不同问题，所以合适的示例，就是与你的路线图读者相匹配的那一个。版式是最后才需要决定的事。

下面的每个示例都以一个虚构的产品为背景，一款小团队任务应用，所有条目都是编造的。重点在于形状：每个格子里放什么，一条真实的条目长什么样，以及这种格式为什么会在一个季度之后失效。

好的产品路线图示例是什么样的？

好的路线图示例很简短，有明确的读者，并且只做一种承诺。按照你愿意兑现的承诺来选格式：一个方向、一个日期、一组主题工作、一个结果、一个公开的承诺，或者一份交付排期。

每种产品路线图示例具体长什么样？

下面的每种格式都配有贴近真实的条目，之后说明它适合谁、什么时候站得住脚，以及通常是怎样失效的。

Now/Next/Later

NOW (本月正在构建)
  Saved views on the inbox
  CSV export that works for large accounts
NEXT (已决定，顺序未定)
  SSO for the Team plan
  Slack notifications
LATER (一个方向，不做承诺)
  Mobile app
  Audit log

这种格式适合不想承诺日期的公司，很多早期团队都是如此。它之所以站得住脚，是因为三列描述的是你有多确定：“now”是正在进行，“next”是已经决定，“later”是一个期望。当”later”变成存放所有没人愿意拒绝的想法的地方，或者当”next”在没有人称之为时间线的情况下悄悄拥有了顺序和日期时，它就失效了。

时间线或季度路线图

Q4 2026
  Oct   Saved views on the inbox
  Nov   SSO beta with five design partners
  Dec   SSO general availability
Q1 2027
  Jan   Slack notifications
  Mar   Audit log (export only)

这种格式适合销售、支持和财务，他们需要围绕某个东西做计划。当日期是真实的约束时，比如一份合同、一场大会或者一个合规截止日，它就能奏效。当日期只是猜测时它就会失效，因为路线图上的一个月份，几周之内就会变成销售资料里的一份承诺。如果使用这种格式，请把每个季度标注为”已承诺”或”预测”，并且让第二个季度明显比第一个季度更松。

主题式路线图

THEME: First week experience
  Import from CSV and Trello
  Starter templates
THEME: Ready for bigger teams
  SSO
  Audit log
  Role permissions
THEME: Fewer manual steps
  Slack notifications
  Recurring tasks

这种格式适合领导层汇报和新员工，因为它在列出工作之前，先解释了这些工作为什么存在。当每个主题都对应一个客户会在意的理由时，它就站得住脚。当主题宽泛到（“增长”、“质量”）每个条目都能放进每个主题下面时，它就失效了，这时的分组什么也解释不了。

结果式路线图

GOAL: More new teams finish setup
  Metric: setup finished within 7 days, 40% to 55%
  Bets: import from CSV, starter templates
GOAL: Fewer support tickets about exports
  Metric: export tickets per week, 30 to 10
  Bets: large-account export fix, export status page

这里的数字只是示意，重点在版式：一个目标，一个有起点和目标值的指标，以及你打算尝试的几个押注。它适合那些被信任可以自行选择解决方案的产品和工程团队。当指标存在并且有人负责时，它就能奏效。当目标无法衡量，或者”押注”仍然是原来那份功能清单、只是在上面贴了一句结果描述时，它就失效了。

面向客户的公开路线图

PLANNED
  Saved views on the inbox
BUILDING
  Slack notifications
SHIPPED
  CSV export for large accounts

这是最小的格式，也做出了最强的承诺。它适合客户，他们想知道自己的请求有没有被听到。条目极少、没有日期、标题用客户自己的话来写，它就站得住脚。当它沦为积压清单的倾倒场时就失效了：你列出的每一个”也许”，都是一个别人日后会来追问的承诺。如何从你的 issue 追踪系统运行一份公开路线图，已经写在三列式公开路线图里，这里不再重复。

内部发布路线图

这种格式适合工程、QA 和支持，他们需要知道哪些内容会一起发布，以及什么阻塞了什么。当它精确到周、并且每一行都有负责人时，它就能奏效。当有人把它当成战略时它就失效了：交付排期说明的是什么会在什么时候发出去，而对于这些版本是不是正确的押注，它什么也没说。

应该选择哪种产品路线图格式？

先按读者来选，再按你实际拥有的确定性来选。如果你说不出谁会读这份路线图、它帮助他们做出什么决定，那么上面任何一个示例都救不了它。

• 客户在问”你们听到我了吗？” 用公开格式，并且只保留寥寥几项。
• 销售和支持在问”我能告诉客户一个日期吗？” 用季度时间线，把已承诺和预测清楚地分开。
• 领导层在问”为什么做这些？” 用主题式，如果有数据就用结果式。
• 一个每月都在改变方向的团队。 用 Now/Next/Later，并且克制住不加日期的冲动。
• 工程师在问”什么时候发布什么？” 用发布路线图，并且让它与战略路线图分开。

大多数团队最终会拥有两份：一份是前四种形态之一的战略路线图，下面是一份发布排期。公开路线图则是战略路线图的一个过滤视图，只展示你愿意被追责的内容。

如何编写产品路线图？

编写路线图的方法是：先确定读者，选择适合他们问题的格式，只列出你会在会议上为之辩护的条目，并给每个条目一个状态和一位负责人。然后在发布之前，决定它多久评审一次。

1. 确定读者和他们要做的决定。 “支持团队要决定如何向客户介绍 SSO”是一个理由。“所有人都应该看到路线图”则没有给你任何可以设计的依据。
2. 从你已经知道的东西出发。 未处理的请求，按照一条你能解释清楚的规则排好序，比一场头脑风暴是更好的原材料。
3. 把每个条目写成客户的结果。 “保存一个你常用的筛选条件”比”实现已保存视图的持久化”读起来更好，也能让客户判断这是不是他的问题。
4. 决定路线图不包含什么。 日期、估算和想法积压清单，是三种常见的排除项。
5. 设定一个评审日期。 一份没有安排评审的路线图，就等于没有安排日期的葬礼。

如何让产品路线图保持最新？

让路线图保持最新的办法，是在工作推进时移动条目，并且从追踪这项工作的同一个地方来做，同时在条目上线或被放弃时记录发生了什么。一份有人在另一个工具里手动更新的路线图之所以会陈旧，是因为它不是任何人的日常工作。

最廉价的事实来源是 issue 追踪系统。如果路线图的每一列都对应 issue 上的一个标签，那么标签一变，路线图就跟着变，什么都不需要重新录入。Changeloop 的做法使用 roadmap:planned、roadmap:building 和 roadmap:shipped 标签，当一个 issue 同时带有两个标签时，更靠后的那个胜出。把卡片移到已发布依然是一次单独的标签变更，所以要把它纳入你批准体验日志条目的那次评审。

条目是另一半。当一个项目上线时，体验日志会用客户的话说明改变了什么，提出过请求的人也可以得到通知。闭合这个循环，正是客户反馈循环的要点，而路线图就是这个循环里、在任何东西发布之前客户能看到的那一段。如果你放弃了一个项目，就要说出来；一句公开的”不做”同样会结束这个请求，拒绝功能请求里介绍了如何措辞。想看已完成的条目读起来是什么样子，可以浏览体验日志示例。

FAQ

最简单的产品路线图格式是什么? Now/Next/Later。它只有三列，不需要日期，按确定性来给条目分组。对一个经常改变方向的小团队来说，它也是最不容易出大糗的格式。

产品路线图应该有多少个条目? 比你想的要少。对公开路线图来说，所有列加起来不到十项就够了，一份内部战略路线图很少需要超过十来项。再多就成了一份换了个好看标题的积压清单。

产品路线图应该包含日期吗? 只有当日期是真实的约束时才需要，而且只写最近的一个季度。再往后，就用列或者主题。路线图上的日期，不管你是不是有意为之，都会在销售对话里变成一份承诺。

产品路线图和发布计划有什么区别? 路线图说明你打算构建什么以及为什么。发布计划说明哪个版本在哪天发布、由谁负责。路线图随着你的战略变化而变化，发布计划则随着工作的进展而变化。

本文的技术内容未经独立审核。如有错误，请告诉我们，我们会更正。

changeloop 相关页面： 开发者文档, changelog 示例