运营跟产品的关系—-亦敌亦友,目标相同

早晨有朋友在群里说,公司的产品太强势,感觉运营就是打杂的,一句话道出了很多运营人的心声,但是运营和产品的关系原本并不是这样,影响运营和产品的关系的除了两个人本身之外,公司性质/团队/等等都能影响到两者的关系。

一个互联网产品团队,核心角色是产品、运营、研发、UI/交互。这四者之间的关系分两种:

  • 需求提出方和满足方的关系,比如产品向研发和设计师提需求,运营向产品提需求。产品和运营就是需求提出方,研发和设计师就是满足方。
  • 相互依赖和配合的关系,比如产品和运营。这两个角色想要做好自己的工作,就必须与对方持续、紧密的配合,缺了谁也不行。

但是在产品和运营协同工作的过程中,会出现很多复杂又难以解决的问题,分别举例如下:
运营认为,产品不重视运营,但运营却要为产品背负责任:

  • 为什么PM做功能从来不和我们讨论,他们懂用户需求吗,懂行业吗?功能上线后用户骂声一片,就让运营出来安抚一下、解释一下,其实就是擦屁股。
  • 好容易有几个版本的效果好,PM就在群里邮件里开心的写着效果评估。其实那是因为运营的核心用户在挺我们啊,是我们为新版策划了活动啊,功劳都是PM的了?

为什么运营提的需求总是优先级最低的?提一个需求还按必须给什么效果预估,没上线怎么预估,这不是形式主义忽悠人吗?
产品认为,运营总是没起到应有的作用:

  • 运营什么时候才能不盯着KPI做活动,数据倒是上去了,怎么不看看留存呢?就知道有奖送礼什么的,把产品搞的乌烟瘴气,一点氛围都没有。
  • 为什么运营就不能具备一些基本的产品思维,别再提那些不着边际的需求了,这和用户直接反馈有什么区别,害得我们还要花时间去解释为什么不做。
  • 我们需要的是爆点,不是小打小闹。运营你说你懂行业朋友多,那就多请一些大腕来活跃啊,帮着传播推广啊。

以上描述虽极端,但很有代表性,相信很多公司的产品和运营同学都有过类似感受。因此,让这两个角色配合默契、有序运转、形成合力,并不容易。下面就聊聊产品和运营这亦敌亦友的关系。

1.产品和运营为什么会是亦敌亦友的关系

产品和运营配合出现问题的根本原因是:两者目标不一致,导致从出发点到具体执行都是两条平行线,不能拧成一股绳,就无法形成合力。由此可见,将产品和运营的目标统一,是解决这个问题的核心点。
为什么会存在目标不一致的现象呢,因为屁股决定脑袋。从组织架构的角度说,很多公司的产品和运营分属两个团队,由两位不同的老大负责。
既然团队和老大都是两个,那么目标肯定也是两个,否则就无法衡量这两个老大和两个团队的价值。比如,两个人炒一盘菜,一人负责切,一人负责炒,那色香味俱全是谁的功劳,味如嚼蜡谁又是幕后黑手,就很难分辨了。如果两个人互相推脱责任,就进入到扯皮阶段了,很难根治。
一般在团队分工时,都会避免工作内容和目标有重合,保证团队或个人的独立性。这样做的目的是保证员工的个人发展空间,也便于清晰的衡量工作产出,暴露所存在的问题。
综上可知,因为团队分工的问题,导致了产品和运营的目标不统一。除此之外,两个团队的架构,还会带来其他负面效应。比如两个老大为了争夺话语权,出现对峙的情况。这种状态的起因是私利,而非工作,势必会影响到决策的合理性,最终影响产品的进展。

2.产品和运营常见的几种关系

关系一:运营跟产品各自为政

人力紧缺,需要团结协助的创业公司基本不会有这种各自为政的运营与产品关系,它比较容易出现在产品用户规模大的成熟产品,类似豆瓣、知乎、QQ、贴吧、YY语言这种千亿级别的产品。这样的大产品通常会设立运营部门,做已有功能的运营或者商业化运营,设置产品部门专门负责功能创新与用户拉新。它们之间,除非是核心资源上的合作才会有交集,一些专业的问题处理上基本就是各自学习或者部门各自招人来处理。
这种关系下的运营与产品,容易出现相互抢活,工作重叠。要想让产品支持你的运营工作,有三种方法你可以尝试下。第一种,做项目立项让公司高层来安排;第二种,利用产品的KPI来做运营;第三种,私底下处理好跟产品的童鞋关系,也就是人缘好。

