B端产品经理的机会

周末跟做研究员的3个朋友聊天，他们一个在南方基金，一个在中庚基金，还有一个在榕树资本。聊到系统方面的问题时，大家纷纷探讨自己工作中有什么好的软件、公司提供了什么好的系统：

然后比较好的情况是，有的公司自己研发了一些word和excel的插件，方便大家快速处理研报、数据等信息，更好点的是自建了平台，实现了模拟组合，个股推荐，内部研报系统等功能。并且负责这个平台的产品经理特别受研究总监重视，形成了很好的业务和产品合作关系。

如果没有自研的公司，就大多用wind等平台型产品，往往体验很差且不能个性化研发。如果找小团队外包支持，又往往研发质量很差。好点的研发公司合作付费，要一年100多万，还没发体验到产品是否可用，如果不可用的话后期切换的成本更高。

所以整体B端产品行业现状来看，主要有以下几个特征：

1. 只有头部公司养得起自研团队，能够有比较好的产品自用。

2. 业务人员不懂产品，沟通起来非常弱势，难以推动产品优化。

3. 平台化和定制化没有达到平衡，产品积累不足。

4. 产品经理良莠不齐，业务整体对于产品的期望不高，难以有较大投入。

所以以上整体这些情况，造成了B端产品的不景气，但同时也昭示着B端产品经理的机会。要拿下这个机会，就要引导行业变革，让业务放心和产品合作，同时产品可以做出真正好的东西武装业务团队，这样才能在业务主导的行业，慢慢融入产品的力量。

如果要做好这项事业，需要以下3个能力。

B端业务能力

说到B端能力，我们先讲一个事实。

上文我们讲的那个很厉害的产品经理，做出很多模拟组合功能的产品经理，其实是研究员转行的。也就是说，只有做过研究员，做过业务，做过B端用户，才能深切的识别到哪些需求是合理的，哪些是假的痛点。如果不懂B端业务，做出来的东西就是驴唇不对马嘴，很容易就会陷入想当然的境地。

上文那个产品经理做的功能都不复杂，比如一个查询功能，可以搜索所有的研究员组合调整记录，再在个股推荐的时候关联研究记录。这些功能就极大减少了研究员的检索成本，同时还提供了新的数据维度来帮助分析，提升了研究员的工作效率和产出。

最近很多微信公众号插件，给作者提供了很好的便捷工具，让写作体验更好，极大提升了产出。而这些插件的功能点，并非是普遍的功能点，而是B端业务独有的场景和功能。如果没有真的写过微信公众号，很多人是无法体会到操作流程中的痛点的。

所以我说，好的B端产品经理未必出在互联网产品经理之中，因为懂业务这点太重要了。如果不懂业务，就是空有一身招式，无法用正确的内功驱动，做出的产品也没有内在了。而懂业务的最好手段，就是变成用户，能够适当轮岗或定期调研，是比较好的培养B端产品经理的方式。

平台产品能力

平台产品能力主要包含两部分，一个是平台能力，一个是产品能力。

比如我的朋友说，他们的一个查询功能，经常不好用，很多时候就直接卡死了。他根据这个事实，问我“程序员之间有什么差别？为什么我们用的这款产品这么多BUG，这么难用？”，我的回答是这样的：

通常，我们在研发过程中，其实是不太喜欢讲BUG的。因为BUG本质上只是一种需求和研发成果的不匹配，直接讲“这块跟需求不太一样”就可以了。但业务是没有产品意识的，他们会认为只要不好用，就是BUG，只要修复不了，就是程序员调BUG的能力太差。而一个业内有经验的产品经理来看，在目前行业代码工程能力已经积累到一定程度的情况下，往往问题都出现在产品经理身上。

通常50%以上业务人员认为的BUG，都是产品经理没有调研好需求、没有设计好方案。在业务人员眼中，是只能关注到产品的显性特征的，他们只在乎刷新速度快不快、页面好不好看清不清晰，而背后的逻辑是看不到的。这样的结果就导致业务方很难和研发团队平等沟通，毕竟产品能力的欠缺导致了心虚，并且无法抓到当前产品的主要矛盾。

