产品运营岗的工作内容主要包含内容建设、需求提炼、活动组织、如何与研发建立良好合作4个部分，本文全面解析产品运营的日常工作及价值体现

关于互联网产品经理的话题历来火爆，产品运营就冷清得多。

产品运营入行门槛通常不高，工作内容又看似琐碎繁杂，面面俱到，易做难精。有这么几种观点：运营就是“做客服的”、“删帖子的”、“论坛版主”、“搬运工”、“保洁员”、“网络运维（完全是两个工种好么！）”……甚至很多从事运营的人自己也说不清楚，只能自嘲“打杂儿的”。

从职位名称到工作内容，产品运营都没有“产品经理”听起来那么“高端大气上档次”，一直缺乏清晰明确的定义跟标准，发展方向就更不明朗啦。我不止一次听到有人抱怨：“运营好没劲，我要改行做产品！”活儿多钱少没发展，产品运营到底是怎样的工作？它的价值究竟体现在哪里？我根据几年来从事社区产品运营工作的经验，尝试做个回答。

首先，什么是产品运营？个人观点，产品运营就是吸引用户使用产品并促使用户持续产出符合产品定位和发展目标的行为和内容、充分挖掘和发挥产品核心价值的一系列运作。例如对于社区产品来说，一定数量的人群在某种形式的网络空间内持续产生互动和内容，就形成了社区，社区运营就是吸引用户加入社区并促使社区用户持续产出符合社区定位和发展目标的互动和内容、充分挖掘和发挥社区价值的一系列运作。

其次，产品运营的工作具体有哪些？在我看来可以分为内容建设、市场推广、活动策划、用户维系、数据分析、规则维护、竞品调研、需求提炼8项，但它们在产品不同的发展阶段所占的比重是不同的；针对不同的产品类型，不同的用户群体侧重也不同。如新产品上线推广阶段，内容建设和市场推广是重点，产品进入稳定发展阶段，用户维系和规则维护的比重将逐渐增大；对BBS来说用户维系是一项主要工作，对于资源下载产品就要更注重内容建设和规则维护，面向学生群体和面向CTO群体的社区产品，运营重点也各自不同。

一、内容建设

1、标准建立：产品的价值观，由其承载的内容体现。

什么样的内容是合适的，希望产生的，什么样的内容是不合适的，应该排斥的，在产品上线伊始甚至产品策划阶段，就应该达成共识，并制定相应的标准，它将是运营人员未来开展工作的重要依据，并会通过产品运营传达给用户，并随着产品运营不断深入而日益清晰完善。

这也是我主张运营人员应该在产品策划阶段就加入产品团队的原因之一，运营人员只有深入了解产品的来龙去脉，充分认同产品体现的价值，才能正确地建立和把握标准并在运营工作中灵活地实施，否则只能做一个机械的“裁判员”。

2.内容初始化：运用技术或人工手段填充一批符合标准的内容作为产品冷启动的基础。

没内容的产品是个空壳儿，不利于产品推广，用户来了也会不知所措。通过内容初始化，吸引用户访问，快速树立示范，便于市场推广，渲染产品氛围，典型的例子：建立一个论坛，需要划分版块对内容主题进行细分；论坛开设新版，需要提前填充一些版面主题相关帖子；资源分享站点开张，也必须事先准备好一批种子资源。初始化内容越丰富，展现形式越生动，对新用户的吸引力越大，可不是简单堆砌一些干巴巴的说明文档就可以的。

3.内容审核：内容有了，用户多了，垃圾广告也就跟着来了。

运营人员需要定期检查并剔除垃圾广告内容，否则它们会充斥网站，严重影响用户浏览访问；如果出现违反国家法律法规、或者侵犯他人正当权益的内容，还可能导致网站发生安全问题无法正常运营。一部分审核工作可以通过技术手段自动完成，但仍然有一些需要人工维护，如敏感词库更新、网站安全监控以及推动审核系统持续升级以应对不断出现的垃圾广告新形式。

