【产品小记】B端产品的同理心

上周五，和老板一起跟一位刚转入产品岗的管培生同学沟通她近两个月的产品工作体会。她列出了在网上查找到的关于产品经理的能力图谱，足足快30项，她还非常有心的为每一项能力划分了十个等级，并用不同颜色区分了。乍一看，我觉得已经很全面了，结果老板的一席评论让我反思良久。

他说，这些还不够，除了产品的硬性知识技能外，你这些能力换一个岗位是不是也是需要的，比如学习能力、沟通能力、团队管理能力。而产品应该有的特质是什么呢？

他说，首先是同理心，然后是好奇心、理想主义以及坚韧。

是啊，产品最内核的职责是为用户代言，同理心是一位合格的产品经理首要的品质。产品这个岗位从诞生以来就是在公司内部代表用户开发声、抗争以及提出用户导向的解决方案的。这就是跟其他岗位在内核上最大的不同。

为用户代言，在很多C端产品眼中是天经地义，因为用户不在身边，他们要研究用户走近用户才能去设计产品。而B端产品，尤其面向组织内部管理运作的B端产品，需求的来源就是用户，大家一般都是在被用户推着做事情，那大家可能会说了，用户难道还代表不了用户吗？所以，很多B端产品经理慢慢的会把自己置为用户的合作者的角色，甚至在有矛盾的时候会把用户当作对手。

但是，用户真的能代表用户吗？产品怎么能代表用户？

昨天被同组的产品小伙伴拉去临时开一个会议，很有意思，这个会议的业务方有很多的角色，包括项目主业务PM和他的领导、需求方部门的对接人代表、未来实际的执行业务、需求方相关部门的同学，当然还有主产品以及我这个配合方的产品。这个会议的目的是，对于前期需求梳理完之后制定的初版产品方案，在投入开发前大家在一起做一次check，也就是业务端PRD评审。

在主业务同学介绍整体流程、以及主产品介绍整体方案的时候，业务方对接人代表包括实际执行业务都没有声音，在听了一小段之后，我发觉这个方案的范围和核心的业务基础逻辑存在很大的漏洞，所以立刻提出了质疑。

简单来说，这个项目是把原有比较分散和滞后的一个管理环节做前置和统一管理，这原本是一件必要且好的事情。但是这个项目的核心负责人仅仅考虑到了新增一个管理环节，而没有想到如何与原有的管理环节协同，是否要简化甚至去掉原有的管理环节呢？流程之间的衔接维度是否能对齐呢？按照这样的方式实现，实际操作人在系统上线后将面临着工作量double的问题，这无疑将是一次重大的设计失误。

在我提出这个质疑之后，项目主业务PM和需求方代表立马跳出来，说这个不是这次项目的范围，之前的沟通已经确认好了之类之类，甚至项目主负责业务领导提出来，资源已经锁定、上线时间已经敲定不能再新增需求。这时候，真正的用户没有发声，用户代表没有发声，只有产品能够去坚持和推动这个事情。我立刻提出来，这个项目的目标到底是按时上线，还是要达成既定的提效的ROI，按照这个方案执行必然达不成ROI还会给业务执行方带来巨大的执行困难，所以如果要做必须要把全流程的改造考虑清楚，否则产技不会接收这样的方案。这时候，大家都不再纠结了，而是转而给出意见看后面需要如何梳理和确认新的业务规则。从而，通过产品的沟通，解决了一次设计危机。

事后，那位年轻的主产品同学来找我复盘这整件事情，他说之前在设计方案的时候就提出过这个质疑，但是业务方代表一直说没问题，所以他就没有再继续深究，那么如何避免下次再出现类似的事情呢？

看待这件事情，首先要了解一个事实，那就是用户有时候也代表不了自己。为什么这么说？第一，不同用户参与到这件事情的目的不一样，比如这个会议中有人只想把项目推进下去；第二，用户代表可能对于自己的职责不够明确，比如这里面的需求方代表只是作为一个组织人，并没有真正了解一线人员的实际操作；第三，一线执行的同学可能没有全盘思考的能力来判断这个事情的影响。

其次，产品经理要具有通过逻辑推导深度质疑和刨根问底的钻研精神。面对这种疑惑的时候，需要相关方拿出实例来说明真的没有影响，而不是仅仅让对方给一个回复，如果对方一口咬定一个结论，但是从逻辑推导的角度来说不合理，那么产品同学需要进一步的去追寻结论，直到事情可以逻辑自洽。

最后，产品经理如何能具备站在用户的角度思考问题的能力呢？答案其实很简单，走到一线去，走到一线去，走到一线去。去体会，去感受，同时要把点状的场景和操作，汇聚成业务流，汇聚成业务域，汇聚成系统整体的规划。这样才能在了解用户的同时，具备通盘思考的能力，从而在关键的时刻可以快速指出问题解决问题。