良心干货!彻底认识产品运营岗的工作及价值体现

发布时间 :2022-07-02 09:33

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

网站运营的工作

全文较长,建议收藏起来慢慢阅读

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

 产品运营入行门槛通常不高,工作内容又看似琐碎繁杂,面面俱到,易做难精

网站运营

有这么几种观点:运营就是“做客服的”、“删帖子的”、“论坛版主”、“搬运工”、“保洁员”、“网络运维(完全是两个工种好么

)”……甚至很多从事运营的人自己也说不清楚,只能自嘲“打杂儿的”

 从职位名称到工作内容,产品运营都没有“产品经理”听起来那么“高端大气上档次”,一直缺乏清晰明确的定义跟标准,发展方向就更不明朗啦

我不止一次听到有人抱怨:“运营好没劲,我要改行做产品

”活儿多钱少没发展,产品运营到底是怎样的工作

它的价值究竟体现在哪里

我根据几年来从事社区产品运营工作的经验,尝试做个回答

 首先,什么是产品运营

个人观点,产品运营就是吸引用户使用产品并促使用户持续产出符合产品定位和发展目标的行为和内容、充分挖掘和发挥产品核心价值的一系列运作

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

 其次,产品运营的工作具体有哪些

在我看来可以分为内容建设、市场推广、活动策划、用户维系、数据分析、规则维护、竞品调研、需求提炼项,但它们在产品不同的发展阶段所占的比重是不同的;针对不同的产品类型,不同的用户群体侧重也不同

如新产品上线推广阶段,内容建设和市场推广是重点,产品进入稳定发展阶段,用户维系和规则维护的比重将逐渐增大;对BBS来说用户维系是一项主要工作,对于资源下载产品就要更注重内容建设和规则维护,面向学生群体和面向CTO群体的社区产品,运营重点也各自不同

 一、内容建设 、标准建立:产品的价值观,由其承载的内容体现

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

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

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

 没内容的产品是个空壳儿,不利于产品推广,用户来了也会不知所措

通过内容初始化,吸引用户访问,快速树立示范,便于市场推广,渲染产品氛围,典型的例子:建立一个论坛,需要划分版块对内容主题进行细分;论坛开设新版,需要提前填充一些版面主题相关帖子;资源分享站点开张,也必须事先准备好一批种子资源

初始化内容越丰富,展现形式越生动,对新用户的吸引力越大,可不是简单堆砌一些干巴巴的说明文档就可以的

 .内容审核:内容有了,用户多了,垃圾广告也就跟着来了

 运营人员需要定期检查并剔除垃圾广告内容,否则它们会充斥网站,严重影响用户浏览访问;如果出现违反国家法律法规、或者侵犯他人正当权益的内容,还可能导致网站发生安全问题无法正常运营

一部分审核工作可以通过技术手段自动完成,但仍然有一些需要人工维护,如敏感词库更新、网站安全监控以及推动审核系统持续升级以应对不断出现的垃圾广告新形式

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

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

 这就要求运营人员熟悉产品,对各种显性隐性信息敏感(足够八卦

),了解社区文化和当下时事热点,能够以用户喜闻乐见的方式进行表达,了解产品数据,知道什么推荐位效果好,什么位置适合开发成推荐位

 简直跟做编辑的要求差不多了有木有

但与传统编辑不同的是:评估编辑的工作可以直观地通过内容浏览量和传播量,而这两个指标对于运营人员的内容推荐工作并不足以衡量其价值

运营的内容推荐目的在于普及倡导产品价值观,引导用户产出更多符合产品价值观的内容,鼓励产生优质内容的用户,挖掘具备成长潜力的用户,这个效果不是一朝一夕就能够看得出来的,需要达到一定时间的积累方可,因此对运营人员的相关考核也需要综合评估,不能单纯只看某几个数据,做运营的同学本身也需要能“耐得住寂寞”啊

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

 主要有两种方式:一种是给用户提供自主内容整合的工具,运营人员负责质量把关

