2023年ToB产品运营的角色定位-新的引领者

ToB产品运营的角色定位——新的引领者笔者有7年的B端产品运营阅历，负责过三家头部互联网教育公司的CRM以及提效工具，从0-1搭建过三套后台。

在我刚接触这个岗位的时候，它甚至还不叫产品运营，后来市面上消失了少量的讲产品运营的书和网课，但都是C端居多，B端的几乎没有。

正值我被裁员的大喜日子，有大把的时间可以复盘，于是想把这些年对于产品运营的一些工作阅历复盘一下，为面试做预备，其余权当和大家争论。

个人之言，难免有主观的成分，如有问题，也盼望各位大佬评论区沟通指正。

B端产品运营大致可以分成三类，SaaS方向的，双边市场的供应端方向的，还有就是内部业务系统方向的。

我们接下来的争论都是针对内部业务系统这个方向进行的，我估计会根据产品运营的角色、产品功能规划、产品功能推动、运营体系建设四个方面和大家去沟通。

今日想和大家聊的是，ToB产品运营在工作中应当扮演一个什么样的角色。

只有把自己的岗位角色定位清晰，才会知道需要把握什么样的技能，哪些事情该做哪些不该做，以及上升的通道是什么，避开成为一个替代性很强的角色，这样才能在工作中有价值感，并能喜爱这份工作，让我们开头吧。

一、B端产品运营狗的心碎日常

当年作为作为一名初出茅庐的ToB产品运营，我有过这样的难忘经受。

在周一阳光大好的下午，我和业务侧代表认仔细真的开头聊本周的业务需求和问题，期间欢声笑语不断，靠着我对业务的理解，很快就get到了业务的问题。

之后在与业务的商业互吹当中，开心的结束了本次沟通。

回到工位，我开头整理需求，想到业务殷切期盼的眼神，我的手在键盘上飘舞的更快了。

又是一个阳光大好的下午，我和产品经理坐在了会议室中，在对产品经理照惯例拍了三分钟马屁之后，开头了友好的需求争论。

经过一阵激烈的讨价还价和几声请求，我困难的结束了本次的需求会，望着产品经理渐行渐远的背影，我还不忘加一句，“内审结束之后，肯定记得给兄弟反馈啊。”

我对本次的战果特别不满足，原本提的需求被砍了2/3，面对产品说的“不做这个是不是也不影响业务运行”“这个功能现在不是也能用吗”“研发资源没了，我也没方法”“你能让研发加班我就让他们做”毫无招架之力

弱小，虚弱，无助，都写在我的脸上。

过了一段时间，业务方嫌我推动需求慢，产品经理觉得我的需求没有整体上的优先级，两边都不情愿搭理我。

我去找领导求助，领导说：“需求要是好推动，我要你干啥呢”

是啊，要我干啥呢？我究竟有啥用呢？

这是我在刚做ToB产品运营时的噩梦瞬间，入职三个月不到，我就做到了领导、业务、产品三方都不情愿搭理我的程度，那个阶段上班如上坟。

看不到自己的价值，于是我发出了灵魂叩问，ToB的产品运营究竟是个啥呀。

二、ToB产品运营的核心竞争力

我在一本讲B端产品经理的工具书中，找到了一个模棱两可的答案。

B端产品运营岗位的工作内容主要包括产品功能推广培训、问题解答处理、需求采集过滤、项目效果分析、业务诊断分析《决胜B端》

这个描述和我当时做的工作几乎全都，我信任各位也做着差不多的工作，并且在功能培训、功能答疑、效果分析这类工作上，几乎都不会遇到太大的问题，而这类工作本质上也不会给我们带来太大的价值感，由于似乎是个人就能做。

而且我越来越怀疑这个岗位存在的必要性。

产品需求收集，效果分析，产品经理就能做啊。

业务需求总结，功能培训，业务侧找个人兼职也可以啊。

莫非这份工作就是做业务需求的传声筒，产品功能的培训师吗？

我没有感受到在部门中的归属感，也没有感受到对工作的掌控感。

没有归属感是由于，在产品眼里，我是运营，确定不是自己人。在业务眼里，我是个半吊子产品，也不太像是自己人。

所以，我究竟应当站哪边？

没有掌控感是由于，我既没有产品懂产品，也没有业务懂业务。产品总觉得我提的需求没那么精确     ，优先级不高。业务总觉得和我聊需求很费劲，方方面面都得解释到。

所以，我这个岗位的核心竞争力又在哪呢？

经过一段时间的思索，我发觉了一部分问题的答案。

关于站队的问题，我有时候真想给自己一个嘴巴子，我的岗是挂在业务下面的，我是业务侧的产品运营，当然要无脑站业务啊。

