产品经理大忌：脱离用户

                                                脱离用户，这是做产品的大忌，这个理论几乎每个产品经理都知道，但实际真正做到不脱离用户的产品经理并不多，至少在火山能够接触到的范围内的产品经理，就大面积地存在这样的问题。扪心自问，在脱离用户这条弯路上，火山也留下过不少坚实的脚印。

我之前所负责的是一款toB类的业务型产品，需求的主要渠道就来源于销售与客服，产品设计基本是围绕着业务需求展开的，因此，业务部门在我们公司具有非常强的话语权。而与此同时，我们产品经理接触实际用户的机会非常少，脱离用户的情况基本是常态，接下来跟大家分享一个真实的产品案例。
之前，我在《为什么说完美主义的产品理念背后潜藏着一个天坑》一文中分享过一个“订单拦截”的项目案例，这个案例主要是针对的是机票订单，大意是讲我们的客户希望能够在前台用户下单之后将机票订单进行拦截，人工决定是否通过我们系统自动出票。但对于最终通过我们系统自动出票的订单而言，订单中附带的保险也将从我们系统自动出保。
在这个功能上线大概2个月之后，我们一个新来不久的销售同事又回来给我提了另外一个“姊妹需求”：
我们有一个大客户表示订单拦截的功能挺实用的，因此，对于机票订单中附带的航意险、航延险等产品，他们也希望可以做一个“保单拦截”的功能，因为保险产品他们也有自己的出保渠道。
听到销售同事说自己之前做的产品得到了客户的认可，不仅之前做订单拦截功能时被客户无情否定的失落感瞬间荡然无存，甚至还有一种幸福感油然而生。那么，在我接到这个需求之后，我是怎么做的呢？
假设你是接到这个需求的产品经理，你打算如何实现这个需求？
思考1分钟，计时开始……

由于订单拦截的先例已经得到了客户的认可，而“保单拦截”是一个同类型的需求。因此，被幸福感“冲昏头脑”的我几乎没有考虑这个需求的合理性，几乎立马就投入到了这个项目的设计当中……
首先，拦截开关是无法共用的，因为订单拦截之后，本身保单就是需要人工出的，因此需要增加一个保单拦截的开关。
其次，需要考虑可能的拦截场景：机票订单自动出，但是附带的保险订单做拦截；机票订单手工出了之后，保单还有可能需要从我们平台自动出，但无论如何下单的流程需要调整。
再次，需要考虑扣款流程的一些调整：如果机票自动出了，但是保单不自动出，那么扣款怎么扣？相应的，发生退票之后，退款了里流程怎么走，自动还是手工？
然后，一些可能的特殊场景：下了机票订单，机票出票了，但是保单并未及时手工出保，需要如何处理？整张订单的状态算正常还是异常？
……
在经过一个星期左右的梳理之后，我基本把各类场景下的业务逻辑都梳理清楚了。当然，这次我没再犯一蹴而就的低级错误，我拿着我梳理好的流程图，找到了开发经理评估技术可行性方案，开发经理又给我补充了一些我未考虑到的场景，具体不再细说，总的来说最后，最后大概需要一个多月的工期能够开发完成的方案，这还不包括测试的时间。
工程量不算小，但总体而言，方案可行性是没有问题的，我又把大致的方案销售和客服的同事都做了讲解，他们基本也没有提出什么异议。但是我总觉得哪里不太对劲，于是，我又让销售同事把客户的联系方式给了我，我把我的方案巴拉巴拉又给客户说了一遍，而客户的态度似乎跟销售和客服的同事没什么太大的差异。
此时，但就这个功能而言，我的方案已经得到了内部、外部几乎所有人的认可，理论上说，我的产品方案在大方向上应该是没有大问题了。但是，就在我准备挂掉客户电话，开始进行详细方案设计的时候，我不经意间的一个提问却在一瞬间改变了整个局势，最终让我把我的整个方案全盘推翻。
想一想，这会是一个什么样的问题？
思考1分钟，计时开始……