4.内容推荐：这里专指在产品内部进行的推荐（在产品外部其他网站上推荐属于市场推广范畴，下文详细介绍），它是非常重要的一项常规运营工作，既能够突出体现产品价值观，又能够鼓励贡献优质内容的用户。

做好内容推荐并不简单：首先运营人员一定得对内容标准把握到位，其次要具备一双能够在海量内容中及时发现优质内容和活跃用户的“慧眼”，还需要有一定的编辑能力，可以对原始内容进行适当的编辑加工使其更利于传播，而且要对产品各个推荐位置和推荐效果了如指掌。

这就要求运营人员熟悉产品，对各种显性隐性信息敏感（足够八卦！），了解社区文化和当下时事热点，能够以用户喜闻乐见的方式进行表达，了解产品数据，知道什么推荐位效果好，什么位置适合开发成推荐位。

简直跟做编辑的要求差不多了有木有？！但与传统编辑不同的是：评估编辑的工作可以直观地通过内容浏览量和传播量，而这两个指标对于运营人员的内容推荐工作并不足以衡量其价值。运营的内容推荐目的在于普及倡导产品价值观，引导用户产出更多符合产品价值观的内容，鼓励产生优质内容的用户，挖掘具备成长潜力的用户，这个效果不是一朝一夕就能够看得出来的，需要达到一定时间的积累方可，因此对运营人员的相关考核也需要综合评估，不能单纯只看某几个数据，做运营的同学本身也需要能“耐得住寂寞”啊。

5.内容整合：产品稳定运营一段时间，有了稳定增长的用户群体，积累了一定数量的优质内容，为了集中充分展示优质内容，更好地打造产品口碑，促进产品价值传播，就需要开展内容整合工作了。

主要有两种方式：

● 一种是给用户提供自主内容整合的工具，运营人员负责质量把关。比如CSDN博客的博客专栏，用户可以自主申请建立自己的博客专栏，收录自己博文中成系列的精华博文，由运营人员遵循一定的标准对专栏申请进行审批，确保专栏的质量和有效性。

● 另一种是由运营人员将已有的优质内容根据不同领域、不同主题进行编辑整理，加工成内容专题形式。如每周博客精华周刊、每周论坛热点回顾、每月下载资源top100、版块精华问题集合等。这是非常受用户欢迎的一种形式，对运营人员的内容编辑能力要求也更高，也可以在活跃用户群体中邀请用户参与编辑工作，但最终的质量把控还是要运营人员来负责的。

6.开发商业价值：做产品，有了人气卖广告，谁不会？还需要开发神马商业价值哇？

你能够做到不让过多的广告干扰用户体验吗？

你能够做到根据产品形式和内容匹配合适的广告吗？

你能够做到根据产品特点和用户人群策划商务项目吗？

你足够了解你的产品和用户吗？

互联网产品简单地卖卖广告就能赚得盆满钵满的时期已经过去了，客户买的其实是产品提供的服务，客户看中的是使用产品的用户群体所能带来的购买力和口碑。而运营人员恰恰对产品能提供的服务和用户群体是最为了解的，产品承载的内容本身就具有潜在商务价值，如资源付费下载、在线付费咨询、精华内容出版等等，各种商务项目的实施最终也是以各种产品内容形式来体现。那么，在产品商业价值开发中，如何充分发挥运营的价值呢？这个问题，可不仅仅是有志于产品运营的同学应该思考啊。

二、需求提炼

提产品需求是运营同学的日常工作之一，看似简单，其实并不容易。

什么是产品需求呢？产品需求就是对达到某个既定目标需要实现的产品功能和特性的描述，可以从以下几个维度来划分：

1.外部需求和内部需求

前者来自各个渠道收集的用户反馈，如微博微信qq群客服邮箱客服电话，以及产品自身的反馈渠道（如论坛的客服专区、在线即时咨询窗口等）；后者来自公司内部，如老板和其他部门的反馈。这些反馈通常都不会很明确，需要运营同学进行整理挖掘，沟通调研进而提炼出需求。如果不经整理提炼就统统丢给研发同学去处理的话——会被鄙（qia）视（si）的……

