产品路线图规划:5个阶段、3个时间维度和一个模板

最后更新：2026年9月15日

这份路线图在制作完成的那天早上是准确的。到了发布周期的第二周,一个功能的工作量已经悄悄翻了一倍,另外两个还卡在一个没人写下来的决定上,而幻灯片上却仍然显示所有五项会在同一整齐的一行如期交付。

没有人撒谎。只是这份文档根本没有办法得知任何事情已经发生了变化。

好的产品路线图规划,不是做一份更好的幻灯片。它是要缩小计划与实际工作之间的差距,让计划能和所有人一样,随时了解到最新的情况。下面将讲述这个差距藏在哪五个阶段里,如何诚实地展开排序的讨论,以及一个可以直接借用其结构的、真实运作中的Quire项目。

什么是产品路线图规划?

产品路线图规划,是决定你的产品将发布什么、大致按什么顺序发布,然后让这个顺序始终与交付它的任务绑定在一起。前半部分是一场关于价值的论证。后半部分则是管道工程,而正是这后半部分,决定了这场论证在六周之后是否依然站得住脚。

大多数建议都止步于前半部分。你会得到各种优先级排序框架、利益相关者沟通模板,以及一场关于"主题"和"功能"孰优孰劣的辩论。这些都有用,但没有一个触及真正会出问题的地方。

产品路线图为什么会与现实脱节?

路线图之所以失真,是因为它和它描述的工作被分开存放。两份材料,一个真相,却没有任何机制让它们保持一致。所以它们大概只能一致一个星期。

这个差距会带来三个具体的代价。

它牺牲了诚实的答案。有人问接下来会发生什么,而知道答案的那个人得去问五个人,再根据回复重做一遍幻灯片。等到汇报的时候,内容说的其实是上周四的情况。

它牺牲了决策的记录。一个功能延期了,路线图上显示出新的日期,却没有任何记录说明是谁做的决定、又为了腾出空间放弃了什么。

它牺牲了预测的准确性。Kevin Thomas和Cornelius König在《心理学前沿》(Frontiers in Psychology)上发表的研究发现,当一项任务与估算者此前已完成的任务相似时,工期预测会更接近现实。

你自己团队已发布的历史记录,是你手头最好的估算工具。而一份在发布结束的那一刻就把这些数据封存起来的路线图,等于每个季度都在把它白白丢弃。

我们曾一度用一份电子表格来运营Quire的发布工作。这个方法一直管用,直到有一周,有人问了它一个它无法回答、只能靠开会才能解决的问题。

这个问题里关于汇报的那一半,有它自己的解法:不开状态会也能做好利益相关者汇报介绍了一种异步模式,它从工作本身产出报告,而不是依赖某个人的记忆。

从想法到发布,中间要经过哪五个阶段?

一个功能会依次经过收集、分诊、界定范围、构建和发布这五个阶段,而一份常规的路线图往往只展示最后两个。这足够画出一张图表,却远远不足以解释清楚整整一个季度发生了什么,因为真正有意思的事情,恰恰都发生在那三个不留痕迹的阶段里。

也就是说,一个功能实际上会停留在五个位置上,而每当某个位置被跳过而不是被真正经历时,账单就会随之而来。下文的每个阶段都会标注它在Quire产品路线图模板中的对应位置,本文后面会完整展开这个模板。

• 1. 收集位于"Idea intake"区段。跳过这一步,需求就会停留在某条私信里,然后六个月后以投诉的形式卷土重来。
• 2. 分诊的结果是进入Later,或者被关闭。跳过这一步,清单就会不断膨胀,直到没人再信任它,于是每个人都悄悄地维护起自己的私人清单。
• 3. 已界定范围位于Next,状态为"已界定范围”。跳过这一步,工程团队打开工单时,就会在自己的工作周期里,被迫继承一个你一直拖延未做的决定。
• 4. 构建位于Now,并附带子任务。跳过这层嵌套,一整行不透明的记录就会连续两周显示"完成百分之八十”,却没人说得清原因。
• 5. 发布依托"发布检查清单"子清单运行。跳过这一步,客户就会在支持团队被告知这个功能存在之前,先一步遇到它。

注意哪些阶段是留下痕迹的。只有最后两个阶段会出现在常规路线图上;前三个阶段发生在收件箱和走廊闲聊里,这正是为什么图表看起来总比这个季度实际经历的要平静得多。

