大多数产品路线图在写完后不到一个季度就被抛在一边。这并不是因为团队缺乏纪律，而是因为路线图建立在错误的基础上：固定的日期、功能清单，以及被包装成计划的各方利益相关者的愿望。当现实不可避免地出现偏差——某个功能耗时更长、客户需求发生变化、竞争对手有了新动作——路线图就成了一纸空文，团队也就不再去看它。
一份人们真正会遵循的路线图，不是披着产品战略外衣的甘特图，而是一份动态更新的文档，反映团队当下对“应按什么顺序解决问题”的最佳判断，并坦诚地区分哪些是已知的、哪些是未知的。
在设计路线图之前，值得先弄清它的目的。路线图做三件事：传达方向（我们要去哪里，为什么），迫使我们排定优先级（我们不可能什么都做，所以什么先做），以及为对齐奠定基础（让研发、设计、销售和客服都朝着同一个目标努力）。
路线图不保证交付日期，不承诺具体功能，也不能取代持续的用户探索。如果利益相关者把路线图当作承诺，那是流程上的问题，而不是在文档里刻意营造虚假精确度的理由。
对大多数团队来说，最经得起时间考验的路线图形式，是三层时间视野模型。它对不确定性保持坦诚：“现在”中的事项是已承诺的，“接下来”中的事项已列入计划但尚未锁定，“以后”中的事项方向上是对的，但会随着你了解的增多而调整。
请注意，每个事项不仅写明了“是什么”，还写明了“为什么”。没有理由说明的路线图只是一份清单。当团队成员理解了每个事项为何入选，情况发生变化时他们就能做出更好的决定；当客户提出清单之外的需求时，他们也能展开更有成效的沟通。
以功能为导向的路线图（“做 X，做 Y，做 Z”）会带来一种危险的惯性：团队交付了功能就算完成，哪怕这些功能并没有推动它们本应推动的指标。功能交付了，问题却没有解决。
以成果为导向的路线图，会把每个事项重新表述为一个目标：“把新用户的首次价值获得时间从4天缩短到24小时以内。”团队可以由此自行决定——并不断重新审视——如何实现这个成果。这种结构也让你在发现更好的达成方式时，更容易降低某个功能的优先级。
产品经理对路线图负责，也就是对它的内容、更新以及向利益相关者的沟通负责。但负责并不意味着一个人单独撰写——最好的路线图都是协作完成的，需要研发（就可行性和工作量）、设计（就用户体验方面的影响）和面向客户的团队（就市场信号）共同提供意见。
产品经理应当抵制的，是用委员会的方式来设计路线图。利益相关者可以提出意见，但不应对具体事项拥有否决权。产品经理综合各方意见并做出决断。如果得出决断的过程值得信赖，结果也会被信任。
“现在”这一列应该每个迭代回顾一次。“接下来”这一列应该在每个季度初回顾，或者在出现重要的新依据时回顾（某个重要客户流失、竞争对手推出相关产品、用户探索迭代得出了出人意料的发现）。“以后”这一列每个季度回顾一次——目的不是细化它，而是确认这些方向性的押注是否依然成立。
目标是让路线图既不会陈旧到令人尴尬，也不会更新得过于频繁而引发焦虑。大多数团队的问题在于更新不足——路线图反映的还是六个月前的决策，没人说得清上次修改是什么时候。
只有团队信任路线图，它才会被遵循，缺一不可。这种信任来自三点：每个事项的理由清晰可见且站得住脚；团队参与了路线图的制定，而不是被动接收；情况变化时，产品经理会及时更新，而不是假装最初的计划依然成立。
如果路线图被当作谈判工具，或是为了应付高管而产出的文件，团队层面会把它置之不理，利益相关者层面则会心生不满。而一份反映真实思考、真实取舍和坦诚的不确定性的路线图，会成为人们愿意随时翻阅的工具——因为它确实能帮助他们做决策。