产品路线图不是纯粹的功能列表。您应该放弃对函数的过度关注，但是要关心我们最终想要什么以及需要解决什么。这样，你就可以摆脱功能路线图的束缚，转向更科学的产品开发模式。  

其中，在WorldRemit工作的前3年，我为公司制作了10多种不同类型的产品路线图。  

改变设计理念的原因是，我希望通过尝试至少具有一些优势，找到最有效的产品路线图：更有针对性、更有效的与股东的沟通，以及领导团队高效地协作。  

在我看来，大多数产品路线图现在都有一个共同的大问题：产品路线图被制成一个纯粹的功能列表，唯一的区别是这些功能被放在一个时间线上（并且不是很清楚）。  

事实上，功能列表存在很多问题。最直接的事情是公司，包括你的客户，会认为这样的功能清单是你的承诺，你会毫不犹豫地兑现承诺，这给开发团队带来了巨大的压力，并且必须是原创的和本地的，才能遵循这个清单。南墙，你不回头。  

回首过去，您会发现这些功能根本解决不了问题，即使它们解决了，它们也是很小很微不足道的问题。这个团队的任务是日复一日地完成列表上的任务，即使产品开发的环境（包括G公司的战略、用户需求、行业竞争格局等都发生了变化。  

作为一名产品经理，列出一系列的职能会让你处于尴尬的境地。大公司的顶层和底层公司治理文化清楚地定义了主管和股东在产品开发中的绝对话语权。他们向产品团队提供功能开发指导，并且团队只能遵循这些指导。  

类似地，如果你加入一家商业公司，公司的创始人通常会决定如何完成产品，只要你给他一个空白的清单，它会立即填满你。  

此时，作为产品经理，您几乎没有自主权，充其量只是一个指令接收器，您只需要尝试并尝试呈现老板想要的功能。  

在功能路线图的框架中，即使你是一个好的产品经理，也只能确保你做得很好，并且你不能控制产品的整体有效性，这就像赢得一场又一场局部战争，最终输掉整个战争。  

设想一下：到年底，你完成了产品的开发，并向管理团队汇报，你告诉他们计划中的所有功能都已经完成了。不管你做的是什么不可思议的任务，他们仍然会对你大吼大叫，说你打中了他们的想法。一点效果都没有。  

如果您正在执行面向功能的路线图，那么很可能会发生这种情况，可能是因为您被迫开发的功能没有达到预期的效果，但是您仍然必须最初执行它。  

从现在开始，您应该放弃对函数的过度关注，但是要关心我们最终会遇到什么以及需要解决的具体问题。  

试着问问自己，如果我们的产品开发成功，将会给世界带来什么样的变化我们的用户会有什么样的体验他们能用我们的产品做什么  

在特定的时间段内，每个团队都应该为共同的、明确的目标或结果而努力，而不是草率行事。  

任何好的目标都应该被测量和测量。同样，必须验证您设置的结果。最直观的反馈是，你的产品能得到用户和行业的认可吗  

如果结果是，用户可以看到更多的广告，这对于用户来说是毫无价值的，并且由于这个结果，在商业上不太可能成功。  

因此，产品经理不再是管理的管理者。如何进行产品开发，开发出什么样的功能，达到什么样的效果，已经成为整个团队的问题。  

这种方法的最大优点是团队在团队中具有更大的自主性，并且每个成员都能够发挥其专业专长和创造性。L是实现的，我们不需要管理任何功能。  

当你对自己想要达到的结果有更清晰的理解时，你会发现自己比以前更加开放，更有可能解决问题。  

EdwardDebono博士（EdwarddeBono）在他的书《横向思维》中引用了一个非常经典的例子：一个大公司的经理遇到了一个问题，公司搬到了一座新的办公大楼，结果发现，该大楼的设计师没有得到考虑，也没有配备足够的电梯。员工经常抱怨电梯很长时间。  

许多管理人员提出了加快电梯速度，或者在建筑物中切割电梯轴以增加体积的方法。然而，他们最终采取了不同的方法，并采用了完全不同的方法，这也成功地解决了这个问题。  

他们在电梯的入口处安装了很多镜子。当他们早上来上班时，他们把注意力集中在镜子里，忘记了等待电梯的辛勤工作。  

在这种情况下，管理人员真正需要解决的问题不是电梯不够，而是员工在等电梯时的烦恼。  

这种新设计思想的另一个好处是避免开发团队向产品添加过多的功能，尤其是用户不需要的功能。  