业务的压力，有一部分会传导到产品功能上，这部分就应当传导到我的身上，关心业务解决产品功能压力，才应当是我的职责。

产品需求只是其中一部分，完整的形态应当是对产品需求的合理的筛选和总结，以及对产品功能的进度推动，这样才能减轻业务侧的压力啊。

反观之前的我，虽然没有傻到去站产品，但是始终试图保持中立，这是个极不明智的选择。我一个小小的，挂在业务下面的岗位，怎么会想着去中立呢？

有了业务做靠山，才好推动需求啊，思路一开，我的归属感就消失了，一种替业务排忧解难的使命感也来了，岗位的价值感也油然而生。

关于核心竞争力的问题，我发觉，我完全比较错了对象，我不应当和产品比产品，和业务比业务，而是做到，比产品懂业务，比业务懂产品。

这个道理很好理解，但是作为产品和业务属性都有的岗位，我该向哪个方向主要发力呢？

ToB产品的本质是解决业务的难题，那么很明显，只有先对业务了解透彻，才会上能和业务聊需求，下能和产品对进度。

于是我开头申请轮岗，老狡猾实的干了半个月的业务，认真总结了业务的流程，体验了全部的产品功能，拆解了市面上能找到的第三方业务系统。

之后我发觉，我提需求的精准度提升了，无论和业务还是产品沟通，都变得简洁顺畅了，便秘一般的产品推动也变得有所好转了。

我对于工作的掌控感消失了，好像一切都往好的方向进展，但是一个新的问题又消失了，产品运营，真的只是一个中间角色吗？

三、ToB产品运营的角色定位

B端产品运营，听起来是要交给它一个产品，然后让它去运营，这个角色既要懂产品，又要懂运营，还得懂业务。

懂产品，是为了能把业务侧反馈的问题，提炼汇总成需求懂运营，是为了能把产品功能更好的推广给业务方去使用，以及迭代懂业务，是为了在和产品的沟通中，讲明白业务痛点的流程、场景，以及需求的重要性工作职能上，它其实充当着一个产品与业务中间人的角色。

但是我在工作当中发觉，这么理解好像不够。由于我的需求，虽然在精确     性，必要性上有所提高，但是仍旧有两个问题，那就是需求的延后性以及需求的细碎性。

业务在产品的使用过程中或者某个业务环节有问题来找我，我凭借还算不错的业务理解把需求提交给产品。

也就是说，问题消失了，才有我的戏份，我并不能提前预知到问题，提前为业务规避问题。

再有就是，产品每次接到的都是体验问题或者是较小的功能点，缺乏整体的规划。体验问题会造成重复开发，大量的功能点需求导致后台系统的整体比较混乱，系统本身也简单变成大杂烩，到最终无论体验还是整个后台的简易性都会遇到特殊大的挑战。

这两个问题，明显是产品功能规划的有问题，一个业务的基本规律是确定的，后台产品的基本框架也应当是确定的。

但是目前的状况就是，没有人为整体框架负责，也没有人去划分产品在每个阶段应当实现的目标和形态，更没有人制定项目整体的目标和收益。

大家都在为业务过程中消失的问题而努力，因此头痛医头脚痛医脚，后台的补丁越来越多，越来越臃肿，越来越简单。

遇到之前遗留下来的问题就相互踢皮球，最终由于迭代难度太大，不了了之。业务方连续硬着头皮用，产品方则连续做糊裱匠。

当然，这里面有许多现实因素，比如产品经理是有限的，但是产品需求是无限的。许多业务线并没有在一开头就配备产品经理对整体产品功能做清楚的框架，一般都是拿着比较成熟的业务线的后台系统直接用，哪里需要改哪里。

但是业务和业务之间的区分还是很大的，那么这个整体规划的工作应当谁来做呢？

我认为，有两种状况：

第一种状况，产品经理作为后台产品的负责人，在项目启动之初，就要依据业务做系统的规划，详细到后台产品的终极形态，阶段性的实现步骤，细节的产品功能。

这个状况下，产品运营也需要把产品经理的规划工作原封不动的再做一遍，由于我们默认，产品运营更懂业务。

两个规划最终相融合，得到业务和产品都满足的结果，之后按部就班的开动。

其次种状况，产品运营作为后台产品的负责人，做一遍上述的具体规划，并且和产品方、业务方做深化沟通，得到一个三方满足的结果，然后开动。

所以无论哪种状况，产品运营都要为全盘的、阶段的、细节的规划负责。