“x总，我能了解下你为什么想要做这样的保单拦截的功能吗？”我问道。
“因为你们的保险成本需要5元钱，我们自己的出保渠道只需要4元钱左右，走你们的渠道不合算。”客户也毫无保留地给说了他们的想法。
我这才意识到，其实客户需要的 “保单拦截”功能，这只是一个表象需求，根本需求实际上还是成本考量。而实际上，我们渠道的保单成本是可以降到3.5元左右的，也就是说可以比客户自身渠道的成本还要更低。而出现5和3.5元的保险成本的信息失真，可能是由于新来的销售同事对于业务不熟导致的。后来，经过跟客户的再次沟通，我们把保险成本的信息给客户做了一次重新的传递，客户当即表示：“那这样的话，就用你们的保险好了，我们还不用人工去盯着，人工成本也省下来了，还省心。”
最终，我们在产品上再没有投入1分钱的人力物力，通过改变客户的想法的方式就满足了客户的需求，与此同时，还帮助客户降低了采购成本，实现了双赢。
案例分享完毕，发生在火山身上的这个真实的项目案例是否带给你某些启发？
思考1分钟，计时开始……

火山复盘
在这个案例中，我想当然的认为“保单拦截”和“订单拦截”是同样合理的需求，犯了一个很明显的错误——缺少需求调研，再将这个错误升华一下就是——脱离用户，而这个错误直接导致的影响就是，它让我对伪需求的分辨能力直线下降！
作为一家toB类型的互联网企业，火山所在的创业公司跟大多数面向B端的互联网公司一样，销售在公司的话语权非常强，尤其是早期的时候，我们大部分的需求基本上都是被销售牵着鼻子走。后来随着业务量上升，主要的需求来源从销售转移到了运营，于是我们的产品思路又围绕着内部运营的实际业务展开。产品经理脱离用户基本是一种常态。有时候哪怕明知道他们提的需求不合理，产品经理想跟他们争论一下甚至都没有底气，因为我们接触用户真的没有他们多，有时候争论急眼的时候，他们甩出来一句“你了解客户还是我了解客户”可以直接把产品经理“噎死”。
但无论是销售还是运营，实际上都不是我们产品的最终用户，终端用户的实际需求经他们转述之后势必产生信息损耗或失真。基于二手的用户需求做出来的产品，势必很难把握用户的核心痛点和真正诉求，最终导致我们做出的产品如同隔靴搔痒，根本无法为用户创造真正的价值。脱离用户的产品经理，势必难以有效地掌握产品的走向，无论最终是被销售还是被运营所主导，都只会停留在具体的功能需求落地执行层面，头痛医头脚痛医脚，无法挖掘到用户的真正需求。按照如此的路数做产品，也许我们拼尽全力，最终可以给我们的用户提供无数更快的马，却永远无法给他们提供一辆更快更舒适的车。
因此，无论toB还是toC，要想做出真正好的产品，脱离用户都是产品经理的大忌！然而，画原型、做方案、写PRD，与老板沟通、与程序员沟通、与设计师沟通、与业务部门沟通、各类会议、跟踪项目进度……产品经理日常的工作如此之细碎繁杂，每天泡在用户当中显然也是不现实的。
那么，如何保证产品经理的日常工作正常推进的同时又不脱离用户呢？在最后，火山把自己总结的几个小建议分享给大家，希望可以对大家有所帮助：
[ol]

做任何需求，跟需求方做需求调研是最基本的产品工作，是绝对不能省的；

如果这个需求来自于明确的终端用户，则在内部需求调研之后需要向终端用户做直接的需求调研。跟终端用户去聊，了解他们在想什么，他们有什么痛点，他们最想解决的问题是什么，这也是不能省的，不能想当然地认为业务、销售同事做过需求调研了，就可以不再跟用户去做调研了；

在有了大致的产品方案之后，再跟终端用户聊一聊，看看方案是否有方向性的问题，及时发现、修正方向性的问题；

在原型文档出来之后，如果条件允许的话再给客户展示一下原型方案，在提交开发之前尽可能地发现并修正一些细节性问题。
[/ol]
后记
产品是做给用户用的，但做产品的产品经理却不了解用户，看似很不可思议，可这样的情况却也并不鲜见，哪怕是从业3年以上的产品经理也不例外。将一个需求转化为具体的产品落地方案，做到无懈可击也不是没有可能的，但是产品经理往往会忽视的一个问题就是，这个需求到底要不要做？而想清楚这个问题往往比前者更加重要和意义深远，产品经理如何才能对这个问题做出更加明智的判断？这个能力是多方面因素决定的，但需要时刻铭记的一点就是——永远不能脱离用户。