2.改进型需求和新建型需求

它们俩是从1到10和从0到1的区别。我个人的建议是已有的产品如果改进优化后能用，尽量不要另起炉灶，除非是原有的产品从定位到风格全都跟新需求不一致。这就要求运营对现有产品定位跟功能了如指掌，能够根据需求制定出合理的问题解决方案，有时甚至可以不需要产品改动就达到目的。这样不是效率很高吗~

最怕的是拍脑袋就做个产品，不考虑是否能利用已有的，导致留下一堆半截子工程，说能用也凑合能用，彼此间定位不清晰，后期运营推广也不好做；同时系统里很多冗余代码难以维护，如果负责人一离职就再也没人能说清这产品的来龙去脉，于是又推倒重来一遍……对人力物力的极大浪费啊。

3.笼统型需求和精确型需求

前者如“现在这个编辑器太难用了换一个吧，好多代码格式都不支持”，后者如“需要一个除现在支持的代码格式外，还能够支持markdown语法的编辑器”。很多用户反馈的需求就是前者那样的，必须深入了解分析，否则过于笼统不具体的需求，是无法实现的，即使勉强上马，也一定会因为需求不明确而导致工期延误和反复修改，最终应付了事，所有参与人忙得够呛都不开心，宁可早期多用一些时间把需求搞清楚。

4.解决问题的需求和提高效率的需求

“我需要一个能给用户群发邮件的后台”和“我需要能够自己导出符合某些特征的用户邮箱列表给他们群发邮件”。不过后者需要评估使用频度，如果是高频使用需求，开发一个还是有必要的，否则每次都要找研发同学给导出邮箱也确实麻烦；如果是为了某个临时性的项目用，或者一年也用不了几次的低频需求，那就没必要开发一个专门的功能了。

为什么要从这些维度来划分呢，因为实现产品需求的资源通常是有限的，因此必须对需求的合理性和优先级做出明确判断，并以此来决定开发的资源投入以及排期先后。

另外有些似是而非的“产品需求”，实际上是bug，bug和产品需求的区别及处理方式的不同如下：

产品需求：

● 针对还不存在的功能提的

● 解决的是“不好用”的问题

● 实现周期通常较长

● 发给产品经理处理（这个要看具体团队构成和分工，是否有专门的产品经理来处理需求，如果运营兼负责产品那就由提出需求的同学自己处理了）

产品bug：

● 针对已经存在的功能提的

● 解决的是“不能用”的问题

● 解决时间视bug严重程度，通常要求尽可能快地处理

● 可直接发给研发人员解决

提需求和提bug的流程

产品需求描述

产品经理通常需要把收到的各路需求整理成产品原型文档，但对于运营同学来说并没有那么严格的文档要求，只要让产品同学能够明白你的意思就可以；不过为了提高沟通的效率，有必要参照一定的格式来描述你的需求。

什么情况下需要提产品需求？

如果以上你都已经烂熟于心，对于如何提产品需求应该是没有问题了。但是且慢，知道怎么做只是最基础的，对于合格的运营来说，更重要的是判断要做什么和不做什么。

用户的需求永无止境，运营不能只是需求的传声筒，需要深入分析用户需求背后的目的和隐藏的问题，如果能够用已有的产品达到的，就尽量不要重复建设做新产品；如果能用运营的手法解决的，更不必耗时费力地动用产品和研发；如果能够利用已有成熟的渠道跟平台借势推广的，又何苦非要做一个“自己的”独立平台一切从零开始呢？做加法永远比做减法容易，另起炉灶似乎也比在原有基础上修补改进要痛快，但是资源永远都有限，无论是人力还是时间，即使你有一组强悍的产品和研发同学24小时无条件配合，仍然要评估需求真实的价值有多少，衡量投入产出比。运营的强项在于给你一个产品，你能够发掘它的一千零一种用法（玩法）并将其传递给用户来满足不同的需求，如果一接到新需求就要做个新产品，而不是先看看运用已有的产品是否能够解决问题，运营自身的价值何在呢？

