公众号：PM火山

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

　　我之前所负责的是一款toB类的业务型产品，需求的主要渠道就来源于销售与客服，产品设计基本是围绕着业务需求展开的，因此，业务部门在我们公司具有非常强的话语权。而与此同时，我们产品经理接触实际用户的机会非常少，脱离用户的情况基本是常态，接下来跟大家分享一个真实的产品案例。

　　之前，我在《》一文中分享过一个“订单拦截”的项目案例，这个案例主要是针对的是机票订单，大意是讲我们的客户希望能够在前台用户下单之后将机票订单进行拦截，人工决定是否通过我们系统自动出票。但对于最终通过我们系统自动出票的订单而言，订单中附带的保险也将从我们系统自动出保。

　　在这个功能上线大概2个月之后，我们一个新来不久的销售同事又回来给我提了另外一个“姊妹需求”：

　　“我们有一个大客户表示订单拦截的功能挺实用的，因此，对于机票订单中附带的航意险、航延险等产品，他们也希望可以做一个“保单拦截”的功能，因为保险产品他们也有自己的出保渠道。

　　听到销售同事说自己之前做的产品得到了客户的认可，不仅之前做订单拦截功能时被客户无情否定的失落感瞬间荡然无存，甚至还有一种幸福感油然而生。那么，在我接到这个需求之后，我是怎么做的呢？

　　假设你是接到这个需求的产品经理，你打算如何实现这个需求？

思考1分钟，计时开始……

　　由于订单拦截的先例已经得到了客户的认可，而“保单拦截”是一个同类型的需求。因此，被幸福感“冲昏头脑”的我几乎没有考虑这个需求的合理性，几乎立马就投入到了这个项目的设计当中……

　　首先，拦截开关是无法共用的，因为订单拦截之后，本身保单就是需要人工出的，因此需要增加一个保单拦截的开关。

　　其次，需要考虑可能的拦截场景：机票订单自动出，atv，但是附带的保险订单做拦截；机票订单手工出了之后，保单还有可能需要从我们平台自动出，但无论如何下单的流程需要调整。

　　再次，需要考虑扣款流程的一些调整：如果机票自动出了，但是保单不自动出，那么扣款怎么扣？相应的，发生退票之后，退款了里流程怎么走，自动还是手工？

　　然后，一些可能的特殊场景：下了机票订单，机票出票了，但是保单并未及时手工出保，需要如何处理？整张订单的状态算正常还是异常？

　　……

　　在经过一个星期左右的梳理之后，我基本把各类场景下的业务逻辑都梳理清楚了。当然，这次我没再犯一蹴而就的低级错误，我拿着我梳理好的流程图，找到了开发经理评估技术可行性方案，开发经理又给我补充了一些我未考虑到的场景，具体不再细说，总的来说最后，最后大概需要一个多月的工期能够开发完成的方案，这还不包括测试的时间。工程量不算小，但总体而言，方案可行性是没有问题的，我又把大致的方案销售和客服的同事都做了讲解，他们基本也没有提出什么异议。但是我总觉得哪里不太对劲，于是，我又让销售同事把客户的联系方式给了我，我把我的方案巴拉巴拉又给客户说了一遍，而客户的态度似乎跟销售和客服的同事没什么太大的差异。

　　此时，但就这个功能而言，我的方案已经得到了内部、外部几乎所有人的认可，理论上说，我的产品方案在大方向上应该是没有大问题了。但是，就在我准备挂掉客户电话，开始进行详细方案设计的时候，我不经意间的一个提问却在一瞬间改变了整个局势，最终让我把我的整个方案全盘推翻。

　　想一想，这会是一个什么样的问题？

思考1分钟，计时开始……

　　“x总，我能了解下你为什么想要做这样的保单拦截的功能吗？”我问道

　　“因为你们的保险成本需要5元钱，我们自己的出保渠道只需要4元钱左右，走你们的渠道不合算。”客户也毫无保留地给说了他们的想法。