B端数字化产品经理生存发展指南

在职场工作中，B端产品经理难免会遇到一些难处，这个时候，该如何应对？这篇文章里，作者站在B端产品经理的视角，聊了聊自己在工作过程中所遇到的问题，并给出了一些应对之策，不妨一起来看看。

入行B端产品经理已经三年多了，在从事B端产品经理，尤其是与政府、企业相关的数字化产品经理的过程中，逐渐遇到了很多问题，想与大家分享，针对某些问题，我也思考了一些解决方案。

在描述B端产品经理的困境时，自然要与C端产品经理的工作模式相比较，曾经笔者也接触过一些C端产品的设计项目，了解过一些设计案例，也许有不太深入的地方，也欢迎读者指正。

当然，无论是面向B端还是C端的产品，都有不同的难点，笔者并不偏袒某一方。只不过本文重点在于论述B端产品的难处及应对之策，仅此而已。

一、C端产品经理画像

假如现在你是一位C端产品经理，现在让你先从零开始设计一个音乐播放APP，当你拿到这个需求时，想必已经在脑海中构建出来整体规划了。

首先实现核心功能，例如登录、音乐播放、歌词功能等，之后再为产品运营人员提供工具，可以进行歌曲资源的运营，然后再规划会员、积分等各种商业化功能，之后不断迭代，完善产品。当然，每一步的顺序视最终决策，都可以进行灵活调整。

拿到需求后，你也不必担心具体功能点的细节应该如何设计，最起码可以先做竞品分析，把目前主流的几个音乐APP拿过来用一用，功能点逐个拆解，再加上个人的思考，取长补短，做一些差异化的东西，用不了多久，原型UI以及需求设计文档就可以成型并交付开发了。

即使是比较复杂的系统，例如电商系统，你也可以找到主流的几个电商软件，分析其功能，取长补短，复制一套出来。

当然，把产品做出来并不难，C端互联网产品其实主要难在之后的阶段，如何增长、如何获客、如何变现。说简单点就是如何让一大群人知道你的产品，下载你的产品并愿意用你的产品，并且你还能赚到钱。

所以互联网公司相对于做企业服务的IT公司，一般会有更为庞大的商业化运营团队，需要在运营层面构筑壁垒。与之对应的，C端互联网产品经理的分工在越来越细的同时，也出现了很多与运营息息相关的产品经理岗位、例如增长产品经理、策略产品经理、商业化产品经理等等。

在做完用户能看得见的软件系统后，C端互联网产品经理还需要规划那些看不见的功能，例如业内人士最常见的数据埋点，之后统计用户的访问次数等一系列的数据，然后做数据分析，算转化率等等。当然，除此之外还有很多难点，此处不再一一列举。

二、B端产品经理的困境

相比于C端互联网产品经理来说，B端产业互联网产品经理的难处，主要体现在前期。拿到需求后，系统应该怎么设计，最终呈现成什么样子，是一个相当难的问题。

假如现在你是一位B端产业互联网产品经理，而且你面临的情况与前文所述一样——你们公司之前没有做过相关的产品，没有这方面的积淀，那么你的第一个难题，就来自于需求方，也就是我们常说的甲方。

首先，甲方对于系统具体要做成什么样子，是没有任何概念的。你能拿到的需求都是只言片语。比如说，“你给我做几个报表吧，我要搞搞数据分析”，你问他们需要什么样的报表，他们也不知道，最后扔下一句话“你是专业的，你看着弄吧”

然而，当你搜遍资料，搞出一些专业报表并开发出来后，甲方看到你们团队辛辛苦苦搞出来的成果，才会仿佛大神附体，让你改这改那。所有的B端产品经理，尤其是做定制化项目，一定都会有类似的吐槽，都做出来了，甲方倒来劲了，早干嘛去了。

第二个难题，我想大概率来自团队内部，比如市场、售前，或者干脆就是高层领导。他们的要求一般会高过甲方一大截。甲方如果想要一些数据可视化，他们巴不得你能现做一个工业元宇宙出来。然而当你回头看看开发团队配置和公司资金投入，不得不慨叹自己夹在中间真是难受。

其实前面所说的难题，大部分都是来自于人的问题。不过我认为，跟人打交道的问题，始终都是最大的问题。毕竟在C端，产品的很多成果是可以靠数据来量化说明的。你的产品能做到多少日活、访问量、转化率怎么样，能搞多少GMV，都可以说明你产品做得怎么样。