关系二:产品生孩子,运营养孩子

产品把东西做出来了,运营帮忙推广,非常纯粹的先后关系,运营在产品设计阶段参与的非常少。这种关系,容易出现在公司的快速发展期,产品忙于新功能的设计,运营疲于用户的拉新,虽然是缺乏沟通,但是每个人都能够得到快速的成长,各取所需。
这种关系下的运营与产品,基本没啥矛盾,就是对运营而言推广需求会偶尔来的突然,运营积极性容易被消磨,推广做到出色比较难。如果你刚好是这样的运营处境,我的建议是提前周知产品规划,这样可提前做好相应的推广准备。或者是设置一套运营需求流程,让产品提前来排推广需求。

关系三:有共同KPI目标

当运营跟产品明确的被指明为同一KPI负责时,他们的关系会更加的紧密,产品在设计阶段也会提前告知运营,并且会适当的按照运营的建议调整产品,但整体来说是一个产品主导的关系。比如一款产品的会员商业化工作,产品需要设计会员特权,运营可以根据自己对用户的理解,提出会员特权的具体功能,并推广这款特权。
这种关系下的运营与产品,容易会出现抢功局面,毕竟没有明确的被规定哪些是运营工作哪些属于产品范畴。但总的来说是荣辱与共,完成KPI才是关键,老板只关心这个。

关系四:深入合作

深入合作一般意味着成立由运营跟产品组成的项目组,并选定项目负责人。他们明确彼此分工,在产品写需求文档阶段,运营就拥有足够的话语权,童鞋产品也会安排人力专门收集运营需求。他们不仅有共同的KPI,也更经常的开会,汇报彼此的工作进度,了解对方能否满足自己在某个节点的关键需求。
以贴吧看贴为例,在产品层面,在灰度期是运营主导着编辑器设计,产品童鞋负责前端用户功能设计,当然运营也可以为前端的设计提出优化方案;在运营层面,产品会提出自己的内容更新要求,运营也会告知产品需要那些入口支持
这种关系下的运营与产品,倒有点像一个创业团队,把一款功能一个项目当作自己的事儿。如果再配合到大公司的资源,应该是最容易出运营成绩的。既然是跟产品深入合作了,作为运营可以多学习一些类似用户调研、原型设计的产品技能,需要在推理演绎能力上有所积累,因为你还需要面对优先级排期的立项会议。
最后聊一个不管你跟产品是处在什么“暧昧”关系下,都会比较关心的一个问题:在产品开发时,自己运营思路何时介入比较好?
我的建设是越早越好,早到产品还只是立项阶段。因为能够在产品层面植入运营的需求,会大幅度减少你的运营压力,当然你也可以理解成运营与产品的第五种关系——运营主导产品。
举一个时效性运营的正面的例子。作为运营如何能够比较早的介入产品,在产品设计阶段就让技术给留下类似发贴框、回复框、特效关键词、红包分享等彩蛋接口,在做时效性就可以直接通过这些接口做出很多好玩的活动,例如双十一的天猫关键词特效。
举一个数据运营的反面例子。产品需要的数据跟运营真正想要的数据是有出入的,产品的数据,它可能只关心整个功能的日活,次日留存,停留时长。而运营除了这些数据,还需要单篇图文的阅读点击数据,用户停留时长阅读的条数,用户的步长。如果不提前做产品的介入,埋好相关路径的统计点,在做后续数据分析时,会出现数据缺失问题。
产品跟运营的关系从深到浅“暧昧”,彼此的思维方式跟工作方向不一样,相互吐槽也属正常。在我们吐槽产品生的孩子不好时,估摸着产品也指点运营的不是。不过话说回来,同为搬砖打工,撕逼完后大家还是一起唠嗑下公司老板就好。

3.产品和运营不协调的关系该怎么解决

说说自己的亲生经验,公司上线一个小项目,组建了一个团队,产品、运营、研发、UI等八九个人,我们每天都有晨会,每周都有例会,目的是打通产品和运营障碍。
在团队里,虽然每位成员分工不同,但关注的目标是一样的,只是大家通过完成自己的任务去达成这个目标。比如,

  • 运营在运营种子用户、建立对外合作、准备预热活动等
  • PM在优化操作流程、提升流量转化率
  • 研发保证按照需求和时间点完成开发任务,并且尽量少出BUG
  • UI设计师力求页面效果不仅满足PM的功能需求,也符合运营的预期调性