比如CSDN博客的博客专栏,用户可以自主申请建立自己的博客专栏,收录自己博文中成系列的精华博文,由运营人员遵循一定的标准对专栏申请进行审批,确保专栏的质量和有效性

 另一种是由运营人员将已有的优质内容根据不同领域、不同主题进行编辑整理,加工成内容专题形式

如每周博客精华周刊、每周论坛热点回顾、每月下载资源、版块精华问题集合等

这是非常受用户欢迎的一种形式,对运营人员的内容编辑能力要求也更高,也可以在活跃用户群体中邀请用户参与编辑工作,但最终的质量把控还是要运营人员来负责的

 .开发商业价值:做产品,有了人气卖广告,谁不会

还需要开发神马商业价值哇

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

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

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

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

 互联网产品简单地卖卖广告就能赚得盆满钵满的时期已经过去了,客户买的其实是产品提供的服务,客户看中的是使用产品的用户群体所能带来的购买力和口碑

而运营人员恰恰对产品能提供的服务和用户群体是最为了解的,产品承载的内容本身就具有潜在商务价值,如资源付费下载、在线付费、精华内容出版等等,各种商务项目的实施最终也是以各种产品内容形式来体现

辣么,在产品商业价值开发中,如何充分发挥运营的价值呢

这个问题,可不仅仅是有志于产品运营的同学应该思考啊

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

 什么是产品需求呢

产品需求就是对达到某个既定目标需要实现的产品功能和特性的描述,可以从以下几个维度来划分: .外部需求和内部需求 前者来自各个渠道收集的用户反馈,如微博群客服邮箱客服,以及产品自身的反馈渠道(如论坛的客服专区、在线即时窗口等);后者来自公司内部,如老板和其他部门的反馈

这些反馈通常都不会很明确,需要运营同学进行整理挖掘,沟通调研进而提炼出需求

如果不经整理提炼就统统丢给研发同学去处理的话——会被鄙()视()的…… .改进型需求和新建型需求 它们俩是从到和从到的区别

我个人的建议是已有的产品如果改进优化后能用,尽量不要另起炉灶,除非是原有的产品从定位到风格全都跟新需求不一致

这就要求运营对现有产品定位跟功能了如指掌,能够根据需求制定出合理的问题解决方案,有时甚至可以不需要产品改动就达到目的

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

 .笼统型需求和精确型需求 前者如“现在这个编辑器太难用了换一个吧,好多代码格式都不支持”,后者如“需要一个除现在支持的代码格式外,还能够支持语法的编辑器”

很多用户反馈的需求就是前者那样的,必须深入了解分析,否则过于笼统不具体的需求,是无法实现的,即使勉强上马,也一定会因为需求不明确而导致工期延误和反复修改,最终应付了事,所有参与人忙得够呛都不开心,宁可早期多用一些时间把需求搞清楚

 .解决问题的需求和提高效率的需求 “我需要一个能给用户群发邮件的后台”和“我需要能够自己导出符合某些特征的用户邮箱列表给他们群发邮件”

不过后者需要评估使用频度,如果是高频使用需求,开发一个还是有必要的,否则每次都要找研发同学给导出邮箱也确实麻烦;如果是为了某个临时性的项目用,或者一年也用不了几次的低频需求,那就没必要开发一个专门的功能了

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

 另外有些似是而非的“产品需求”,实际上是,和产品需求的区别及处理方式的不同如下: 产品需求: 针对还不存在的功能提的解决的是“不好用”的问题实现周期通常较长发给产品经理处理(这个要看具体团队构成和分工,是否有专门的产品经理来处理需求,如果运营兼负责产品那就由提出需求的同学自己处理了) 产品: 针对已经存在的功能提的解决的是“不能用”的问题解决时间视严重程度,通常要求尽可能快地处理可直接发给研发人员解决 提需求和提的流程  产品需求描述 产品经理通常需要把收到的各路需求整理成产品原型文档,但对于运营同学来说并没有那么严格的文档要求,只要让产品同学能够明白你的意思就可以;不过为了提高沟通的效率,有必要参照一定的格式来描述你的需求,这里举个我现在团队的例子: .需求名称:产品名称+功能+提出时间,如“CC编辑后台改进产品需求---” .目的:有助于产品同学充分理解你的需求的必要性和重要程度,如“为了提高编辑发稿的工作效率”或“为了统一网站整体风格而进行UI重新设计”

 .优先级和时间要求:这个也很重要,因为产品经理通常会收到大量的需求,如何安排优先级处理顺序