但是到了B端，客户的主观评价，甚至于公司内部一大堆人的主观评价，都成为决定产品好坏的关键因素。但是大家也知道众口难调。这期间要和各种不同的角色进行无数次沟通、交流甚至battle。还是强烈建议不善言辞的同学不要轻易做这一行。

说完人的问题，就是实打实的设计方法问题，B端产品经理的苦恼就在于，很难拿一些现成的产品过来做功能分析。毕竟B端的产品，商业模式是简单粗暴的，并不能玩出多少花样，基本都是一手交钱、一手交货，给钱才让用。

这也就意味着，如果你打着“学习交流”的旗号去找一些行业内比较成熟的B端产品的厂商，如果不掏钱，大概率是连人家产品的页面都看不到的。很多情况下，我们只能在人家公司的官网上，看到一些高大上但又看不太懂的专业理论，还有一些成功案例。

当然，如果遇到一些不错的商家，或许能拿到一套演示系统来看一看，学学人家的功能细节如何设计的，不过这个就很大程度上依赖运气了，而且一般能轻易展示出来的系统，要么就是人家的技术很难复制，要么就是展示出来的功能非常基础，不够深入。

另一方面，作为B端产品经理，尤其是数字化、产业互联网相关的产品经理，项目经验的重要性尤其突出。毕竟成功做过类似的项目，并在项目中深入了解对应的需求，设计每个详细的功能点，对于职业生涯的成长来说，才是最深入的学习和提升。

三、产品设计能力提升的一些方法论

针对上文所提到的B端产业互联网、或者说数字化相关的产品设计“开头难”的问题，笔者向大家分享一些切实可行的干货方法，希望对读者有所帮助，接下来按可操作性由低到高的顺序给大家介绍。

一是“骗”方案，当你的需求明确后，操作步骤大概就是找到一些行业内做的比较好的公司，找到其销售人员一顿诱惑，谎称我们公司是某某项目的总包，有充足的资金，计划采购一套数字化系统，然后从这些公司“骗”过来一些方案。

当然，这里用“骗”这个字眼也不太合适，毕竟都是读书人的事情，怎么能叫骗呢！

不过，这也是可操作性最低的方案，毕竟人家做了这么久，什么样的人都见过，如果运气好的话，或许即使看不到人家的演示系统，也能拿到一些产品手册、功能清单之类，根据这些蛛丝马迹，去构建整个产品的全貌。

二是去查阅行业研究报告，例如在某某研报、某某大厂研究院等平台查阅一些行业资料。另外，现在多家互联网大厂也在布局产业互联网，有些厂家本着学习交流的心态，开放了很多知识库给大家，各位读者可以搜罗。

三是可行性比较高的操作，深入学过Axure的同学，想必有很多听说过Axure中文网，该网站不仅提供原型学习资料，也会提供原型素材供大家下载。虽然很多需要付费，但是都可以在线预览。如果你要做一个B端的产品设计但是没有思路，想了解一下同行一般如何设计的话，在这里大部分素材都是可以找到的。

四是购买一些系统化的学习资料或课程进行学习。目前我了解到的，以“人人都是产品经理”系列的书籍和课程最成体系。当然，这些学习资料其实更建议大家在业余安排充足的时间进行基础学习，这些资料比较适合打基础。

四、需求沟通机制

首先说与甲方客户沟通的问题，笔者认为，沟通之前最应该做好的准备就是心理准备。我们经常会因为甲方提一些头疼的需求而脑袋大，也会因为等我们产品做好了以后，客户心血来潮想一通乱改而气愤不已。

其实换个角度来想，客户喜欢马后炮，乱提需求，也恰恰说明他们其实在数字化系统这方面并不专业，只要自己气场足够强，说不定能把他们忽悠住。如果对方真的专业，那其实你们一板一眼地沟通即可，并不会有太多为难。

笔者所见过真正厉害的B端数字化产品经理，一定是可以引导甲方客户的需求的。比如客户跟他简单说一句，想要建造一个智慧能源管理系统，那么这位厉害的产品经理，可以从政策到行业，从架构到功能细细地讲解整个系统的建设思路，说明投入产出比，让客户跟着自己的节奏来走。

当然，修炼到上述境界的人，一般都是宗师级别的产品专家或解决方案架构师，而对于成长路上的我们来说，笔者认为，最起码要在需求分析和管理客户预期上下功夫。