● 目标足够明确吗？

● 已有的产品确实无法满足工作要求吗？

● 已有产品的缺陷已经极其影响工作效率吗？

● 成本是否合适？

● 如果答案是否定的，那就需要重新审视这个需求的合理性，并且和需求方积极沟通确定最终解决方案。

如何促使需求尽快实现？

● 需求表述明确，沟通清楚，提交流程规范：该自己做的一定要做到位

● 按流程提交需求后最好再当面跟产品经理沟通，尽快落实需求并启动

● 必要时要舍得砍需求，确保快速上线

● 充分利用各项资源来达到目标：平时和产品设计研发同学搞好关系，必要时通过上级推动都是方法

几点总结

● 产品改进通常要落后于业务需求

● 互联网产品改进伴随整个产品的生命周期，不是一次性的

● 产品改进是由运营驱动的

● 再好的产品，运营跟不上也是白费

● 对内容运营和社区运营来说，产品是辅助手段，不是目标

● 了解产品的互联网编辑/运营会有更多的职业发展机会

三、如何与研发建立良好的合作

一直以来，大家都很强调产品和研发之间的沟通合作，但随着互联网产品逐渐发展成熟，运营的职能和重要性相比以往愈来愈凸显，尤其在产品进入相对稳定发展阶段由运营主导的时候，以及初创公司团队由于人手有限运营可能要身兼数职的时候，运营与团队其他成员尤其是研发（其实也包括设计）是否能够建立良好的合作就显得尤为关键了。

1、运营和研发建立良好合作的重要性

通常一个互联网项目团队包括如下几个职能的人员（排名不分先后，且根据具体情况和不同时期人员配置会有增减）：产品、设计、研发、测试、运维、运营、市场、商务，其中的产品主要起到业务需求方（运营/市场/商务）和技术研发之间的桥梁纽带的作用，那么运营作为典型的业务需求方，只要把需求跟产品沟通清楚就好了，为什么还要和研发建立良好的合作呢？

第一、很多时候，运营要承担一部分产品的工作，必须和研发打交道

产品都是有生命周期的，一般来说，产品从无到有的孵化阶段是以产品人员和研发人员为主导，确保产品按需完成，如期上线；当产品上线后进入相对稳定的上升发展期时，运营逐渐成为主导角色，收集提炼出大量来自用户的，和运营过程中调研挖掘的产品需求，推动产品不断迭代优化。

而且很多公司里，产品和研发资源并不是完全从属于某一个产品线，这个产品上线稳定一段时间后，可能就会调去参与其它项目，不会有很多精力能够投入该产品的持续优化了。这个时候运营就必须责无旁贷地承担起一部分产品的工作，要和研发同学直接打交道。

第二、运营是最终担业绩的人，但无法独立完成业绩，需要其它职能的配合

在几乎所有的互联网产品中，运营都是最终承担KPI的人，而且运营的工作相对容易量化，可以各种数据指标的变化来衡量。

但互联网产品数据的提升，是不能仅靠运营单方面来达成的，一定是各个职能多方面通力合作的结果：产品界面不友好，运营拉来用户也留不住；系统性能不稳定，经常闪退或者报错，运营每天处理用户吐槽和救火就疲于奔命了，哪里还有精力去完成业绩。

可是往往运营又并不具备能够充分调动产品和研发资源的权限，如果自己团队有配备专属的产品研发还好，否则只能是多方面寻求资源协作，能否与研发建立良好的合作关系就尤为重要了。

第三、靠谱的研发能避免很多不必要的资源浪费

见识过不靠谱的研发，你就知道能有靠谱的研发是多么幸福的事情。

靠谱的研发，

不会拍着胸脯说这东西简单得很两天就上线，但是一旦承诺了排期就不会拖延；

靠谱的研发，

会保证产品开发质量，提交测试基本就是没有bug；

靠谱的研发，