这取决于我们的核心竞争力，我们比产品更懂业务，我们可以看到产品经理看不到的盲点。相比于业务，我们更懂产品，许多简单的流程仅凭业务侧是无法抽象成产品功能的，由于工作重心不同，他们往往缺乏产品化的思索，但是我们可以。

我们不应当是产品经理和业务之间的传声筒，也不是产品功能的培训师，更不是专职数据反馈的ppt制造机，而是基于业务流程与进展，规划产品框架、确定产品阶段、填补功能细节、引领产品功能落地实现的总设计师。

我认为，这才是ToB的产品运营岗真正无可替代的缘由，也是它最具价值的点。

也就是说，我们要成为产品经理的上游，把他们从繁杂的业务中解放出来，由于他们很可能身兼多个业务线，但是我们只要专精一个就可以。

我们要成为整体业务的下游，将业务的进展和流程都作为后台产品框架的参考，而不是只做某个群体（比如销售群体）的下游，只做体验和迭代的部分。

这样就可以把业务从产品功能的限制中解放出来，我们要想业务侧不敢想，把他们业务流程中的，却又从来没有想到过能产品化解决的顽疾抽象出来，并落地，从而在产品层面引领业务更好的前进。

这样我们就从产品与业务中间人的角色，发生了很大的转变。

在产品层面，我们从传递者变成了规划者在业务层面，我们从倾听者变成了引领者假如你接手的某个后台系统已经有了完整的规划，甚至是产品经理做主导，你也要把仔细拆解和理解产品规划，在此基础上，提出自己的规划和看法。

一旦你这样做了，就会消失以下几个好处：

你对后台系统有了全盘的熟悉，基于对业务的深度理解，你可以和产品经理做更有深度的沟通，可以为整个系统后台提出真正具有方向性以及建设性的看法你会对后台产品的各个模块有更为清楚的熟悉，对每个模块对应的业务场景有更深的理解，对于之后需求的优先级、必要性，会做出更为合理的推断基于对业务的理解，你可以提前预知业务的痛点和流程的难点，并对这部分产品化做出更具前瞻性的规划，真正做到为业务排忧解难，雪中送炭依托清楚的产品框架和业务流程，我们的需求将变得模块化，虽然同样是一个小的细节性的需求，但是你和产品经理都知道，这个细节是为了建设哪个模块，这个模块成型后又会带来何种质变。这对产品经理是一个很大的动力，究竟谁都想做出一个完整的作品。你将在产品经理和业务之间赢得巨大的话语权，成为一个真正引领者的角色，并且很难被替代。有些伴侣可能会觉得，听起来很美妙，但是这样下来，你和产品经理的界限在哪里呢？这不是抢产品经理的活吗？

我认为这恰好是互补的，行业里面始终流传着一句话，一个好的运营，肯定要懂产品，一个好的产品，肯定要懂运营。

产品运营和产品经理从职能上看虽然不同，但是他们背的指标是相像的，比如功能的上线状况、对业务的提升状况、功能的使用率、B端用户的满足度等等。

换句话说，这两个职位对于同一个后台系统来说，是绑在一条船上的，只要动身点是为了产品做的更好，业务做的更顺畅，不会有什么功能的重叠，相反，我们专业的业务视角，放眼全局的规划、对业务场景的深刻理解，是可以很大程度上反哺产品经理的。

从我自身的工作经受来看，我以这样的角色既主导过后台系统，也帮助过产品经理。我们协作的特别融洽，产品经理也会特别敬重一个专业的产品运营。有了信任和敬重做基础，产品功能的推动、反馈、迭代都是非常顺当的。

只要你不上赶着画产品原型，产品经理都是非常愿意接受你的建议的。但是前提是，你真的真的特别懂业务。

从另一个角度说，你还要做培训、支配灰度、提升使用率等等诸多的运营工作，产品工作上有交叉只能是我们的加分项。

由此，我们可以得到ToB产品运营的全貌。

角色定位：

业务部门的下游，通过对全盘业务的梳理及理解，对支撑业务运作的业务系统进行整体、阶段、细节的规划，取得与业务方的全都

产品经理的上游，依据整体规划，与产品部门取得全都，并与产品经理一道进行产品功能的确定、推动、上线等等

综合来说，产品运营需要对整个业务系统的功能上线与迭代、功能培训与反馈、数据收集与分析、使用率提升及用户满足度负责，在我看来，B端的产品运营相比C端，更注意产品方向的力量。

四、一个真实经受

2022年末，我在一家头部公司从0到1搭建了一套针对于销售的效率工具，工具的效果特别好。

于是其他新兴业务线也来用我们的这套工具，为了更好的使用，他们派出两个产品运营来学习。

我开头从业务模式到使用场景，再到细节功能逐个给他们