产品路线图和产品待办清单有什么区别?

待办清单是你可能会做的一切,没有任何承诺的顺序。路线图则是你已经承诺要做的那一小部分,并附有大致的时间安排。团队之所以会陷入麻烦,往往是因为只维护一份清单,却把它同时当成两者,结果清单里的每个想法读起来都像一个承诺。

把它们放在同一个项目里,但分在不同的区段中。同样的任务,同样的字段,不同的含义。

由此带来的一个有用结果是,晋升变成了一个明确的事件。把一个任务从Later移到Next,是某个人在某个日期做出的决定,而不是一行记录在没人注意的情况下悄悄往上漂移。

关于如何让候选项清单保持有用、而不是变成一个坟场:让你的产品待办清单讲出完整的故事。

Quire的产品路线图模板里都有什么?

它是一个已经内置了五个阶段的、可实际运作的项目,在任何计划下都可以免费拷贝。示例数据是一个虚构的v2.0发布版本,这样你可以先看到这个结构如何运作,再把它换成你自己的内容。

与其从一个空白项目开始搭建,不如直接使用Quire的产品路线图模板。它自带以下八项内容:

• 三个时间维度区段,外加一个收集区段。Now是当前发布版本,附有真实日期;Next是下一个版本,以大致形态呈现;Later是没有日期的候选项;而Idea intake则是尚未分诊的需求,其中任何一项都不构成承诺。
• 一套五步状态流程:想法、已界定范围、进行中、审核中、已发布。"已界定范围"这一状态是刻意设置的,因为"尚未开始"和"没人决定过这到底是什么"是两个完全不同的问题。
• 六个路线图字段:发布版本、影响力、工作量、客户请求数、来源,以及一个"需要发布说明"复选框。
• 能展开成真实工作的功能条目。"通知中心"不是一个单独的待办事项,而是规格说明、设计、面板构建、静音设置和摘要邮件,每一项都有明确的负责人和日期。
• 作为项目里程碑的发布关卡:功能冻结、代码冻结和GA,以相依关系的形式串联起来,这样它们必须发生的先后顺序就清晰可见。
• 三个横跨整棵任务树的子清单:当前发布版本、承诺给具名客户的一切,以及发布检查清单。
• 一份"我们如何排定优先级"文档,把评判标准一次性写下来,这样你就不必每次在某个条目上产生分歧时,都重新争论一遍方法本身。
• 两个报告标签页:一个用于每周查看的仪表板,以及"按负责人统计工作量”,它会汇总每个人的预估工时,方便你判断这次发布的工作量是否与团队人手相匹配。

嵌套结构正是阻止一个功能连续两周显示"完成百分之八十"的关键。当"通知中心"被拆分成五个各有负责人的子任务时,“百分之八十"就变成了"摘要邮件那部分还没开始,Ana正在负责”。

即使你不打算碰其他任何部分,也一定要借用这份发布检查清单。七个问题,每一个都对应一个具体的名字,而GA这个项目里程碑要等到这七项全部完成后才会关闭:

1. 本次发布中的每个功能都已"已发布”,或者被明确取消并移到下一个版本。
2. 所有勾选了"需要发布说明"的条目,发布说明都已写好。
3. 每个发生变化的界面,文档和API参考都已更新。
4. 支持团队已被提前告知:已知问题、变通方案,以及需要升级处理的情况。
5. 迁移已在一份生产数据的副本上测试过,回滚方案也已经演练过。
6. 面向发布群体的功能开关已设置好,默认值也已确认。
7. 状态页说明和应用内更新日志已安排在发布当天发布。

第五项写的是"演练过”,而不是"写好文档”。一份没人真正跑过的回滚方案,不过是一个带文件名的愿望而已。

“拷贝"这个操作是对整个项目生效的,所以整棵任务树会完整地被复制过来,而不是一个任务一个任务地搬。从模板标题旁的下拉菜单中打开更多,选择拷贝。

给副本起个名字,选择它归属的组织,然后点击创建。大约一分钟,每一层嵌套结构都会随之而来,这也是拷贝胜过重新搭建的唯一原因。

然后要对它下狠手。结构才是有用的部分;示例功能只是脚手架,你留下的每一个示例条目,到了十一月,都会变成一件让你隐隐感到愧疚的事情。

如何决定下一个发布版本要做什么?

