产品路线图

它是什么

产品路线图是按时间与目标组织产品方向的计划，说明「接下来要解决什么问题、为什么是这个顺序」。它不是承诺交付日期的功能清单，而是对齐干系人预期、传递优先级和战略意图的工具。

为什么需要它

没有路线图，团队各做各的、干系人不知道方向、每次改动都要重新解释。路线图把「先做什么、为什么」摊开，帮助争取资源、管理预期，也让短期决策回到长期目标上。

它如何工作

先定产品目标与关键问题，再按「现在 / 下一步 / 以后」或「季度 / 主题」组织要解决的问题，而不是罗列功能。路线图应随学习和反馈持续调整，重点说「为什么」，并区分「承诺」与「探索」，避免把未验证的想法写成确定交付。

必须澄清的误会

产品路线图 ≠ 需求优先级。 优先级是「先做哪个」的判断方法，路线图是判断结果在时间上的排列，前者是方法后者是产出。

产品路线图 ≠ 项目管理。 路线图管「做哪些、什么顺序」，项目管理管「正在做的这件事怎么按计划推进」，时间尺度不同。

真实例子

一个 AI 客服产品把路线图写成：本季度「先让坐席可靠找到带版本原文」，下季度「提供可编辑草稿并验证采纳」，再往后「评估受控自动回复」。每个主题都对应一个要验证的产品问题，而不是「上线 XX 功能」。

什么时候适合与不适合

适合：需要跨团队对齐、争取资源、或让方向可见。慎用：把路线图当成不可变的承诺会失去灵活性；细节过多会变成项目管理计划。路线图表达方向与优先级，不是合同。

亲自试一下

写下未来两三个月的产品目标，再用「现在 / 下一步 / 以后」三个框，各填一个「要解决的用户问题」。检查每个框能否说清「为什么是这个顺序」，并标出哪些是承诺、哪些还在探索。

接下来学什么

配合需求优先级确定顺序，用 MVP 和北极星指标验证每一步是否值得继续。

来源与修订

「路线图表达方向而非功能清单」的原则参考 Marty Cagan [S1]；路线图的结构与类型参考 ProductPlan 的实践指南 [S2]。本版强调区分承诺与探索，不把路线图写成交付合同。