产品路线图对于产品团队来说，非常重要；在产品路线图的指引下，每个团队成员都能够明确自己的职责，而不会为接下来该做什么感到迷茫。但是，产品路线图也是令开发团队众多心血付之东流的罪魁祸首；为什么这样说呢？

如今的产品团队都是在围绕什么开展工作的呢？答案毫无疑问是产品路线图。

一般来说，产品路线图包括以下内容：需要实现的功能、想法和创意、大大小小的阶段性目标、细分给各团队的任务、还有多团队协作的计划等，除此之外最重要的一个特征就是：以上每一项通常都附有一个截止期限。

在产品路线图的指引下，每个团队成员都能够明确自己的职责，而不会为接下来该做什么感到迷茫。那么，我们可以将产品路线图简单地定义为：产品路线图是一系列按照优先级别和截止期限排列的功能与计划的清单。

产品路线图通常由管理团队或产品经理制定，他们有充足的理由解释，为什么大家需要产品路线图，又为什么每个人都要严格遵循其中的规划。

最常见的理由有：

1. 有了产品路线图以后，他们就能确保团队集中精力完成最高优先级的任务；
2. 他们是企业的创办者，理应对公司的业务做出规划，他们希望追踪产品的开发进度，以便为之后的市场营销和销售做好准备，同时也能及时向公司的投资者汇报。

这些都是产品路线图存在的理由，不过有一件非常重要的事，一直以来都被我们选择性地遗忘：其实，产品路线图也是令开发团队众多心血付之东流的罪魁祸首，其中超过半数的功能和想法最终都未能如愿实现。

一、导致问题的原因是什么呢？

残酷的事实是：即便我们的规划做得再完美，也会有50%以上的创意和构思化为泡影；对那些更加保守的团队而言，这个比例可能高达75%。我们都知道，在产品开发的过程中，计划永远赶不上变化，更具体的来说，大致有以下一些原因：

1. 对于我们正在开发的功能，用户可能并不像我们一样，对未来有非常乐观的预期；
2. 如果用户想要使用某个功能，而且需要花费大量时间来研究明白，那么他们很可能就选择放弃了；
3. 有时候，某个创意看起来非常棒，一旦实施起来却发现需要投入大量的时间和精力，我们只能半途而废；
4. 可能存在资金紧缺、行规限制或法律约束等原因，让我们无法按照原计划去落实方案；
5. 最后也是非常重要的一点：如果一个创意必定能够为公司和用户都带来价值，但却需要经过大量的迭代才能达到理想的状态，那么相对于之前的构思，我们显然需要更多的时间和资源。

你可以选择接纳残酷的现实，并努力尝试解决问题；也可以选择视而不见，接受一切可能产生的后果。

为此，我专门做了一个对比研究，比较“传统型团队”和“变通型团队”是如何应对上述现实的。

以下是我的发现：

1. “传统型团队”盲目地遵从产品路线图的指示

日复一日，他们随时都在按照产品路线图的规划行事，确保每一个任务都能按时完成。

一旦出现了问题，他们就会开始抱怨管理层目标设定的不合理，并请求多给些时间来重新设计“功能”。

如果他们有充足的时间和资金，或许他们最终就能够成功解决问题并找到理想的应对方案，但现实中这样的情况实在太少了。

2. “变通型团队”理解、接受现实，并及时作出调整

最理想的状态并不是忽略存在的问题，而是接纳现实，换一个角度看问题，理解需求的不断变化。

“变通型团队”在开发之初并不会先在产品路线图上列明需要实现的功能，而是从“产品发现”阶段开始。

产品路线图存在的问题是：我们只会向里面添加各种需要开发的功能，却忽略了现实的商业问题。什么才是产品开发最根本的问题？反正绝对不只是功能的开发。

——Marty Cagan

在产品发现阶段，产品团队需要弄清楚以下几个问题：

