笔者有7年的B端产品运营经验，负责过三家头部互联网教育公司的CRM以及提效工具，从0-1搭建过三套后台。
在我刚接触这个岗位的时候，它甚至还不叫产品运营，后来市面上出现了少量的讲产品运营的书和网课，但都是C端居多，B端的几乎没有。
正值我被裁员的大喜日子，有大把的时间可以复盘，于是想把这些年对于产品运营的一些工作经验复盘一下，为面试做准备，其余权当和大家讨论。
个人之言，难免有主观的成分，如有问题，也希望各位大佬评论区交流指正。
B端产品运营大致可以分成三类，SaaS方向的，双边市场的供给端方向的，还有就是内部业务系统方向的。
我们接下来的讨论都是针对内部业务系统这个方向进行的，我预计会按照产品运营的角色、产品功能规划、产品功能推进、运营体系建设四个方面和大家去交流。
今天想和大家聊的是，ToB产品运营在工作中应该扮演一个什么样的角色。
只有把自己的岗位角色定位清楚，才会知道需要掌握什么样的技能，哪些事情该做哪些不该做，以及上升的通道是什么，避免成为一个替代性很强的角色，这样才能在工作中有价值感，并能热爱这份工作，让我们开始吧。
一、B端产品运营狗的心碎日常
当年作为作为一名初出茅庐的ToB产品运营，我有过这样的难忘经历。
在周一阳光大好的下午，我和业务侧代表认认真真的开始聊本周的业务需求和问题，期间欢声笑语不断，凭着我对业务的理解，很快就get到了业务的问题。
之后在与业务的商业互吹当中，愉快的结束了本次沟通。
回到工位，我开始整理需求，想到业务殷切期待的眼神，我的手在键盘上飞舞的更快了。
又是一个阳光大好的下午，我和产品经理坐在了会议室中，在对产品经理照惯例拍了三分钟马屁之后，开始了友好的需求讨论。
经过一阵激烈的讨价还价和几声哀求，我艰难的结束了本次的需求会，望着产品经理渐行渐远的背影，我还不忘加一句，“内审结束之后，一定记得给兄弟反馈啊。”
我对本次的战果非常不满意，原本提的需求被砍了2/3，面对产品说的“不做这个是不是也不影响业务运行”“这个功能现在不是也能用吗”“研发资源没了，我也没办法”“你能让研发加班我就让他们做”毫无招架之力
弱小，虚弱，无助，都写在我的脸上。
过了一段时间，业务方嫌我推进需求慢，产品经理觉得我的需求没有整体上的优先级，两边都不愿意搭理我。
我去找领导求助，领导说：“需求要是好推进，我要你干啥呢”
是啊，要我干啥呢？我到底有啥用呢？
这是我在刚做ToB产品运营时的噩梦瞬间，入职三个月不到，我就做到了领导、业务、产品三方都不愿意搭理我的程度，那个阶段上班如上坟。
看不到自己的价值，于是我发出了灵魂叩问，ToB的产品运营到底是个啥呀。
二、To B产品运营的核心竞争力
我在一本讲B端产品经理的工具书中，找到了一个模棱两可的答案。
B端产品运营岗位的工作内容主要包括产品功能推广培训、问题解答处理、需求采集过滤、项目效果分析、业务诊断分析—《决胜B端》
这个描述和我当时做的工作几乎一致，我相信各位也做着差不多的工作，并且在功能培训、功能答疑、效果分析这类工作上，几乎都不会遇到太大的问题，而这类工作本质上也不会给我们带来太大的价值感，因为好像是个人就能做。
而且我越来越怀疑这个岗位存在的必要性。
产品需求收集，效果分析，产品经理就能做啊。
业务需求总结，功能培训，业务侧找个人兼职也可以啊。
难道这份工作就是做业务需求的传声筒，产品功能的培训师吗？
我没有感受到在部门中的归属感，也没有感受到对工作的掌控感。
没有归属感是因为，在产品眼里，我是运营，肯定不是自己人。在业务眼里，我是个半吊子产品，也不太像是自己人。
所以，我到底应该站哪边？
没有掌控感是因为，我既没有产品懂产品，也没有业务懂业务。产品总觉得我提的需求没那么准确，优先级不高。业务总觉得和我聊需求很费劲，方方面面都得解释到。
所以，我这个岗位的核心竞争力又在哪呢？
经过一段时间的思考，我发现了一部分问题的答案。
关于站队的问题，我有时候真想给自己一个嘴巴子，我的岗是挂在业务下面的，我是业务侧的产品运营，当然要无脑站业务啊。
业务的压力，有一部分会传导到产品功能上，这部分就应该传导到我的身上，帮助业务解决产品功能压力，才应该是我的职责。
产品需求只是其中一部分，完整的形态应该是对产品需求的合理的筛选和总结，以及对产品功能的进度推进，这样才能减轻业务侧的压力啊。
反观之前的我，虽然没有傻到去站产品，但是一直试图保持中立，这是个极不明智的选择。我一个小小的，挂在业务下面的岗位，怎么会想着去中立呢？
有了业务做靠山，才好推进需求啊，思路一开，我的归属感就出现了，一种替业务排忧解难的使命感也来了，岗位的价值感也油然而生。
关于核心竞争力的问题，我发现，我完全比较错了对象，我不应该和产品比产品，和业务比业务，而是做到，比产品懂业务，比业务懂产品。
这个道理很好理解，但是作为产品和业务属性都有的岗位，我该向哪个方向主要发力呢？
ToB产品的本质是解决业务的难题，那么很明显，只有先对业务了解透彻，才会上能和业务聊需求，下能和产品对进度。
于是我开始申请轮岗，老老实实的干了半个月的业务，仔细总结了业务的流程，体验了所有的产品功能，拆解了市面上能找到的第三方业务系统。
之后我发现，我提需求的精准度提升了，无论和业务还是产品沟通，都变得简单顺畅了，便秘一般的产品推进也变得有所好转了。
我对于工作的掌控感出现了，似乎一切都往好的方向发展，但是一个新的问题又出现了，产品运营，真的只是一个中间角色吗？
三、To B产品运营的角色定位
B端产品运营，听起来是要交给它一个产品，然后让它去运营，这个角色既要懂产品，又要懂运营，还得懂业务。
懂产品，是为了能把业务侧反馈的问题，提炼汇总成需求懂运营，是为了能把产品功能更好的推广给业务方去使用，以及迭代懂业务，是为了在和产品的沟通中，讲明白业务痛点的流程、场景，以及需求的重要性工作职能上，它其实充当着一个产品与业务中间人的角色。
但是我在工作当中发现，这么理解似乎不够。因为我的需求，虽然在准确性，必要性上有所提高，但是仍然有两个问题，那就是需求的延后性以及需求的细碎性。
业务在产品的使用过程中或者某个业务环节有问题来找我，我凭借还算不错的业务理解把需求提交给产品。
也就是说，问题出现了，才有我的戏份，我并不能提前预知到问题，提前为业务规避问题。
再有就是，产品每次接到的都是体验问题或者是较小的功能点，缺乏整体的规划。体验问题会造成重复开发，大量的功能点需求导致后台系统的整体比较混乱，系统本身也容易变成大杂烩，到最后无论体验还是整个后台的简易性都会遇到特别大的挑战。
这两个问题，明显是产品功能规划的有问题，一个业务的基本逻辑是确定的，后台产品的基本框架也应该是确定的。
但是目前的情况就是，没有人为整体框架负责，也没有人去划分产品在每个阶段应该实现的目标和形态，更没有人制定项目整体的目标和收益。
大家都在为业务过程中出现的问题而努力，因此头痛医头脚痛医脚，后台的补丁越来越多，越来越臃肿，越来越复杂。
遇到之前遗留下来的问题就相互踢皮球，最后由于迭代难度太大，不了了之。业务方继续硬着头皮用，产品方则继续做糊裱匠。
当然，这里面有很多现实因素，比如产品经理是有限的，但是产品需求是无限的。很多业务线并没有在一开始就配备产品经理对整体产品功能做清晰的框架，一般都是拿着比较成熟的业务线的后台系统直接用，哪里需要改哪里。
但是业务和业务之间的区别还是很大的，那么这个整体规划的工作应该谁来做呢？
我认为，有两种情况：
第一种情况，产品经理作为后台产品的负责人，在项目启动之初，就要依据业务做系统的规划，具体到后台产品的终极形态，阶段性的实现步骤，细节的产品功能。
这个情况下，产品运营也需要把产品经理的规划工作原封不动的再做一遍，因为我们默认，产品运营更懂业务。
两个规划最后相融合，得到业务和产品都满意的结果，之后按部就班的开动。
第二种情况，产品运营作为后台产品的负责人，做一遍上述的详细规划，并且和产品方、业务方做深入沟通，得到一个三方满意的结果，然后开动。
所以无论哪种情况，产品运营都要为全盘的、阶段的、细节的规划负责。
这取决于我们的核心竞争力，我们比产品更懂业务，我们可以看到产品经理看不到的盲点。相比于业务，我们更懂产品，很多复杂的流程仅凭业务侧是无法抽象成产品功能的，由于工作重心不同，他们往往缺乏产品化的思考，但是我们可以。
我们不应该是产品经理和业务之间的传声筒，也不是产品功能的培训师，更不是专职数据反馈的ppt制造机，而是基于业务流程与发展，规划产品框架、确定产品阶段、填补功能细节、引领产品功能落地实现的总设计师。
我认为，这才是ToB的产品运营岗真正无可替代的原因，也是它最具价值的点。
也就是说，我们要成为产品经理的上游，把他们从繁杂的业务中解放出来，因为他们很可能身兼多个业务线，但是我们只要专精一个就可以。
我们要成为整体业务的下游，将业务的发展和流程都作为后台产品框架的参考，而不是只做某个群体（比如销售群体）的下游，只做体验和迭代的部分。
这样就可以把业务从产品功能的限制中解放出来，我们要想业务侧不敢想，把他们业务流程中的，却又从来没有想到过能产品化解决的顽疾抽象出来，并落地，从而在产品层面引领业务更好的前进。
这样我们就从产品与业务中间人的角色，发生了很大的改变。
在产品层面，我们从传递者变成了规划者在业务层面，我们从倾听者变成了引领者如果你接手的某个后台系统已经有了完整的规划，甚至是产品经理做主导，你也要把认真拆解和理解产品规划，在此基础上，提出自己的规划和意见。
一旦你这样做了，就会出现以下几个好处：
你对后台系统有了全盘的认识，基于对业务的深度理解，你可以和产品经理做更有深度的交流，可以为整个系统后台提出真正具有方向性以及建设性的意见你会对后台产品的各个模块有更为清晰的认识，对每个模块对应的业务场景有更深的理解，对于之后需求的优先级、必要性，会做出更为合理的判断基于对业务的理解，你可以提前预知业务的痛点和流程的难点，并对这部分产品化做出更具前瞻性的规划，真正做到为业务排忧解难，雪中送炭依托清晰的产品框架和业务流程，我们的需求将变得模块化，虽然同样是一个小的细节性的需求，但是你和产品经理都知道，这个细节是为了建设哪个模块，这个模块成型后又会带来何种质变。这对产品经理是一个很大的动力，毕竟谁都想做出一个完整的作品。你将在产品经理和业务之间赢得巨大的话语权，成为一个真正引领者的角色，并且很难被替代。有些朋友可能会觉得，听起来很美好，但是这样下来，你和产品经理的界限在哪里呢？这不是抢产品经理的活吗？
我认为这恰好是互补的，行业里面一直流传着一句话，一个好的运营，一定要懂产品，一个好的产品，一定要懂运营。
产品运营和产品经理从职能上看虽然不同，但是他们背的指标是相似的，比如功能的上线情况、对业务的提升情况、功能的使用率、B端用户的满意度等等。
换句话说，这两个职位对于同一个后台系统来说，是绑在一条船上的，只要出发点是为了产品做的更好，业务做的更顺畅，不会有什么功能的重叠，相反，我们专业的业务视角，放眼全局的规划、对业务场景的深刻理解，是可以很大程度上反哺产品经理的。
从我自身的工作经历来看，我以这样的角色既主导过后台系统，也辅助过产品经理。我们配合的非常融洽，产品经理也会非常尊重一个专业的产品运营。有了信任和尊重做基础，产品功能的推进、反馈、迭代都是十分顺利的。
只要你不上赶着画产品原型，产品经理都是十分乐意接受你的建议的。但是前提是，你真的真的非常懂业务。
从另一个角度说，你还要做培训、安排灰度、提升使用率等等诸多的运营工作，产品工作上有交叉只能是我们的加分项。
由此，我们可以得到ToB产品运营的全貌。
角色定位：
业务部门的下游，通过对全盘业务的梳理及理解，对支撑业务运作的业务系统进行整体、阶段、细节的规划，取得与业务方的一致
产品经理的上游，根据整体规划，与产品部门取得一致，并与产品经理一道进行产品功能的确定、推进、上线等等
综合来说，产品运营需要对整个业务系统的功能上线与迭代、功能培训与反馈、数据收集与分析、使用率提升及用户满意度负责，在我看来，B端的产品运营相比C端，更注重产品方向的能力。
四、一个真实经历
2020年末，我在一家头部公司从0到1搭建了一套针对于销售的效率工具，工具的效果非常好。
于是其他新兴业务线也来用我们的这套工具，为了更好的使用，他们派出两个产品运营来学习。
我开始从业务模式到使用场景，再到细节功能逐个给他们讲解大大小小的40多个功能，他们很惊讶，为啥我啥都知道，并且能细节到使用场景。在他们的印象里，只有产品经理才会考虑这些问题。
于是我们聊起了对产品运营的理解，不出所料，他们认为产品运营就是做培训和反馈的。正是这样的认知差异，造成了我们的能力画像的不同。
进一步也会影响我们未来不同的发展路径和薪资待遇，以及可替代性的大小。
我建议初入B端产品运营的新人，即使目前做着比较基础的工作，也要往全盘的方向去思考和发展，不为别的，就为饭碗更稳定，工资更高一点。
下一篇文章，我们详细讨论下ToB产品运营的能力画像，有任何建议，欢迎各位在评论区讨论指正。