把价值和成本放在一起比较,并让两者的证据都摆在屏幕上,而不是把它们混合掉。优先级排序常常会以一种可预见的方式出错:有人搭建了一个评分公式,公式算出7.4分,然后所有人都对着这个数字点头,而它其实悄悄掩盖了本该解决的分歧,而不是真正解决了它。

保持各项输入独立且可见。在这个模板里,这意味着每个候选项都有三个字段:

• 影响力,衡量其价值,分为高、中、低。
• 工作量,用S到XL粗略估算。
• 客户请求数,统计究竟有多少人真的提出过需求。

按"影响力"排序,同时查看旁边的"工作量”,并让请求数来防止声音最大的那个人成为唯一的决策依据。

然后要留意那个几乎人人都会踩中的错配情况。在示例数据中,“深色模式"收到了47条客户请求,而它的"影响力"却被评为"低”。

这仍然是一个合理的决定,因为它成本低,还平息了一个反复出现的投诉,但没有人应该假装这是一次增长押注。清单上被要求最多的东西,往往不是价值最高的那个,而一个单一的综合评分,恰恰会把这一点掩盖起来。

这就是表格查看模式:同样的任务,六个可排序的列,不需要额外导出任何东西。

任何东西进入Now之前,都要经过三项检验:它是否已"界定范围”?它是否会在代码冻结之前落地,而不是拖到GA那一周?它是否有一个具名的负责人,而不是一个团队?一个塞得满满的Now,和一个空的Now没有区别。

说"不"是另外一半工作,而把东西永远留在"想法"阶段,其实就是一种没人愿意说出口的"不”。把它们移到Later并附上一句话说明理由,或者直接关闭。例外情况是客户承诺子清单:任何有人向具名客户承诺过的东西都会放在那里,所以放弃它是一场对话,而不是深夜11点悄悄做的一次编辑。

不妨在团队争论最多的那十个候选项上试一试。在一个免费的Quire项目里为它们的"影响力"和"工作量"打分,然后排序。通常十个里有八个会自己尘埃落定,会议就只剩下那两个原本就是真正分歧所在的问题。

如何直接从路线图本身回答"接下来会有什么、什么时候会有"这个问题?

你可以直接从时间维度、项目里程碑和状态里读出答案,因为这三者本身就已经由正在做本职工作的人持续维护着。这正是那份幻灯片本该回答、却总是很快过时的问题。

时间维度回答的是大致的时间。Now有日期,因为这些工作已经被界定范围并指定了负责人。Next有发布版本,但没有精确到天的安排。Later则两者都没有,这是故意的。给Later加上日期只是为了显得井井有条,而这恰恰是你在不知不觉中获得一个你从未同意过的承诺的方式。

项目里程碑回答的是必须先满足哪些条件。功能冻结、代码冻结和GA是时间线上真实存在的对象,彼此之间有相依关系,而不是写在某份文档里的句子。当一个功能延期越过了冻结点,时间线会显示它和什么发生了冲突。

状态回答的是现在正在发生什么。"审核中"和"进行中"看起来不一样,而"进行中"又和"想法"不一样。工程师修改一个状态,就顺带更新了路线图,这是他们做本职工作时自然产生的结果,也是唯一能保持实时更新的汇报方式。

仪表板则是为那些永远不会打开路线图的人回答这个问题的。这里有两个小组件特别值得一提。

“已创建任务 对比 已完成任务"设定了工作到来的速度与离开的速度之间的对比。这是判断一个发布版本正在膨胀而非取得进展的最早的诚实信号。

“受阻任务"会把每个卡住的条目和阻碍它的原因配对显示,这样任何路线图评审会上都会被问到的那个老问题,就已经提前有了答案。

模板中每个已发布的功能,也都同时记录着它当初的预估和实际耗时。这个规律正是前文提到的研究所预测的那样:与团队此前做过的东西相似的工作,估算结果很接近实际;而真正全新的工作,则超出预估达三分之一。

这背后有两个机制值得单独一读:Quire的项目里程碑是如何运作的,以及任务相依关系如何把工作串联在一起,正是后者让一次延期的冻结变得可见,而不是停留在理论层面。

产品路线图规划应该放在你的任务管理软件里吗?

应该,而判断标准是:一名工程师关闭一个工单时,路线图会不会在没人要求的情况下自动更新。如果答案是否定的,那你就得维护两份文档,并且早晚会放弃每周核对它们的习惯。

