数字化转型咨询顾问的B端产品复盘

数字化转型咨询顾问的B端产品复盘

编辑导语：B端产品对于用户的需求比较重视，由于B端产品是为企业所提供的服务产品，所以对于服务对象的各种需求来源需要做好判断，并且在对于客户诉求方面也要重视；本文作者分享了关于数字化转型咨询顾问的B端产品复盘，我们一起来了解一下。

在做产品之前，我做过一段时间的咨询顾问，参与了一个比较典型的咨询项目，帮一家传统制造业龙头做数字化转型咨询。

整个项目是端到端的帮助客户梳理各环节流程。在帮助客户梳理好流程之后，形成产品需求书，指导客户招标发包，帮助客户筛选供应商，并且全程参与发包之后的项目实施。

对于产品经理来说，设计产品，和研发沟通，确保产品按时按需落地，这几件事情会占到产品经理日常工作的80%以上的时间。而需求在商业上的来源，可能很多小伙伴会接触的少一些。

而咨询顾问的经历，可以覆盖住产品经理工作中不涉足的部分，以一个第三方视角看待甲方客户和产品经理所在的乙方公司。

回过头复盘当时的咨询项目，对如今的产品工作也有很多启发。今天想从咨询顾问的视角复盘一下，一个产品从构思到落地，再到变现的整个过程和思考。

01 正确理解需求才是好的起跑开始

对于一个大型的企业，在C端红利逐渐吃尽的时代，在大家开始琢磨增长，开始注重留存的后互联网时期，提质增效降本减存又一次的出现在企业老板的面前。其实从早几年，我们就能感受的到，国内的一部分企业需要开始精耕细作了。

当企业决定自我革命，开始想要在内部用数字工具管理自己的数字资产的时候，B端的机会悄悄到来，而需求也在其中。

B端的需求来源会有很多，可能是老板拍脑袋，可能是产品经理从竞品中有所体悟，也可能是外在商业环境的压力。我们今天先不聊公司内部的需求，从B端客户的视角看看，需求是怎么产生的。

在B端的用户世界里，用户是知道他们想要的是什么的，但是他们知道的是最终状态，不知道的是实现方法，所以往往他们表达不好他们的需求。这种情况下，往往会涉及到无限的需求变更。产品经理需要有能力帮客户理清他们的根本诉求，设计对应的产品。

在咨询项目期间，我们帮用户梳理他们企业内部可能涉及到的数字化产品，大家可以参考下面这张图。

企业内部数字化产品示意图

可以看到在这张图里，有非常多的B端产品线。当然成熟一点的企业，在用B端产品的时候，ERP、CRM这些肯定用的比较早；这也是当下用友、金蝶，salesforce和销售易、纷享销客这类产品为什么目前占据着头部地位。

在深入企业调研的过程中，我们为客户梳理了业务流程。梳理流程在B端非常重要，正是因为不同企业流程的不同，才会导致B端产品标准化困难。

而往往用户身在其中，可能知道结果有问题，但是不能找到问题在哪里。

比如仓库里的库存周转天数高，做过WMS产品的人一定懂这个指标，库存周转天数高就说明仓库里经常积压，周转时间长，造成了大量了仓储成本。

在供应链这块，行业有几个龙头：宝洁、GE、苹果。近几年苹果在失去了设计之神乔布斯之后，却迎来了供应链之神库克。

今年5.2号巴菲特股东大会，巴菲特老爷子公开表示虽然库克创意比不上乔布斯，但却是最棒的管理人。

最近苹果发了一季报，库存周转天数指标长期在10天以内：

苹果一季报（图源：同花顺）

但是大部分厂商的周转天数高居不下，指标是直观现象的结果反馈，但是仓库管理员可能并不知道是哪个环节出了问题。当用户发现问题但是不知道如何解决的时候，他的业务改进需求书就肯定写不明白，业务改进需求书写不明白，在引入解决方案的供应商的时候就会面临很多阻碍。

我们深度参与了指导用户梳理流程，帮用户一起起草业务改进需求书，形成了后期招标书的初稿。而后期招标书，其实基本就是企业里的需求源头。

02 商业竞标就是一场产品路演

需求以招标书的形态出现了，那么自然也会有供应商打标的环节，在整个B端产品的商业生命周期中，B端的产品经理在这个阶段正式介入需求。

这个环节流程是：

1. 入选的各个供应商先研读招标书；
2. 基于自家产品输出解决方案；
3. 带着自家的方案在甲方现场首轮私下沟通需求内容；
4. 正式供应商评审会；
5. 发包会，确定供应商。

这个环节里，供应商带着方案去甲方沟通，本质就是一个路演环节，和创业者见投资人类似，只是一个拿着商业计划书（BP）去向投资人要钱，一个是带着方案，向关键客户（KA）要钱。