结果驱动的方法可以引导团队集中精力改进现有功能，最大化这些功能的影响，而不仅仅是考虑添加新功能。  

我曾经和一个朋友讨论过这个问题。他的电子商务产业最重要的指标之一就是转化率。他们有年终统计数据。结果表明，推广的重点不在于新功能的添加，而在于现有的工作，通过优化图像处理技术等技术改进，大大提高了网络加载的速度。  

但是，像其他任何方法一样，再次尝试是不合适的。在本文的其余部分中，我想重点介绍什么是可能的以及如何避免结果驱动的方法。  

首先，最重要的是，如果你的公司没有明确的公司战略，那么结果驱动的产品路线图将不可避免地失败。  

在WorldRemit，我们首先定义公司的年度目标，利用这个目标来明确团队的任务，然后从任务开始细分季度目标和要达到的关键结果。  

我见过太多的球队跳到最后一步，没有确定一个共同的目标，走到最后。  

出现这个问题的原因是，您的公司正在经历从原始的传统企业文化到结果驱动的产品开发框架的转变，不再关注特定功能的开发。  

如何验证这个想法的可行性，本课题本身可以在另一篇文章中讨论。这里，我使用一个图片来说明如何在开发过程中使用用户的反馈来验证它。  

这通常是过渡过程中最大的绊脚石。这里有几种不同的方法来解决这个问题：勇敢地向别人解释你的想法。看起来我们很少花时间和其他人解释他们的方法，这似乎是整个行业的常见病。  

大多数人认为，如果一家公司比我们公司好，他们仍然在规则中。为什么我们必须调整然而，只要你能解释清楚，科学方法还是很容易被别人接受的。有人建议你用一些隐喻来使你的表达更加生动。  

例如，你可以说，如果我是远征队的队长，我命令建造一座桥梁，而队员们可能会花很多时间寻找桥梁的材料，而且桥梁可能不够坚固，无法满足整个队伍的安全。  

但如果我告诉他们我希望球队安全地过河，那么球员们可能会想出各种各样的方法：做木筏，寻找河滩等等，而且每个人都很清楚什么时候可以过河——也就是说，每个人都可以过河。  

如果你这样问领导：我们明年要做产品路线图。你认为有什么功能需要补充吗您必然会得到答案：我们必须在着陆页面上添加一个蓝色窗口小部件，并放一个视频告诉用户我们能够提供什么样的服务。  

事实上，我们建议您就现有的问题提问，例如：我们明年的目标是提高登陆页面的转换率。你认为什么原因导致用户数量下降  

嗯，你可能会得到一个更具建设性的回应，比如：我们认为转换率很低，可能是因为他们不知道我们能够提供什么服务。  

有时你会发现添加新功能只是你的一厢情愿，而功能越少越好。微软已经通过一项实验发现，几乎13对产品有负面影响，而13根对产品没有影响。  

如果领导不同意你的计划，试着找到一个低成本的测试，并在合适的机会向他们建议先测试效果。  

如果您与以前相同，那么很容易确保每个人都根据不同的功能进行分工，但是当您将其更改为结果驱动的方法时，很可能会遇到这个问题。  

例如，在共同目标的指导下，不同的团队有不同的开发任务，当这些团队之间存在矛盾时，他们应该如何区分优先级  

例如，团队的任务是减少产品内的诱导性宣传，而另一组的任务是提高用户的转化率。显然，两者之间存在着一定的冲突。此时，有必要组织您的产品开发团队一起进行咨询，并且我们必须对情况有一个清晰的认识。  

我已经介绍了结果驱动方法的好处，以及如何处理一些常见问题，但是您必须承认，有时您需要产品路线图，特别是当存在外部团队时，因为他们需要知道何时将介绍您可以做什么。  

退一步讲，即使一个符号化的产品路线图也可以在一定程度上消除他人的关注和疑虑。但是您需要调整您的心态，而不是将产品路线图看作一个义务列表，并且实现结果比启动功能更重要。  

事实上，您必须有一个清晰的路线和地点来构建产品路线图，但是对于真正的企业来说，无论从产品设计还是工程的角度来看，都难以做到这一点。  

每一个产品的开发都像是对新世界的探索。你知道你想去哪里，那是你想达到的，但是没有明确的路线。结果，你只能踏上旅程，每走一步，准确定位你自己，并获得反馈，然后你就可以沿着正确的道路到达你所期望的。  

事实上，直到旅行结束，你才能回来绘制完整的产品路线图。这个想法是改变世界，还不如暂时忘记功能，注意结果。