幻灯片软件和专门的路线图工具都能做出一张干净的图。但两者都无法告诉你面板构建延期了,因为它们都不掌握面板构建的实际数据。把路线图放进团队已经在使用的同一款任务管理软件里,就能去掉这份副本,连同它带来的失真也一并消除。

如果你还在挑选这款工具,这篇文章梳理了这个领域的选择:最好的任务管理软件和任务跟踪工具,对比了它们各自如何处理嵌套工作。

有一种情况下,这套结构是不合适的,值得明确说出来。一个还在摸索产品应该是什么样子的团队,手上有候选项,却没有已确定的发布版本。开一个Now时间维度并给它标上日期,就等于凭空捏造出一个没人做过的承诺。

只运行Later和Idea intake,直到真正有事情被界定范围并指定了负责人,再在那一周开启Now。这些时间维度的存在是为了承载承诺,而不是为了显得内容充实。

这份模板只是一整套模板中的一个。其余的都收录在你的团队真正会用到的项目管理模板这篇汇总文章里,包括用于发布、状态汇报和风险管理的模板。

拷贝之后,首先要改什么?

先从日期开始改,因为其他一切都以此为基准。重命名发布版本,并把三个关卡拖到你自己的日期上。

然后把示例功能换成真实的功能,每一项都指定一个具体的人,而不是一个小组。

最后,删掉任何你私下确信永远不会被真正做出来的东西。一份路线图只有在上面每一行都仍然属实的情况下,才会持续保持有用。

关键要点

路线图之所以过时,是因为它存放在工作触及不到的地方。让每一行都成为一个真实的任务,失真的问题基本就能得到解决。

这意味着用五个阶段取代"已计划/已完成"这种粗糙划分,用三个时间维度取代凭空编造的日期,用带相依关系的项目里程碑作为发布关卡,以及用能展示证据、而不是把证据藏进一个分数里的优先级排序字段。

这一切都不需要从零搭建。直接拷贝产品路线图模板,给你的候选项打分,把Now保持精简,剩下的结构会自动帮你完成这项工作。

注册Quire,在任务实际所在的地方运行这一切,这样下次有人问起接下来会有什么时,你给出的答案会是一个链接,而不是一整晚的加班。

常见问题

什么是产品路线图规划?

决定要发布什么、大致按什么顺序发布,并且能够展示每个承诺背后的具体工作。在Quire的产品路线图模板中,每一行都是一个真实的任务,有负责人、有发布版本,工作也嵌套在其下,所以计划和执行不会悄悄地脱节。

产品路线图和待办清单有什么区别?

待办清单是你可能会做的一切。路线图是你已经承诺要做的那部分,并附有大致的时间安排。模板把两者放在同一个项目里,分在不同的区段中。

产品路线图应该规划多远的未来?

当前发布版本用真实日期,下一个版本用大致形态,再往后的什么都不要。这正是Now、Next和Later存在的意义,因为一个为了填满幻灯片而编造出来的日期,正是日后会被拿来问责你的东西。

如何为产品路线图排定优先级?

价值对比成本,两者旁边都摆着证据。Quire的模板把"影响力”“工作量"和"客户请求数"做成表格查看模式下可排序的列,刻意不把它们混合成一个分数,因为单一的数字会掩盖那些真正值得展开的分歧。

路线图应该放在与实际工作相同的工具里吗?

应该,否则你就要维护两个真相版本,并手动去核对它们。把它放进工程师们已经在用的任务管理软件里,这样一次状态变更就能自动更新路线图,不需要任何人去碰第二份文档。

这种路线图结构在什么情况下行不通?

当还没有任何事情真正被承诺下来的时候。一个还在摸索产品形态的团队,手上有候选项但没有确定的发布版本,这时开出一个带日期的Now阶段,就等于凭空捏造出一个承诺。这种情况下只运行Later和Idea intake,直到真正有事情被界定范围并指定负责人。

用这种方式规划路线图,如何帮助团队在工作中提高效率?

它删掉了汇报这一层:不需要每周重做幻灯片,不需要在利益相关者电话会议前追着六个人问进度,也不需要反复追问决定到底是什么。当路线图、发布关卡和实际工作都汇聚在同一个Quire项目里时,那些原本用来解释工作的时间,就转而用在了真正推进工作上。