如果你在需求里有明确的说明,那么处理效率会高一些

如“第一优先级,需要六月日前完成”

 .需求描述:说明用户身份(外部用户和内部用户的处理方式有区别),页面需要包含哪些元素,期待的布局和风格,排列顺序,是否必选项,有何特殊要求,是否需要查询及查询条件设定,是否需要权限管理等信息,尽可能详细,最好给出参考案例或类似竞品截图

 什么情况下需要提产品需求 如果以上你都已经烂熟于心,对于如何提产品需求应该是没有问题了

但是且慢,知道怎么做只是最基础的,对于合格的运营来说,更重要的是判断要做什么和不做什么

 用户的需求永无止境,运营不能只是需求的传声筒,需要深入分析用户需求背后的目的和隐藏的问题,如果能够用已有的产品达到的,就尽量不要重复建设做新产品;如果能用运营的手法解决的,更不必耗时费力地动用产品和研发;如果能够利用已有成熟的渠道跟平台借势推广的,又何苦非要做一个“自己的”独立平台一切从零开始呢

做加法永远比做减法容易,另起炉灶似乎也比在原有基础上修补改进要痛快,但是资源永远都有限,无论是人力还是时间,即使你有一组强悍的产品和研发同学小时无条件配合,仍然要评估需求真实的价值有多少,衡量投入产出比

运营的强项在于给你一个产品,你能够发掘它的一千零一种用法(玩法)并将其传递给用户来满足不同的需求,如果一接到新需求就要做个新产品,而不是先看看运用已有的产品是否能够解决问题,运营自身的价值何在呢

 案例一:数据分析后台 曾经有同事负责运营一个垂直专业领域的群组,提出要做一个数据分析后台,能够根据加入群组用户填写的个人信息自动生成各种维度的分析图表,“就像专业的数据分析报告那样”,他说

这并不是一个实现起来很简单的需求,虽然对用户的数据分析是有必要做的

但是该群组目前的注册用户只有几千人,且新用户增加速度非常缓慢,用户数据分析的时效性并不是非常高,因此最终解决方案是导出用户数据到中,运营自己根据统计需求,利用生成分析图表,至于是否像专业报告,那就看自己的造诣啦~如果未来用户量和增长速度达到一定规模,人工统计无法满足,才是需要开发数据统计后台的时候

 案例二:大会报名 我所在的社区运营团队曾经负责组织公司的开发者大会报名,通过社区各个渠道向开发者用户进行宣传,使用的是社区的活动报名系统,可以汇聚各个渠道的报名数据到后台数据库

有同事提议说开发一个大会报名,以后组织大会都可以让用户通过报名,这样推广时只要通过推送提醒就可以啦~~~我说你这个创意不错,你先想法让用户都装上这个,然后

就没有然后了

 总之接到需求后,问自己以下几个问题: 目标足够明确吗

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

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

成本是否合适

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

 如何促使需求尽快实现 需求表述明确,沟通清楚,提交流程规范:该自己做的一定要做到位按流程提交需求后最好再当面跟产品经理沟通,尽快落实需求并启动必要时要舍得砍需求,确保快速上线充分利用各项资源来达到目标:平时和产品设计研发同学搞好关系,必要时通过上级推动都是方法 几点总结 产品改进通常要落后于业务需求互联网产品改进伴随整个产品的生命周期,不是一次性的产品改进是由运营驱动的再好的产品,运营跟不上也是白费对内容运营和社区运营来说,产品是辅助手段,不是目标了解产品的互联网编辑市场_



- END -