“需求分析”一般是一种比较好听的说法，比较露骨的说法是“需求反驳”，一些天马行空的构想，最起码要在产品经理这个环节挡下。之后挑出核心需求认真设计，一些能变着法实现的需求，能保留就保留。

之后就是界定责任范围。甲方的需求是什么，以及要为需求买单花多少钱，这个肯定一开始就要明确。需求列表要贯穿始终，中间即使更改，也需要与各方拉齐信息。如果要是客户需要加一堆需求，迫不得已的时候只好搬出一开始达成共识的需求列表。“想要可以，得加钱！”

当然，以上方法仅适用于你们不太弱势的时候，如果某些时候，从商务角度来说，甲方站在比较强势的位置，比如说对于你们公司来说是个大单，做不好以后在这个片区混不下去，或者说是toG的项目。只能说该操作有风险，执行还需谨慎。

之后就是管理客户预期，也就是提前给客户打好预防针，沟通的核心主题是：“虽然之前我们的销售给你画了很大的饼，但是你给的这点钱，我们只能做到这样，要想更高端一些，只能加钱。”，总之到了需求沟通阶段，肯定要实事求是，不能再画大饼了。

五、平衡预期与成本

客户的预期往往是大的，而成本的投入往往又是有限的。在B端数字化项目建设过程中，产品经理往往也需要肩负着平衡预期与成本的任务。不要说因为产品设计失误导致的返工误工费用了，几乎每一个看上去高大上的功能，都需要耗尽心血去琢磨如何用最简单的方法实现。

客户的预期讲完，就需要讲一讲组织内部的事情了。国内任何一个行业一旦发现有利可图，就会迅速由蓝海卷成红海。前期竞争没有那么激烈的时候，公司往往可以做到以产品和技术为主，以好的产品打动人心。

然而一旦竞争开始激烈起来，各大牌桌上的主要玩家，将会慢慢将战略从产品、技术转到市场上，销售也就愈发成为不同公司之间竞争的主战场，各个销售人员巧取豪夺的戏码也会轮番上映。

然而这样的场面，对于产品设计者和研发者来说是极为不利的。长期下去，我们会发现即使身处同一个公司，市场部门也会变成一个更加疯狂的甲方。客户所提的需求经过市场部门后，难度要上一个更大的台阶。

如果客户要求到十分，市场部门给你的指标很可能是二十分。同时，原本研发部门可以挣取的利润，又会被市场部门分走大半部分。接下来你会发现，研发越来越不好做，但是所得到的回报却不一定见涨。

当一个公司走向以市场为主导的困境时，真正能与研发团队穿一条裤子的市场人员已经不存在了。（当然，在职场上又有谁跟谁能好到穿一条裤子呢，准确来说，是你们之间的共同利益，交集已经很少了。）

与其说是你们公司的市场部门，不如说它变成了一个充当甲方的二道贩子，这个时候很无奈，产品经理既然作为暴露在最前面的岗位，就得承担起跟甲方斗智斗勇的、一部分市场性质的工作了。

在每次与市场部门接触前，或是开例会，或是接需求，或是出了问题讨论谁来背锅，自然都是要先做好心理建设的。笔者想了很久，其实只要从你心底认同一个真理就行。客户要求是十分，你们产品能做到七八分，剩下的两三分应该交给市场来忽悠。这才是各方应尽的责任。

要知道，只有这样，才能为整个公司或团队赚到钱，要不然市场部门总是在客户需求基础上加码，动动嘴皮子倒是很容易，超过客户预期的话，市场倒是容易向客户交差。但成本又要让研发承担，只能说这么工作的话，人人皆可取而代之。

当然，这也是基于笔者本人的所见所闻形成的一些职场认知，不同公司有不同的生态，如果今日所写恰好你能用上，那笔者要感叹一句“同是天涯沦落人”。如果感觉不受用其实更好，最起码少了一桩烦心事，恭喜您的事业又顺风顺水了一些。

如果本文章不幸被市场从业者看到，八成会非常火爆，甚至想要批驳。当然，笔者理解不同职位都有其特殊的难处，没有真正体验过，也不能妄下断言。但笔者撰写本文，本来就是基于研发和产品经理的立场，一些比较激烈的话语，权当为同行壮胆用！

六、秉承做好实事的理念