不仅如此,在每天的晨会(站会,10分钟)和每周的例会(1个小时)里,大家会抛开自己的分工,一起加入产品的讨论。虽然经常会有不靠谱的建议,但这才像一个团队。
但这个模式也有缺点,就是只适合5-20人的小团队。如果人数增加到30人,就肯定行不通了。原因是:

  • 首先,一个老大直线管理这么多人的成本和难度很高,沟通和信息互通也不会那么通畅。如果老大和员工之间再增设一个层级,变成金字塔式架构,就更复杂了。
  • 其次,如果是30人的团队,那么产品和运营的人数也会增多,比如各5个,这就意味着产品和运营分别成立了二级团队。独立的小团队变成大团队,又会出现上文中所说的目标不统一,各自为战的情况。

所以,如果可以拆分成小团队,或者本是小团队的公司,可以尝试上述的方案。一旦团队规模变大,就不再适用了,这也是业内都很羡慕团队「小而美」的原因吧。
当然,大团队也不是无解,可以通过扁平化的团队架构,来缓解产品和运营配合不好的问题。比如一个总监同时管理产品和运营团队,这两个团队分别有1个经理级中层,再各带一个小团队。这样的三层团队设置,从层级上来讲是可以接受的,承担30人的团队也是没问题的。
相信大家还有别的方式,请在留言区域留言讨论。

4.谁更有话语权

说起产品和运营的关系,就不得不说话语权的问题。这两者一定会存在强势和弱势的关系,不可能有一碗水端平的状态,只是强弱差或大或小而已。当然,谁都希望能主导项目,但是有时候并非是自己能左右的。
决定一个团队是产品驱动还是运营驱动,有两个因素:
团队基因。团队基因主要是创始人团队带来的,所以基本等同于创始人基因。从一个公司,到一个小团队,这个规律都适用。
所以,要看一个团队是什么角色来驱动,主要看老大。如果老大是PM出身,公司很有可能是产品驱动;如果是技术出身,那么运营的角色一定是很弱势,不被重视。因为技术人员一般不重视也不懂运营,两个角色实在是离得太远。
产品属性。通俗的说,就是看是什么产品了,不同类型的产品就是适合不同的团队架构,也决定了角色之间的话语权。
一个工具型产品,肯定是产品驱动的,比如天气、笔记、拍照类app,即使渠道的作用很大,但也不会成为驱动方;一个O2O产品,肯定是运营驱动,比如团购、到家类app。
所以,如果要看一个团队里哪个角色更有话语权,哪个角色是主导地位,就从上面两个因素中就可以看出。

5.该怎么配合

团队架构就说到这,那么产品和运营应该怎么配合,才是合理的,是可以发挥双方合力的。我认为,分为产品上线前和上线后两个阶段。当然,可能没有这样纯粹的阶段,但有这样的状态。

上线前

  • 第一步:产品的功能规划以及发展方向,都是老板的决策。在决策完成之后,应该告知团队全员,项目的背景、方向和规划,让大家充分了解信息,对于后续执行的过程是有帮助的。
  • 第二步:之后执行环节的规划,就是产品和运营协同工作的开始。比如,受众人群、功能特点、版本节奏、运营规划等,应该双方一起参与讨论,得出一个大概的框架和计划。
  • 第三步:按照框架计划,大家开始分头行动。产品去画原型,定功能细节;运营做准备内容、流量渠道和核心用户,以及策划上线后的爆点。在这个阶段,产品和运营可以暂时分离开,不必有频繁的协作。但由于有了前两步的铺垫,在分头行动的过程中,双方也了解对方的计划和进展,所以信息是互通的。
  • 第四步:上线前的准备阶段,之前分头行动的产品和运营的双方,就要再次回到一起,交出之前的作业。也就是大家为产品上线所做的准备,进展、遇到问题和后续计划是什么,拿出来互通和讨论。问题都解决后,就可以上线了。

上线后