1. 我们的商业目标是什么？
2. 有什么可以度量的KPI指标？
3. 有什么需要应对的风险和问题？
4. 对于我们事先界定的最主要的商业问题，如何找到有效的解决方案，并快速地迭代到理想状态。

在产品路线图中列出众多待开发功能的弊端在于：即便产品路线图已经不能满足现实需求了，团队仍将完成其中的规划当做是一种职责。

不管你怎么声明，大家心中还是留存着一个固定的目标——设计或实现某个功能。产品团队会继续开发、实现功能清单上的任务，即便这早已不能解决问题了。

从另一个方面看：我承认，我们的确需要一个功能清单，并且附有严格的时间限制，但我想强调的是，团队必须从纯粹的“功能实现者”转变为“问题解决者”，所以，我并不是建议废弃产品路线图，而是要对其进行完善，在确定计划之前，加上“产品发现”这一步骤。

二、怎样制定更科学的产品路线图？——加入“产品发现”阶段

一些团队可能在还没有确定任何商业目标的前提下，就过早地制定了功能清单，也就是说：他们都还没来得及确认方案的可行性和适用性，就匆忙地将功能列进了计划之中，以至于能不能解决客户遇到的问题都不确定。有一份列明截止日期的功能清单非常重要，但更需要强调的一点是——产品愿景。

三、产品发现

提前加入产品发现，设计交付模式，能够很大程度上改变现状。产品发现是产品管理、用户体验、工程师团队密切合作的过程，其目的就是快速筛选出好的设计构想。产品发现的最终产出是一个经过验证的、可行的产品任务列表。

也就是说，通过产品发现这一步骤，你就能够回答以下问题：

• 用户会购买我们的产品吗？
• 我们的产品能解决用户面临的问题吗？
• 我们的产品能全面提升用户体验吗？
• 我们产品的最大卖点突出吗？
• 这一产品的推出有助于我们实现产品愿景吗？
• 股东会赞成我们的计划吗？
• 我们的工程师水平够吗？
• 用户能掌握产品的使用方法吗？

四、如何应用“产品发现”？

假设目前完成对一个大客户的引导，需要花费两周的时间，而我们需要将这个时间从两周缩短至几个小时，这就是一个非常典型的商业目标案例：“减少对大客户的引导时间。”同时，也能找到一个可测度的观测目标，那就是：“客户引导时长减少一小时。”一个暂时只有商业目标的产品路线图会是怎样的呢？

这样的产品路线图能够充分调动团队的创造力和创新热情，大家会觉得大胆地分享观点是一件很放松、安全的事，我们也不再会受限于已列出的功能清单了。

五、将计划落实的几个步骤

首先：我们需要请示大股东，为做好产品发现多争取一些时间，以便寻求最优的解决办法和执行方案。告诉他们，我们需要时间来检验，既定的目标是否满足用户的需求，以及这样做究竟能不能全面地提升用户体验。接下来：我们需要与工程师一同确定，从技术层面来看，我们的方案是否具有可行性，能否通过多次迭代达到理性的状态。

最后：我们需要和股东或管理团队汇报，确认找到的解决方案是能够实现我们的商业目标的。

一旦我们完成了与客户、工程师以及管理团队的接洽，接下来就可以开始指定实施计划了。

这样的计划包括我们的商业目标、可测度的KPI指标，以及其他细节，同时一定不要忘了为这一切设定对应的截止日期。

最关键的是：公司一定要不时地对规划进行调整，即便一切要推翻再来，也能够乐观应对。

因为通过对客户心声的聆听，以及对关键事项的把控，我们能够真正地改良产品，而非执着于细枝末节的既定功能，缺乏对产品远景的大局观。

最后，即便你不会经常做“产品发现”，但做了远比不做强。

原作者：Eugen Eşanu

原文链接：https://medium.com/@eugenesanu/the-problem-with-product-roadmaps-fd3a40090f7c

翻译：即能，公众号：即能学习

本文由 @即能 翻译发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。