产品路线图并不是纯粹的“功能清单”，你应该放弃对功能的过分关注，而关心我们最终想要的效果是什么，需要解决的具体问题又是什么，这样才能摆脱功能型路线图的束缚，转向更为科学的产品开发模式。
在职业生涯中，我设计过很多产品路线图。
其中，光是在 WorldRemit 工作的头 3 年里，我就为公司做了 10 种以上不同类型的产品路线图。
之所以要不断变换设计思路，是因为我希望通过尝试，找到最有效的产品路线图，至少要具备这样几个优点：针对性强、能与*更高效地交流、引领团队高效协作。
众多产品路线图中的一个
在我看来，现在大多数产品路线图都一个共通的大问题：产品路线图被做成了纯粹的“功能清单”，唯一的区别就是这些功能被放置在一个时间轴上（而且也不是那么明确）。
其实这样一个“功能清单”问题颇多，最直接的就是公司上下包括你的客户，都会觉得这样一个功能清单就是你的承诺书，而你将“矢志不移”地兑现承诺，这无形之中给开发团队施加了巨大的压力，必须原原本本地按照这份清单行事，就算撞了南墙也不回头。
因为一回头你就会发现，这些功能根本就没解决问题，即便解决了，也都是些无足轻重的小问题。这种团队的使命就是日复一日地完成清单上的任务，即便产品开发的环境（包括公司策略、用户需求、行业竞争格局）早已发生了改变。
一、功能导向性产品路线图几宗罪
作为一个产品经理，“功能清单”可能会让你陷入尴尬的境地。大公司里由上而下的公司治理文化，明确了高管和*在产品开发上的绝对话语权，他们向产品团队下达功能开发指令，团队只能遵从指示办事。
类似的，如果你加入了一家创业公司，公司的创始人一般会决定产品要怎么做，只要你给他一个空白清单，立马就会给你填满。
这时，你作为一个产品经理，几乎没有自主权，充其量是个指令接受者，你所需要做的就是想法设法，尽量以最好的效果呈现老板们想要的功能。
在功能路线图的框架下，即便你是一个优秀的产品经理，也只能保证做好个别功能，不能对产品的全局有效把控，这就好比你赢下了一场又一场的局部战役，最后却输掉了整场战争。
想象一下这样的场景：要到年底了，你结束了产品的开发工作，向管理团队汇报工作，你告诉他们，计划里的所有功能都开发出来了。不管你完成的是一项多么难以置信的任务，他们还是会向你咆哮，说你做砸了他们的创意，想要的效果根本没有达到。
如果你是按功能导向型的路线图来做的，那这种事情是很可能发生的，也许是因为你被迫开发的功能没有实现预期的效果，但你还是得原原本本地做出来。
那么问题来了，你应该如何摆脱功能型路线图的束缚，转向更为科学的产品开发模式呢？
二、从期望的结果倒推过程
从现在开始，你应该放弃对功能的过分关注，而是关心我们最终想要的效果是什么，需要解决的具体问题又是什么。
试着问问自己，如果我们的产品开发成功了，会给世界带来什么样的改变？我们的用户会有什么样的体验？他们能通过我们的产品做些什么？
在一个特定的时间段内，每个团队都应该围绕这个共同的、明确的目标或者说结果而奋斗，而不是被功能路线图牵着鼻子走。
任何好的目标，都应该是能够测度、衡量的，同样，你设定的结果也必须是能够加以验证的，最直观的反馈就是，你的产品能得到用户和业界的认可吗？
如果你实现的结果是：“用户能看到更多广告”，这对用户来说就毫无价值，也更不可能因为这个结果而取得业务上的成功。
一个好的结果应当是像这样的：“用户注册时间缩短一半”。
这样一来，产品经理不再是管理层的传令官，产品怎么做、开发什么功能、达到什么效果，变成了整个团队的问题。
这种方式最大的优点就在于：团队内部有了更大的自主性，每个成员都能够发挥自己的专业特长和创造性。同时，只要我们观察到，用户能够在原来一半的时间内完成注册，那么我们的目标就达到了，也不必再管哪项功能有没有实现。
对希望实现的结果有了更清晰的认识之后，你会发现自己的思路更加开阔，解决问题的可能性也远比之前多。
爱德华·德博诺博士（Edward de Bono）在他的著作《水平思考法》中举了一个非常经典的例子：一家大公司的高管们遇到了一个难题，这家公司搬到了一栋新的办公楼后，大家才发现，大楼的设计者考虑不周，没有配备足够的电梯，公司员工经常因为长时间等电梯而心生抱怨。
许多高管提议，要想办法给电梯提速，或者在大楼里再开凿一个电梯井，增加运量。不过，他们最终另辟蹊径，采用了一个完全不同的方法，同样成功解决了问题。
他们在电梯入口处安装了很多落地镜，大家早上来上班的时候，注意力都集中在镜子中的自己，不知不觉就忘了等电梯的辛苦。
在这个案例中，高管们真正需要解决的问题其实并不是电梯不够，而是员工因为等电梯而产生的烦躁情绪。
可以看到：他们选了一个比加装电梯划算很多的方案，最后也取得了非常不错的效果。
三、删除冗余，少即是多
这个新的设计思路还会带来另一个好处，那就是避免开发团队向产品中加入过多的功能，尤其是那些用户根本不需要的功能。
结果驱动型的方法，能够引导团队将精力集中在改良现有功能上，最大限度激发这些功能的效果，而不是光想着增加新的功能。
这种思维方式极大地提高了团队的创造性，甚至能让你关注到平时都没有留意的方面。
我曾经和一个朋友探讨过这方面的问题，他所在的电子商务行业最关注的一个指标就是转化率，他们每年年底都会进行一次年终统计，有充分结果表明：对提升转化率贡献最大的部分，并不是增添的新功能，而是他们对现有功能做出的技术改良，例如优化图片处理技术之后，他们的网页加载速度大幅提升。
这种方法还能让团队不断优化产品，去掉影响用户体验的功能。
不过，就像其他方法一样，合不合适还得试过再说。在这篇文章剩下的篇幅里，我想要重点谈谈，结果驱动型的方法可能会出现什么问题，以及如何避免。
四、可能产生的问题
1. 公司没有一个明确的企业策略
首先，最重要的一点，如果你的公司没有一个明确的企业策略，那么结果驱动型的产品路线图也必然会失败。
在WorldRemit，我们首先从确定公司本年度目标起步，用这个目标来明确各团队的任务，接着又从任务入手，细分出我们的季度目标和要取得的关键成果。
我见过太多团队都是直接跳到了最后一步，还没有先确定一个共同的目标，就奔着结果去了。
2. 你的团队不知道如何验证思路的可行性
第二个导致结果驱动型方法失效的原因是，你的团队不知道如何验证思路是可行的。
这个问题产生的原因，很可能是你的公司正在经历转型，从原来传统的由上而下的公司文化，转变为结果驱动型的产品开发框架，不再聚焦对特定功能的开发。
如何验证思路的可行性，这个主题本身就可以再另外写篇文章探讨，在这里我就用一张图来说明，我们是如何在开发过程中，利用用户的反馈来进行验证。
3. 你没有得到高层的许可
这通常来说是转型过程中最大的拦路虎，下面介绍几种不同的方法来解决这个问题：勇敢地向别人阐述你的想法。我们似乎很少花时间和别人解释自己的方法论，似乎这是整个行业的通病。
大多数人会有这样的想法：如果说一家比我们还好的公司，他们都还在循规蹈矩，为什么我们就要调整呢？不过，只要你能解释到位，科学的方法仍然是容易被别人接受的。建议你用一些比喻，让自己的表述更加生动。
比如你可以这样讲：如果我是一支探险队的领队，我下达命令说要建一座桥，那队员们很可能花大量的时间去找造桥的材料，最后造出来的桥也许还不够结实，不能满足全队安全渡河的要求。
但是，如果我告诉他们，我想让全队安全过河，那么队员们很可能会拿出各种不同的办法：造木筏、寻找河流的浅滩等，而且大家都非常清楚，什么时候算是完成了任务呢——那就是大家都能安全过河了。
向领导询问导致问题的原因，而非解决方案。
如果你这样问领导：“我们在做明年的产品路线图，您认为有什么功能需要加进来吗？”你不可避免地会得到这样的答复：“我们要在登陆页面加一个蓝色的窗口小部件，放一个视频告诉用户，我们能提供什么样的服务。”
实际上，我们更推荐你围绕现有的问题提问，比如：“我们明年的目标是提升登陆页面的转化率，您觉得有什么原因在导致用户数量下降呢？”
那么，你很可能得到更具建设性的答复，像是：“我们觉得用户转化率低，很可能是因为他们不太清楚我们能提供什么服务。”
向大家证明，少即是多。
有时候你会发现，不断地添加新功能，可能只是你的一厢情愿，说不定功能越少反倒越好。微软曾经通过一次试验，发现有将近 1/3 的功能给产品带来的是负面影响，还有 1/3 压根没有产生影响。
当他们不同意你的解决方案时，试着提议先做一个测试。
如果领导不同意你的方案，可以试图找到一个成本较低的测试方法，并在合适的机会下向他们提议，说不妨先测试一下看看效果。
4. 团队工作重叠了，你该怎么办？
如果你像以前一样，按照不同的功能为团队分工，的确很容易确保大家各司其职，但改为结果驱动型的方法时，你就很可能会遇到这个问题。
比方说，在共同目标的引导下，不同的小组有不同的开发任务，那么当这些小组任务之间产生矛盾时，应该如何确定它们的优先级呢？
例如，一个小组的任务是减少产品内的诱导性宣传，而另一个小组的任务是提高用户的转化率，显然两者之间存在一定的冲突，这时候，就需要组织你的产品开发团队共同协商了，大家必须要有清晰的大局观。
五、回到产品路线图来
我已经介绍了结果驱动型方法的好处，以及如何应对一些常见的问题，但不得不承认，有些时候你还是需要有个产品路线图，尤其是有外部团队参与的时候，因为他们需要知道，你大致会在何时推出什么功能。
退一步说，即便是一个只有象征意义的产品路线图，也能在一定程度上消除他人的顾虑和疑惑。但是你需要调整心态，不要再将产品路线图视为一个“义务清单”，实现结果比推出功能更重要。
事实上，你要构造产品路线图，必须要有清楚的路线和地点，但无论是从产品设计还是工程学的角度来看，现实中的企业很难做到这点。
生活不像谷歌地图那样路线清晰
每一次产品开发都像是一次对新大陆的探索，你知道想去哪里——也就是你希望达到的结果——但却没有明确的路线。因此，你只能踏上征程，每走出一步，都准确地定位自己，并不断获得反馈，那么你就能沿着正确的道路，走向你所期望的结果。
其实，直到整个旅程结束，你才能回过头来，画出完整的产品路线图。思路一变天地宽，不妨暂时忘掉功能，关注结果吧。
原作者：Alice Newton Rex
原文链接：https://www.mindtheproduct.com/2018/10/escape-from-the-feature-roadmap-to-outcome-driven-development/
翻译：即能，公众号：「即能学习」
本文由 @ 即能 翻译发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议。