路演环节的关键在于，准确的理解用户的需求，并能针对性的输出产品功能cover住用户需求。这里非常考验产品经理和售前对需求的理解能力，以及产品经理将需求转换成功能的抽象能力。

当然B端发包会，水也是深似海，产品在功能上的硬实力和销售在客情关系上的软实力需要齐头并进。

销售工作没做到位，项目经理或产品经理熬夜赶出的方案真的就收效甚微了，这样也非常可惜，还有一些标的就是需要销售提前识别是否自己竞标就是陪标去的这种情况。

03 产品化是B端利器

产品开发是产品经理最熟悉的环节。这里想要说的是，项目标准化的问题；这个也取决于公司的性质，你是在一家产品型公司做产品经理，还是在一家解决方案型公司做产品经理。通常在解决方案型公司，产品经理和项目经理是一个人。

解决方案型公司输出的产品，是完全为需求定制化开发的产品，这种和用户的诉求往往能更好地匹配；但是付出大量的人天，得到的是产品的不可复用。

产品型的公司会输出一个相对标准的产品，加上少量的定制化开发，快速的迭代响应用户的需求，这种方式当然对自己公司来说最有利，但是往往和客户的需求匹配的没那么好。

两类公司对比

在企业咨询服务里，我们帮客户规划很多数字化的B端项目，参与项目实施的过程中，看了很多家中标企业的工作模式，真的感受到解决方案型公司会过的比较累。他们做过很多项目，对行业会有比较深的积累，但在没有形成产品之前，每次接标都要定制化开发，按项目人天赚钱。

而一旦完成了产品化的公司，中标之后做起来进展就非常快，但是也确实会无法满足一些客户的需求。

产品化本身确实非常困难，B端的流程复杂，行业复杂，关键角色的偏好多元等等。这些都给项目产品化带来非常大的挑战。

但是，可以看到的是，很多公司是一步一步从项目中，形成了自己的组织过程资产，并开发出了相对标准化的产品，以此去更好地应对不同的客户。

04 在验收阶段不要放弃学习的机会

通常B端产品的交付是分阶段的，比如完成了设计部分需要甲方验收一下设计风格，完成了软件产品功能部分，需要甲方验收一下产品功能；而每一阶段的验收，对应的是每一阶段的款项。毕竟一直垫钱做生意，很多公司都吃不消。

分阶段交付是保护双方的一种方式，可以有助于双方及时纠偏，对待突发的变更情况，也可以及时的响应。

然而真正到了项目结尾，B端项目的最终验收一般来说并不容易，所以会有很多回款困难的现象。

客户投入了一大笔钱，创新性地想要在数字化转型上向前迈一步，但是也很忐忑这笔钱花得有没有价值。客户的尾款付掉，如果产品使用的不好，客户企业里主导这个产品采购的负责人会有很大压力，所以验收往往并没有那么容易。

作为B端产品经理，甚至可能会在最终验收的时候，突然收到用户很多无理的需求。

面对这些需求，我的想法是：

1. 让商务团队出马，根据项目边界和客户讨论。
2. 弄清客户不满意的根本原因，安抚化解客户的焦虑。
3. 努力积极的收集用户的需求。

B端产品拿到一线用户需求的难度是远大于C端的，所以在B端企业里马太效应也是很明显。有更多的项目，就有更多的反馈，就有更多的机会去调整产品，而一直没有客户，甚至收集不到客户的真实需求，产品就一直得不到验证。

通常，到了项目最终验收的阶段，很多公司不会再投入过多人力去一个一个满足用户所有的需求了。这个阶段，商务也会介入去推动项目结束。

然而，在整个项目实施的过程中，即使到了要收尾验收交付的时候，都要一直尽力的收集客户的需求，即使并不能全部满足。我们是可以利用用户的需求，为自己内部产品的功能设计添砖加瓦的。

一线用户的需求本身是有价值的，当然也需要产品经理透过这个需求，看到需求背后本质的核心诉求，因为用户是永远没办法准确表达的。

B端产品，还是很多依赖项目存在的。有一次和某位阿里的高P交流的时候知道，即使在阿里云、腾讯云这些大厂的内部，也会面临很多项目产品化的问题。

企业数字化转型里会提到，提质、增效、降本、减存。感觉已经是口号式的目标了。然而你会发现没有一套打法是完完全全可以打穿一个行业，甚至仅打穿一个企业的。

B端的复杂在于业务复杂和流程复杂，差异化太大。一套标准的增效降本，换了个公司就不好用了，甚至同公司换个部门就不好用了。

这也是行业里说的产品化，标准化的价值。

我想，需要B端产品多思考和多复盘，从项目里吸收更多的经验，抽象出不同企业共性的部分，找到一些核心流程进行产品化，同时加以部分定制化开发工作，进而形成自己的护城河。

本文由 @格林不童话  原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议