不会想方设法推卸责任，很多拖了很久悬而未决的问题，到他手里研究一番就可以得到完美的解决；

靠谱的研发，

能结合运营的需求，做出方便又好用的后台，大大提升运营工作效率；

跟靠谱研发合作，运营不需要无休止地重复测试，提交bug；不需要没完没了地开需求沟通会，天天追着问进度；不需要担心某个需求无法实现，从而无法开展新业务。你说如果你是运营，是不是一定要努力找出那些靠谱的研发小伙伴组队啊？

2、运营如何和研发建立良好的合作

第一、谨慎处理需求，不要让研发白做工

通常技术都是业务的支持部门，技术要为业务服务，运营会结合业务发展不断提出需求改进产品是很正常的，但提需求绝不是随意的和漫无边际的。

一定是：

经过充分的论证调研——

现有产品确实无法满足业务发展——

研发成本不会超出现有资源范围——

才靠谱。

心血来潮、拍脑袋就上、不顾实际资源情况就开干的项目多半最后都是惨淡收场，参与人员付出的时间和精力也就白搭了。

研发最怕什么？最怕辛辛苦苦加班加点做出来的产品，最后没人用啊！等于研发这段工作的价值没有得到承认。

你如果说我不在乎，反正做什么不是做，每周都要写工作周报哦，我是研发只管实现你的需求就好了，做完了有没有用那是你们业务部门的事情跟我没关系。这样想的研发也就是混日子的心态，最后业务没发展、公司没发展难道研发日子就会好过吗？

真的有想法有上进心的研发绝不会这样想的，一定是希望自己开发的产品真的能够得到实际的应用，对公司的业务能够起到很好的支撑，进而自己的价值也得到了体现。

第二、充分说明需求，调动研发的积极性

上文说过，靠谱的研发，有想法有上进心的研发，一定不是机械地只管接活干活的人。

他们对业务也有自己的理解和想法，有时甚至能从别的角度给出更好的解决方案，前提是要让他们充分了解这个需求的来龙去脉，这个需求的背景，不仅仅是知道我们要做什么事，更重要的是我们为什么要做这个事：现在的这个产品需求是我运营经过调研分析确定的，我的解释是否能让你足够清楚明白了？然后从研发的角度，请你看看是不是有其他的隐藏问题？你有没有更好的解决方案？我们一起再探讨。

最后达成共识确定的需求，并不是运营单方面「压下来」的需求，而是经过业务方和研发讨论后共同认可的需求，研发也充分认识到了这个需求的价值和意义，你说他不会积极主动地完成吗？一定会的。

而且事先双方确认了需求和排期，后期的责任也非常明确，即使又有了临时紧急的需求变更（有时不可避免），也会更容易沟通。

相反，如果运营只是说我要做某个东西，告诉研发我要这样这样实现，你不要管为什么总之你必须给我做了，还得在指定时间点完成，否则到时影响业绩责任在你……这样研发就成了被动接工单的角色，如何规避风险避免担责任是他们要考虑的首要问题。

这过程中各种扯皮推卸互撕都有可能出现，程度轻重取决于工程大小和工期长短。如果遇到在公司里地位相对强硬的研发，还可能出现项目进度推迟甚至根本无法推进的情况。姑且不论责任究竟出在哪一方，宝贵的时间就这么耗过去了，错过了多少好业务。最后谁获利了？都没有啊。

第三、掌握沟通技巧，研发最怕频繁打扰

运营的工作广泛而又琐碎，很多时候要求「多线程任务并行」，经常要和各种用户打交道，因此运营的思维是比较发散的，需要具备相当的灵活性，这是运营工作的特点决定的。

研发则是逻辑性非常强的工作，要求考虑完整周密，天天跟机器打交道，非1即0，非正即负，没有模糊的中间状态可言。

写代码按照一定的逻辑顺序来，据说有人写代码激情迸发，写到high了物我两忘，完全沉浸在代码的世界里也是有的。