前不久看了一篇文章，某制造业企业的CIO针对数字化转型发表了一些自己的看法，有些言论振聋发聩。他们请了国内许多大厂来做数字化转型项目，结果前前后后花了几千万，似乎只收获了一堆PPT。

国内大厂况且都是这样，更何况小公司甚至是国企呢！这些年下来，数字化转型虽然没有元宇宙或AIGC的噱头大，但在互联网IT加速向产业互联网端布局和工业4.0、碳中和等政策的大背景下，数字化转型整体表现的也非常浮躁，真正做事，实现突破的人非常少。

当然，前文所述，只收获一堆PPT，确实也比较夸张，各方势力做了很多产品，不过目前所见，绝大多数的产品也只是把业务搬到了线上而已，社会各界一直炒作的“变革性”产品，不敢说没有，但的确少见。很多产品对于数据价值的利用，还仅限于PPT或架构图上。

2023年也是不平凡的一年，元宇宙的热潮褪去，AIGC元年开启，颠覆性的技术在不断涌现，不过在消费市场领域，未见其有多突出的应用。换一种说法，目前市面上的应用，不太配得上已经涌现出来的新技术，更别说炒作出来的各种概念了。

即使神如ChatGPT，在人们品尝一段智能问答的新鲜感以后，热度也在逐渐消退。于是各位行业代言人纷纷发言，认为潮流技术在产业端有更大的应用空间。随后，本就是面子工程的数据大屏引入了三维技术，领导视察时看着更好看了一点。各种垂类大模型耗费巨资在训练，之后变成了高级一些的智能客服。

尖端的技术一直被大材小用着，简单来看，是产品经理的不称职，没有做到好马配好鞍。但从另一个角度来想，这也正好是广大B端数字化产品经理的机会，架起实际应用和高新技术之间的桥梁，舍我其谁？

七、B端数字化产品经理应该走向何方

提到数字化，联想到之前看过的所有文章资讯，总感觉B端数字化产品就要走定制化的路子，“不同行业的需求是不同的，甚至同一个行业的不同企业需求也是不同的”，这句话就像是约定俗成的真理。

然而随着接触的项目越来越多，我发现往往一开始给客户介绍方案的时候，说这句话就是为了体现乙方做这个项目有多难，好多报一些钱，一但项目签约下来，乙方便会立即换一幅嘴脸：“把之前某某项目做的系统照搬过来稍微改一改，交付一下就完事了。”

所以我始终认为这句话就是来忽悠外行的，很多专家都是得了便宜又卖乖，就像很多大厂，一方面在各种峰会上阐述着数字化项目的定制属性由多强，要适配不同的客户有多不容易，另一方面又肆无忌惮地对定制化项目的部门裁员，推广自己的标准化产品。

所以很多事情，看淡就好，不得不信，也不要全信。毕竟就连指明所谓发展方向的那些专家们，很多时候也不会行为跟着观点走。

从大方向上来说，笔者认为，B端数字化产品的建设还是需要多方考虑，不能偏执一端。在建设项目的过程中，应该一直努力去寻找不同客户需求的共通点，将这些共性的需求抽离出来，封装成通用模块，避免重复建设，在越来越多的模块上实现一劳永逸。

在进行以上工作的过程中，我们也需要认识到，不同客户之间的需求差异是一定存在的，在封装共性功能模块的基础上，我们也需要思考如何提高系统的自由度和可配置化程度，来应对不同的需求。做这项工作的最终目标应该是，无需程序员进行开发，通过手动甚至自动配置的操作就可以实现，比如低代码。

以上文字总结来说，就是作为B端数字化产品经理，最重要的就是在产品设计的标准化与面对不同客户的定制化之间做平衡，当然现在也有很多解决方案，例如SaaS和低代码等等。这个度并不好把控，接下来笔者也会陆续更新文章，贯彻这一思想。

除此之外，对于现有已经成熟的产品，我们也应当深入优化其交互。B端产品的显著特点是，逻辑性强，功能多且复杂，用户使用之前也需要经过大量的培训才能上手。因此，B端数字化产品经理除了需要平衡好产品标准化与定制化之间的矛盾，还需要贯彻工具产品设计的理念，真正让所交付的产品成为客户企业里所有员工用得顺手的工具。

当然，说比做容易，要达到以上目标，恐怕对产品经理的要求已达化境。不过笔者认为，这一定是一条值得贯彻的产品设计理念。使命如此其重大，能不奋勉乎吾曹！