比如微信这个搜索页面，对于这样量级的平台，并发量是非常大的，这个搜索的优化也非常重要。目前我看到的逻辑是，默认先搜索3条结果，当然也可能是近三年的全部结果，剩下的要下拉刷新后再展示出来，这样就完成了搜索的分页，能够平衡信息展示和搜索性能。

是不是说一下子全部搜索出来不能做呢？其实不是的。任何功能都是可以实现的，只不过看要多少时间、人力、服务器资源罢了。我们之所以不是所有搜索都做全量搜索，主要是看需求到底是怎么样的，如果99%的用户都只查询3个月并且没有继续刷新，那我们完全可以第一屏只展示3个月的。也就是说，通过探寻系统边界，再形成需求逻辑来权衡性价比，这个工作是产品经理来做的，需要很深厚的平台产品能力，并且对于平台至关重要。

沟通能力

沟通能力其实主要是表达能力和冲突化解能力。要能把自己的产品用大家爱听的语言讲清楚，同时面对立场和利益的冲突时，能够很好的调和。

对于B端业务来说，产品研发是一项重资产投资。需要定期投入很多资金成本来进行系统的维护，并且短期内很难见效。很多研发团队交付从0到1的产品少说也得一个季度，并且这个版本还未必能满足业务团队的需求。同时，研发的钱往往从业务团队的业绩里来出，产品团队在以赋能业务为目标分吃蛋糕。那么也就是说，对于业务团队来说，本身对于产品团队就是不信任的，这时候再有一两次没有很好的支持，后续是很难配合的。

所以做B端产品的时候，和C端产品的心态是不一样的。C端产品成王败寇，大家一起申请预算，一起拼杀，一起小步快跑迭代试错。而B端的每一步都需要权衡业务的意见，毕竟研发投入和赋能的都是业务部门。要有好的合作关系，就要有营销的心态，因为B端产品是一个先画饼再实现的过程，要在服务之前就把服务卖给用户。所以要和业务部门有好的契约关系，管控好预期，才能长久良好合作。这里就需要很强的沟通能力。

和业务沟通，要充分考虑对方的立场和价值观，为业务线和业务指标创造新的价值，同时能够帮助他们突破人工的天花板，才能养成良好的合作关系。

传统企业科技转型

从B端产品经理行业现状，聊聊如何科技转型。

对于科技转型来说，其实主要是整体思维的转型，需要全员思维互联网化、产品化。比如一个没有产品思维的业务人员，是不认同产品、不理解产品的，这个时候他们规划出来的东西，初期也没有产品经理的参与，就会导致提交到产品经理这的方案往往不合理，而产品经理因为项目的时间要求必须强制接受。这样整个产品就走了很多岔路。

所以我觉得，如果一个传统企业从价值上衡量要做科技转型，必须优化掉这类人员，否则进展会非常缓慢，导致转型成本增加，转型价值降低甚至失败。

这些不具备产品思维的业务人员，通常会：

1.他们会质疑产品人员的专业性，增加需求分析的难度

2.他们会在产品次要特性比如视觉上浪费精力，而不去好好把控业务价值

3.他们的思维模式固化，已经和互联网脱节，眼界限制了决策价值

4.他们不容易放下自己所谓的业务身段来认可科技的价值和产品平等对话

这样就给研发团队增加了很多屏障，如果不能改掉这几点，势必会导致行业产品积累进步缓慢。

那么具体怎么做呢？我觉得有以下几个建议，或者科技转型的企业一定会出现如下几个现象：

1. 产品团队对业务和研发进行定期输出，将产品通识作为大家决策的部分基础。

2. 好的产品经理从业务团队和研发团队中涌现，他们可能不是最好的业务人员、研发人员，但极有可能成为很好的产品经理。

3. 研发人员要么在技术线上深耕，要么贴近业务。只负责基础功能又不懂业务积累的研发人员将寸步难行。

而这第一件事，也是我正在做，并且视为使命的。我觉得一个好的产品经理要能够影响整个团队，为整个行业的优化、转型来做出贡献，包括产品布道、经验输出、问题分析。这也是我对诸位的建议和我个人深刻认同的看法。

如果能给努力在各个产品领域的你一些灵感，就是这篇文章最大的价值了。

希望我们都能有所坚持，光明就在不远的未来。