如果，隔个几分钟就打扰他一下，改个这里，修个那里，问个问题……研发的思路就中断了，这些单线程的同学们多半会抓狂。

所以我们必须利用工具来管理需求。把所有产生的需求统一放到项目管理工具中，如JIRA就是一种很常用的工具，汇总一批需求定期（这个时间间隔可以和研发事先沟通好，比如每周一次）和研发沟通，确定优先级和排期。

如果是紧急的需求，或者重大的bug出现（比如用户无法登录了），这种可以随时找研发处理，但是尽量不要零敲碎打地报需求，尤其是不要用即时沟通的方式，比如qq，电话给研发报需求，容易遗漏，不好统计和反馈，而且也给研发造成打扰。

第四、最好懂点技术，方便跟研发沟通

看到这里你可能会说：运营要懂技术还要研发干什么？这个当然不一样。

这里指的懂技术不是说运营要会亲手写代码，而是说对技术的一些基本概念，名词，表现形式和行业趋势有点了解是很有好处的。

研发是专业性较强的工作，在和研发沟通产品需求和进度的时候，多少要涉及一些技术相关的问题，如果遇到善于沟通又懂些业务的研发，他能尽量用非技术人员能够理解的方式跟你沟通，但这类人真心不多，能做到的基本都是技术管理层了。有些人还有一种研发范儿的傲娇，哎你们运营连这都不懂……

从我个人经验看来，如果有产品人员在，那么运营基本不用懂技术，只要把业务需求跟产品理清楚，就让产品去跟研发沟通好了；但是在缺乏产品资源，或者要直接和研发合作的场景，以及运营做到一定年限和职位的时候，懂一些技术的运营跟研发沟通会更有优势。

表现在沟通更加顺畅，省去了很多专业方面的铺垫，提需求时能够从研发角度进行一定的考虑，研发提出的方案和排期，心里基本也能有数，效率提高很多。

现在各种学习编程的资源非常丰富，我个人觉得运营学习一些编程知识，对思维的锻炼，产品的了解，视野的提升都有益。

第五、发掘共同利益，大家好才是真的好

说到底，运营的目标是要最大化产品的价值。这中间无论运用何种手段，只要合理合法不违反公司规定都是没问题的。

但如果总想着利用别人，占点便宜，也许一时可以，长久都是不奏效的。

最好的方式：是让参与的人有共同的利益，这事成了，大家都获利，而不只是单纯的部门之间工作配合或者帮忙而已。

一方面，需要从组织结构上理顺，为一个产品线配备齐全人员的产品事业部制，就比按职能划分按任务派活的大部门制更能激发员工对产品的责任感和积极性；

另一方面，要舍得分享，赏罚分明，产品做得好了，大家都有功劳，该分钱分钱，该团建团建。大家都知道跟你做事不吃亏，时间长了，靠谱的人会愿意持续跟你配合，你的口碑和职场信誉也就建立起来了。

3、运营眼中的靠谱研发是什么样的？

技术好，还用多说么。。。

还懂点业务，理解需求快，而且能结合需求完善更好的解决方案；

好沟通，能换位思考，我曾经合作过的一位研发leader，需求完美解决不说，还会自己主动琢磨「怎么把这个后台做得让你们运营好用一些」，好感度提升一万点啊！

最后，颜值还高……这算附加值了，能把自己打理得干净整洁精神焕发的研发更是稀少，遇上请务必珍惜。

以上我从运营角度谈了如何与研发建立良好合作的五点经验总结。

如果你合作的都是靠谱研发那自然好，大多数人没那么幸运，就只能从自身出发，把自己本职范围内的事都做到位，要求对方靠谱，自己一定要先尽量靠谱吧，然后尽量能换位思考理解合作伙伴，帮对方着想一下。

大家都是一起工作的，没有谁天生就和谁是对头，尤其在现在工作压力大的时代，每天和同事相处的时间比和家人都多，如果各个职能的小伙伴都能合作愉快，建立统一战线为实现共同目标高效地工作，那真是个清平安乐的美好人间。