进入到产品正式运转阶段,产品和运营再次结合在一起协同工作。在这个阶段需要高频次的沟通,以及互相推动彼此的工作。
运营,主要关注用户反馈。
在做好内容、用户、活动、渠道等运营工作的同时,向产品及时和详尽的通报用户反馈,让团队了解用户对产品的反应。
关注用户需求,转化为产品需求,推进PM上线。
提出可以大幅提升运营效率的工具需求,推进PM用产品的方式解决。
产品,协助运营的规划和执行工作
除了修复BUG和完成产品需求之外,要关注运营的反馈,因为这是产品投入到用户群体之后的反应,是印证之前决策的过程。
要关注运营遇到的问题,是否可以通过产品的方式解决。主动与运营同学沟通,给出解决方案并推动研发完成。
还需要关注运营措施是否合理,是否对产品的目标有推进作用。如果发现偏离目标,或者唯KPI的行为,要及时沟通并推动改进。
当然,在产品上线前后可不只是做这些事,上面只是提到需要产品和运营配合的节点。由于每个项目的情况都很复杂,所以上述事项肯定也不全,只能是作为一个思路,举例说明而已。

6.网友口中产品和运营关系

张大成:
产品和运营,就是 亲爹和后娘的关系,为了家庭和睦,工作顺心,亲爹和后娘共同努力、、、

亲爹偶尔不喜欢后娘对孩子指手画脚 亲爹更担心后娘照顾不好自己的原产儿子,有能生儿子,担心养不好儿子的亲爹后娘又要有娘的觉悟,孩子出来事情要给别人(用户之流)做解释,做保护神马的 后娘又有时候觉得亲爹生的孩子不咋地 纠结的后娘。
知乎用户:

最近在捣鼓着自己的一个社区产品,一直在产品的功能设计上给力,让它使用起来变得更加简单,让用户更容易接受。但转过来一想,把产品功能搞好了,用户就会来用你的东西了吗?他们就会接受你的产品了吗?他们就会喜欢你的产品了吗?
答案是NO!
对于一个产品,尤其是社区产品,运营上更应该给力,更多时候,产品不是败在功能上,而是败在运营上,因为用户关注的不是功能本身,而是功能上所承载的信息、服务,比方来说,一家咖啡店除了要让它的杯看起来更别致,更应让杯里装的咖啡喝起来更享受,因为顾客是冲着咖啡而来你的店的。
我们可以看下,同样是使用 wordpress 这个博客程序,但有些人的博客质量甚高,内容丰富,读者甚众,而有些人的博客内容低劣,零星几个字,他们对待博客不同的态度、不同的维护方式,决定着一个博客的是优还是劣。
类似的,同样是使用 discuz 论坛,同样是使用 uchome 这些程序,让你同样是搞个地方的论坛社区,不同的人搞起来,会有截然不同的效果;国内提供微博服务的何止新浪,大家功能上大同小异,但独新浪搞好最好,强大的内容运营能力,名人微博的思路,让它一路高歌猛进;同样是团购网站,功能简单去了,但是网站本身之外的线下运营,占去了一个团购服务公司的大部分人力物力。
所以,千万别以为产品把功能搞好,就会有多多的用户了。你要记得你提供给用户的不是产品功能本身,而是产品功能里所承载的信息、服务,而要让用户从你的产品里获得想要信息、服务,你还需要用尽各种手段,把影响产品信息服务一切非功能因素都搞好,像团购网站去拉商家,新浪微博去拉名人。这就是所谓的运营。
所以,如果你是一个程序员,就更应该注意了,程序员往往更关注功能的实现,把功能搞好,而把运营这事给忘了,最后看着自己的东西纳闷:明明我的产品功能搞好很好了,为什么就是没人用呢?如果你确实不知运营的事怎么张罗,就找一个能张罗的伙伴吧。
乔老大:

比较流行的一种说法是:产品就像生孩子,运营就像养孩子。其实这个说法还不是特别准确。
因为,孩子生下来后,模子是不能变的,但一个产品上线后,还需要在运营过程中不断迭代和调整。所以,两者间的关系,既有产品方向和产品形态要决定运营的思路,反过来,又需要运营根据用户反馈和运营需求来决定产品的调整和迭代。
我再把这句话变得拗口一点,产品与运营的关系就变成了:产品负责界定和提供长期用户价值,运营负责创造短期用户价值+协助产品完善长期价值。
这当中,产品和运营间的关系之所以微妙,在于两点——

  1. 对于产品的长期价值用户无法立即感知到,我们需要通过运营先去创造出来一些短期价值,以刺激用户愿意先去尝试使用它。
  2. 产品的长期价值不是一蹴而就的,而是必须借由用户的持续使用和反馈,经过长期优化迭代后才能成立的。因而,在产品的长期价值还不是那么确定的时候,运营需要先通过创造一系列的短期价值让用户先能够来使用你的产品。

