以前做To C后来转To B，期间有不断的一段时间内，在面对用户进行需求分析和实现的时候，不仅产品做的差强人意，还把整个团队弄得身心疲惫。最累的时候，甚至需要1周发大小两个版本，后来意识到问题越来越大，必须停下来重新梳理思路，进行调整。
领悟到一个可能和之前把用户当上帝完全不同的想法。在面对To B的许多用户时，用户并不是上帝。尤其很多To B的产品形态是SaaS级平台，完全依赖于用户作上帝的角度看问题，不仅会把自己弄得很累，而且难以把控产品，获得产品的成就感，更像一个乙方外包。
B端的用户，不同于C端的一个点还在于大部分B端产品都是付费的，所以作为用户，通常会有以下几种表现：
1、不断质疑你，强硬的态度
2、提不完的需求，
3、大客户对产品指手画脚，甚至严重的会干扰到产品的规划
4、永远有不符合心意的功能模块
5、出现问题就爆炸，不管是谁的问题（我就遇到过，自己网络信号不好，责怪产品加载速度太慢，产品背锅）
…诸如此类…
如何对于所有情况，全盘接受，那最终可能的结果是吃力不讨好，用户有时候也不一定是上帝。
对于B端，虽然是面向企业，面向团体，但具体使用产品的还是人，所以当产品出现反馈和问题时，如何从一大堆的可能的质疑，投诉和需求中，抽丝剥茧，找出核心才是关键。很多情况下，不像C端的转移成本门槛低，B端产品的转移成本是比较高的，比如用户体验不好的点，暂时某项功能缺失的点，这些非核心的点，都是可以接受的，首先满足对于核心需求的使用才是关键。
比如金蝶，用友这些ERP软件，他们的体验未必好，早期功能肯定有很多缺失，但是许多企业依然使用，关键在于它们可以解决企业管理的问题，可以让企业的资产调动起来，可以降低企业的成本，可以管控员工。它最终是在解决企业的效率问题，这才是产品的核心需求所在，其他的不过是次一级的，有时候客户提出来，不过是在施压或者发泄不满，解决了核心需求，这些剩下的都是可以一步步来的。
当然，这对于To B的产品经理来说，如何和业务方，需求方处理好关系，给出合理的方案，也是一个很重要的技能点和职业要求。
所以通常情况下，把握几点，可以大致地判断一下
1、是否是高价值需求，这个通常需要和需求方做一下沟通，高价值的才是核心需求
2、有这个需求会怎么样，没有会怎么样，会不会影响到关键业务
3、时间估算需要多长，时间的成本能否承受
至于用户体验等这些问题，可以作为完善型的需求，进行安排，毕竟解决企业的问题，才是B端的核心意义所在。
网友评论