如果在面向用户的立场上,一旦产品的长期价值已经特别明确和具体了,这时候运营最应该做的事情,就是通过包装、策划、营销等一系列手段去面向用户把这个价值传递出去。这时候,运营所要发挥的作用,有点儿近似于传统意义上的“营销”了。
只不过,对一个互联网产品而言,这样的状态,永远是很少的。大部分时候,一个产品都处于持续不断的摸索、调整中,需要运营一起参与去完善它的价值。
在这个立场上讲,假如一家公司的产品和运营没法做到一条心,共同「以用户为中心」来做好自己的工作,最终共同为用户提供价值的话,其实是挺可怕的。
最后,我还想说,其实在互联网公司内部,因为产品和运营分别在不同的环节服务着用户,为用户创造着价值,所以会经常给对方挖坑,比如产品上了个功能让运营被用户骂得要死,或者是运营面向用户承诺了个什么鬼东西结果产品根本做不出来等情况,其实也是很正常不过的。
逻辑上,产品和运营能勾肩搭背手把手腿把腿以一对好基友的心态互相填坑、共同对用户负责,才是王道。
李大少:

产品和运营就像两个人,他们可以做兄弟,也可以做基友…
在产品规划过程中,运营应该如何配合PM,完善和规范产品的规划呢?比如我想做一个陌生人交友的应用。运营需要做的是找准自己的用户在什么地方。而产品经理则很容易沉入交互和产品的细节。特别是一些大局观不强的产品经理。他们更喜欢说“我用了facebook的时间线”我这功能是TW的。但是哪个用户会在意这个?
产品容易抠细节,而忘记了自己应该站的方向。
运营需要提醒和告诉PM,这个产品面向的人群是谁?是北上广深,还是某某镇KTV的官方应用?产品市场需求不一样,那么他们的产品形态和结构一定是不一样的。例如如果要做一个陌生人的应用。运营应该对产品说:“现在有陌陌了,你他妈的别闭门造车了!”我们不需要重新发明轮子!!
运营需要告诉产品:不要去做陌生人的,而是去做你身边20-25岁的陌生年轻女人。这需求就精准了。例如曾经有个法国人,做了一个网站,就是从intragram上搞到了很多很多很多美女的胸部自拍……这就是精准需求!特别是在现在,大家都在嚷着做平台,但是其实很多更垂直和小而美的需求一直存在着,这就是需要运营去发掘的!
MRD,BRD,PRD……这种,其实谁做都可以,就看你领导的口味了。这些文档,你可以写周报用,但是对于产品来说,不是必须的。运营要多去挖掘精准垂直的需求,以便给产品更精确的定位。例如百度的PK大咖,其实他们的人脸识别技术一直都有。并且专门从美国挖来的科学家做的。但是之前没有运营能提出来好的爆发和利用的点。
运营一方面需要告诉PM这个产品的用户在哪,另一方面,你也要告诉PM这个产品的市场和出路在哪!所以运营这个职位,其实若是细化,则可以分为用户运营,内容运营,商务运营。看到这几个词,基本就能发现,其实运营需要做的活挺多的。一个好的运营,也要能从数据里发掘出别人看不到的东西和趋势,为产品的迭代提供证明。
运营一定要最开始就加入产品开发工作中,和产品经理做好分工和调研。一个项目的开始,运营需从立项就加入。负责市场调研、用户调研、合作方联系,运营内容准备。产品主要做项目规划、产品脉络、产品规划和方向。只有这样,才能在做的过程中不断的去修正产品的失误。要不然,最后产品做完,木已成舟,运营要去运营并维护一个自己并不喜欢的东西,产品发现你运营他的东西,你一点都不高兴。大家都在负能量。

朋友们,对于产品和运营,您觉得是什么关系呢?对于产品和运营矛盾的处理,您有什么高招么?欢迎留言交流!
 

你可能还喜欢