用户增长运营是什么，做什么？

从数据产品转用户增长运营，这是我的几点思考:

1.用户增长运营是什么，做什么

要解释用户增长运营，首先，要先明确什么是运营，怎么做用户增长。关于这两个问题，我想引用下我比较赞同的两个业内人士的观点。

运营是通过用户、内容、品牌等运营方式，传递产品价值、打造内容生态、创造新玩法，将产品和用户更好的连接，达到产品最终目的–韩叙

“增长黑客”是以数据驱动营销、以市场指导产品，通过技术手段贯彻增长目标的一群人。这就需要他们既了解技术，写得了代码；又能了解人性，能捕捉用户的心理感受和真实需求；最重要的是，他们经常能突发奇想，发挥创意，大开脑洞，以小的投入获取较多的用户和收入。–《增长黑客》

所以在我看来起来，用户增长运营的工作，就是通过业务梳理拆解出增长点与增长公式，并通过实验测试与数据分析，驱动产品的快速迭代，找到增长方向，为用户传递产品价值，实现产品增长目标。在滴滴，我所在的市内增长组，会以项目FT的形式，联合产品BI研发等部门共同协作，通过AB测试与数据敏捷分析等方法来指导业务发展，从而快速迭代产品，实现增长目标。

为了实现用户增长，除了要深入了解业务，在产品的全流程中拆解增长公式，寻找增长空间，还需要不断学习，通过新维度找到新的增长方向。比如对于用户增长最重要的数据分析能力，就从最开始的在大学只会用excel的数据透视表和vlookup等几个函数处理大量数据，到在网易通过学习使用网易有数这样的敏捷BI工具实现数据的可视化分析，通过维度下钻与用户分群找到增长空间，再到滴滴切换到Tableau进行可视化分析的同时，对于新尝试的分解维度，学习直接用SQL跑数据进行快速分析，开始接触算法调优。对于用户增长，每一个新的实验方式与新的数据分析维度，都是可能的新增长点。

至于为什么需要用户增长运营，在这个移动互联网流量红利不再，就连线下流量都处于火热争夺中的现在，更需要通过精细化运营来实现产品增长目标的时代，用户增长运营的作用尤为突出。

例如对于内容运营，传统运营主要是依靠长期积累的经验，去抓住目标用户的内容需求，靠类似于传统媒体主编的模式，进行选题与内容生产，而对于用户增长来说，我们更倾向于从经验驱动转向方法论驱动，依靠用户群划分与快速实验，数据驱动迭代，在经验的的基础上，进一步找到优化空间。也只有这样通过方法论驱动，才能实现分发针对性内容，做到千人千面，不再是主编的经验与个人倾向决定。

再比如对于电商运营，如果将企业营收指标拆解为流量转化率客单价，那么传统运营的主要抓手是渠道运营去拉更多的流量，通过品类运营的各种资源与工具的熟练运用，去提升转化与客单价，而用户增长的思路可能会更多的根据渠道的具体数据情况，对应的进行用户群的划分与运营方式的探索，通过数据驱动，针对不同用户匹配不同运营策略，实现增长指标。

可能在部分人看来，用户增长只是从过去的靠经验变为靠实验数据验证，并不是脑暴式的底层创新，但实际上，脑暴式的创新是依靠于灵感的不可持续的创新，而通过实验与数据驱动运营方式的快速迭代，是一套可持续的创新思路，即使每次只能做出很小的提升，但持续下去一定可以收获更大的成果，最终当产品的全流程都找到了增长的方向后，这就是一个伟大的创新。

靠用户增长这一个单一指标似乎可以在一级市场里唤风唤雨，让VC/PE来跪舔，但是在二级市场，必须有好几个可供差遣腾挪的增长因素，否则分分钟打脸。

优秀的经营者，都是节奏大师，知道什么时候该在几个增长指标之间调兵遣将，不会把单一指标快用“死”了才找援兵，懂得休养生息。譬如Facebook让 ad load休息了好几个季度，直到Instagram开始大规模商业化才重新激活这个指标。

更伟大的经营者，是可以重写企业的收入公式，扩展疆域，这是华丽的冒险，也是最激动人心的旅程。譬如：丁老板去养猪，我从来没嘲笑过。网易做严选和考拉，电商收入在2017Q2已经占到20%的收入了，如果这个比例再持续增加一些，网易的收入公式就改写成功了。–<增长的接力棒>朱时雨

最后，正如上文所说用户增长的最终目标，可能就是找到每一个可能的增长点，梳理出产品的增长公式，并根据增长需求对增长指标进行合理调配均衡，找到恰当的增长节奏，甚至通过挖掘新的增长点，重写产品的增长公式。

2.”运营是个筐，啥都往里装”

说到运营，似乎是个门槛不高的行业，相比于”人人都是产品经理”，好像”人人都在做运营”，但说到实际的工作内容，又好像都不太一样。在做社群运营的，每天泡在核心用户群里维持群活跃;做用户运营的，忙着做数据分析处理用户反馈，在做新媒体运营的，除了写公众号就是微博抢热评。

笑谈背后，是运营纷繁复杂的职能种类:用户运营、内容运营、活动运营、内容运营、社区运营、电商运营、渠道运营、新媒体运营。

甚至连具体的岗位，不同的公司不同阶段的工作内容，也不尽相同，比如我所在的滴滴顺风车的用户增长运营，按大类应当属于用户运营，由于面对亿级用户，更偏向于策略性运营，根据用户属性划分相应的用户组，并制定相应的策略以实现拉新，激活，留存，转化，传播的用户增长;但是中等规模的产品中，可能用户运营的主要工作是促进核心用户群体的活跃与转化，激励用户产出优质内容，在小规模的创业公司，由于量级小，用户运营可能更多的是做用户反馈的处理与用户群运营;

社区运营在产品早期，做得更多的可能是天使用户的引入与社区内容的准备，以实现冷启动，而在成熟社区，可能关注点就转向了用户内容分发机制与激励体系，建设社区生态，再比如新媒体运营，在滴滴是属于市场部门的工作。

所以，面对庞大复杂的运营体系，相比于急于求成做”全栈运营”，我更倾向于从用户增长运营的角度深度切入，试图在实践中总结出一套适用于自己的运营方法论，并试图应用到扩展到其他运营领域中，逐渐向真正的”全栈运营”迈进。

3.运营和产品岗之间，并不一定”泾渭分明”

在滴滴，加入的用户增长团队是属于运营组，从网易的数据产品，到滴滴的用户增长运营，本以为会经历一段时间的适应期，但其实现在回看，从业务数据梳理与分析，到数据与实验导向的业务决策，再到项目推动与团队沟通，其实两边工作的日常有很多都是类似的，只是可能思考的角度从产品更关注的需求与逻辑，转向了运营所关注的流程与细节。

当然，这也与我所在的运营是用户增长方向的特殊性与公司的部门结构有关。

之前在网易时，我所在的事业部运营以内容运营(编辑)为主，对于需求的把控能力有限，提出需求后，作为产品需要重新进行调研评估明确需求，产出产品方案并交付开发，是产品作为项目的主导推动项目进度，运营在方案评审后，对于项目就参与较少，基本上除了定期的进度沟通和共同探索遇到的项目问题，就直接等待交付验收。

而在滴滴顺风车的用户增长运营组，对于车主日这样的运营活动，项目的前期调研与规划，活动模式策划，项目节点的划分与推进，完成后的数据分析与优化迭代，都是运营的工作，产品更多的是在原型交互产出，与开发排期沟通中参与，是运营来作为项目的主导，承担项目经理的角色，对从项目目标到项目产出的全程负责，更考验运营的项目把控能力。(本来以为在这边作为运营，可能不需要画原型，但实际上，为了和市场，产品，设计沟通策划的活动，除了基础的活动流程与原型，连异常流都进行了梳理，再细化点也就可以看做PRD了。)

所以很幸运这次可以在经历较为”无痛”的转型的同时，更深入了解与参与实际业务，这也是我对于这次转型最大的期待，相比于之前做的数据分析都只能作为运营结果的监控与复盘，对业务提出优化建议，在这里，可以深度参与业务，通过用户群划分细化运营策略，通过AB测试的数据分析来验证各种业务方向上可能的增长点，并根据实验结论指导业务决策。在我看来，这种从偏向理论的数据分析到利用数据做出决策的宝贵转变机会，对业务理解的加深和个人成长的促进是无价的。

4.产品和运营间为什么”水火不容”

说到产品和运营，虽然互相需要紧密协作，但是似乎关系总是有一丝微妙，运营需求好像总是排不上优先级，为新功能策划活动带来的收益却归给了产品;产品好像也总是面对着提出运营的完全没有产品思维的需求  。

所以这次从产品转运营之初，还是有那么一丝担心，是否能够在作为运营，从运营目标为出发点考虑问题的同时，保持和产品的高效沟通协作。但可能是由于之前有过产品经历，比较，了解产品对于运营需求常见的需要确认的细节，并提前准备，在这边作为运营，在和产品提需求时，还是比较顺畅的。但在实际的沟通中，也体会到了为什么运营产品之间，可能存在沟通不畅的问题，在我看来，可能一个重要的原因就是思维角度的差异。

对于运营来说，负责的是从目标到结果，注重流程化，精细化与数据化思维。

对于一次大型活动，运营的侧重点更倾向于从活动目标开始进行拆解，明确在流程每个环节中要达到的指标，与团队职责的划分，最终实现项目结果。比如对于活跃车主增长的指标，可以拆解为“活跃车主增长=新车主活跃增长+老车主活跃增长”，老车主活跃增长又可以拆解为“老车主活跃增长=活跃车主留存提升+沉默车主激活”，对于沉默车主激活的动作又可以拆解为目标用户选取，选择用户触达文案触达方式，引导触达后转化等流程，并把增长指标划分到每一个具体环节，关注触达率，点击率，转化率等多重指标，通过不断试验寻找增长空间。团队职责划分上，对于新增车主可能与市场部的品牌建设关联较大，车主留存率除了通过运营动作提升外，和产品机制与体验的关联较大，需要产品共同负责。对于运营，面对最终的KPI，只有拆解到每个流程环节，明确到每一个时间节点与负责部门，才能在项目周期中始终明确目标，有效推进进度，共同完成任务。

对于产品来说。负责的是从需求到方案，注重逻辑性，细节化与投入产出比。

同样对于一次大型活动，产品可能更关注需求的逻辑，是否真正满足了用户在使用场景下的需求，需求的逻辑与细节是否明确可实现，毕竟只有拿出完备的流程，准备好每个细节可能的问题，才能顺利通过技术评审不被问倒，技术排期的时间预估相对准确，同时面对永远开发不完的需求池，产品也需要注重功能开发的投入产出比，可能就会拒掉一些相对收益不够高的运营需求。

5.产品和运营间如何高效沟通

其实无论是产品还是运营，共同的目标都是让产品更好，让用户更喜欢，只是可能由于职位不同，角度不同，地位不同，得出的观点不同。要想实现高效沟通，就必须换位思考，找到共同语言。

对于需求的逻辑性，无论是产品还是运营，对于用户需求场景的敏感度与站在用户角度思考的同理心，都是基础条件，并且运营作为离用户最近的人，对于用户需求的把控应当是更加精准的，在需求逻辑上，只要耐心沟通，明确用户需求与具体场景，有数据作支撑，应该可以达成一致。

而对于需求的细节化，实际上与运营的精细化有着相同性，对于用户我们会进行用户分层并进行不同的动作，对于流程我们会进行拆解，在每个环节进行ab试验与数据分析以找到增长方向，那么在给产品提需求时，也应当对于产品的细节进行明确，避免不必要的返工，当然，对于细节的梳理应当是和产品一同完成的工作，对于从需求逻辑到产品逻辑的梳理和提前排掉技术上的一些常见坑，产品会更加专业。

最后，对于投入产出比，可能是最见仁见智的问题，对于运营，如果一个小的产品改动可以节省大量的运营精力，提高运营活动效果，当然会认为投入产出比很高，应该提高优先级。但对于产品，可能同时一起等待排期的会是大型版本需求，涉及全量用户的体验提升，自然要优先保证，相比下运营需求自然排不上优先级。

那么，面对这样的认知差异，如何让产品运营双方的认知同步呢?最好的方法还是摒弃主观的重要性判断，用客观的数据说话。

6.如何用数据说话

如何用数据说话，根据项目的情况，可以分为以下几种情况：

1.有明确数据来证明

对于已经上线的功能，可以根据已有的数据进行分析，证明需求的重要性。比如随着业务的发展，用户群的扩大，原先制定的用户运营策略可能已经不能适用于全量用户，需要区分用户群应用不同策略，这种情况下，可以对以前的数据进行分层分析，当分层结果证明不同类型的用户对于同一策略的接受度有明显的分层时，产品也就自然需要进行相应的改动。

2.有类似策略可参考

对于没有明确数据的情况，为了客观的说明问题，可以参照以往活动策略的数据进行预估，比如根据以往活动的作弊拦截情况，说明本次活动防刷券反作弊策略的必要性。有些数据还可以参考竞品的情况，对于可以通过观察竞品数据评估效果的大规模的策略，也有一定的借鉴意义，但绝不是说是因为竞品上了某个策略就一定要追上，而是对产品用户群分析验证是用户的真实需要后，参考数据进行效果预期。

3.纯新策略的 MVP 验证

没有使用过类似策略，连竞品都没有可以参考时怎么办?对于用户增长运营来说，这是经常面临的问题，为了避免浪费开发功能的人力物力，用比较传统的方法做MVP实验，手动完成预期中通过产品 机制实现的功能，通过数据分析来决策功能的重要性是常见的方法。比如对于沉默用户的激活，除了常见的定期活动触达，奖励触达外，如果想通过生日触达等情感化个体化的触达的方式提高激活率，长期来看肯定需要产品机制的支持，但是在需求验证的阶段，可以通过每天手动跑出一批生日用户触达的方式实现，有了一定量的数据做支撑，也就有可以验证需求的重要性。

7.产品和运营间如何协作

通过用数据说话，拉平了认知差距后，在产品上线的全流程中，产品和运营间应该如何协作呢?以下是我这一段时间的总结：

首先，老板决策完产品的发展方向，团队统一对于项目背景，目标，方向的认知之后，产品和运营就应该开始协作，对于产品功能涉及到的用户，需求，场景，方案，市场竞品情况，运营模式等进行分析，明确产品功能框架，运营规划，项目关键时间点等。

然后，按照规划，产品与运营开始分别推进工作，产品调研用户，规划原型，沟通技术，运营准备流量引入，用户教育，内容填充方案。并定期同步工作进展与可能存在的问题与风险，共同探讨完善方案。在进入开发前，最后全面 review 方案，明确可能存在的问题，确认后进入开发，产品跟进开发问题，运营准备运营方案，并定期同步项目进度。

接下来，上线前，最后共同验收产品方案，确认是否满足产品预期，确认运营方案与准备情况，总结项目中遇到的问题，探讨二期规划，确认后功能上线。

上线后，产品关注功能用户反馈，BUG 情况与用户接受度，运营按规划推进运营策略同时，关注产品数据是否符合预期并分析原因，寻找运营中遇到的问题与产品优化空间，验证后转化为产品需求，开始新一轮循环。

8.为什么”人人都想做产品经理”

虽然产品和运营都是互联网公司重要的角色，但是相比于”人人都是产品经理”的火热，运营好像还是有一丝”被冷落”，甚至听到我从产品转运营，有几个之前一起做产品的同学流露出了一丝惋惜。

当然，在实际的工作情况中，我并不认为运营相比产品，在岗位上存在劣势，同样是为了产品目标而协作，产品负责功能的设计与跟进开发，运营负责通过运营手段，实现产品目标，传递产品价值，虽然在工作内容方向上有所差别，但是并不能说有高下之分，在腾讯等公司的校招中，产品策划方向与运营方向是统一招聘的，也能侧面说明在需求分析，数据分析，项目执行力等基础能力的要求上，产品和运营都是一样的标准。

那么，为什么现在对于非技术岗，大家更愿意做产品不愿意做运营，甚至很多运营希望转产品方向呢?

我认为可能主要还是因为”人人都是产品经理”的启蒙作用，大家对于产品经理的认知比运营要强，找实习求职有更强的倾向性，企业在招聘过程中针对这种情况，也把更多的泛职位定义为产品经理(助理)，甚至连数据标注，处理用户反馈，这种没有太多技术性的基础工作也定义为产品助理，让产品的门槛进一步降低，更多的新人涌入。(实际上，有产品感和可以做好产品间，可能还有着一定的差距，比如没有技术背景的新同学，在技术评审排期时，由于对于技术实现上可能存在的问题，不能完全理解，很容易被问倒或者给出难以实现的方案，实际上并没有想象的那么美好)

另外，不同方向的运营工作内容有所差别，内容运营，新媒体运营等方向要求有一定的文字功底基础，门槛较高，很多门槛低一些的运营实习岗其实是做上传产品内容，收集用户反馈，建用户群通知这种基础性工作，也让希望从事运营方向的同学对于运营的未来空间有一定困惑。(转做运营之初，本来想找几个同学交流一下，吸取一下经验，但实际聊了后发现虽然都是运营，但是渠道运营，新媒体运营的和用户运营的工作内容差距还是比较大。虽然思路可以借鉴参考，但是实际工作方法上还是要自己多做多思考适合自己的方法论)

最后，robin，周鸿祎，张小龙等有影响力的公众人物也都把自己定义为产品经理，进一步理想化了产品经理，吸引了人才的同时，公司也更加重视产品经理，进一步促进了产品岗位的火热。

但其实，作为新手产品经理(助理)当然也要做很多的跟进琐碎需求，处理用户反馈等基础性工作，产品运营的工作也十分锻炼产品思维，数据分析与协作沟通的能力，并不能说有高下之分，还是应该根据自己的兴趣与能力，企业的文化与岗位工作内容来做权衡。

9.说给当初的自己

两个月的实习下来，除了工作经验上的积累，还有一些工作方法上的总结，在这里分享给大家，也说给当初的自己。

1.从零开始的心态

不管之前积累了多少经验，到一家新的公司，都应当有一种归零心态，从头开始。每家公司，每个业务线都会有积累的一套规则方法，如果用之前积累的旧思路，对着并不熟悉的新场景生搬硬套，难免遇到问题，过去积累的经验当然会在工作中有所帮助，但是不同的项目方向，不同的老板风格，不同的同事性格，不同的部门关系，都要求我们要重新适应环境。踏实的了解项目的目标，业务的现状，工作的内容，这样才能更好的融入新环境，找到新节奏。

2.时间管理与执行力

作为运营，难免遇到并行任务多，项目对接人多，临时插入的工作多的问题，如果不能高效管理时间，可能会造成忙碌一天，但是项目并没有推进的情况。如何高效处理事物，提高执行力?可以从自我管理和项目管理两方面入手:

对于自我管理，可以每天工作前或者前一天工作后，提前梳理任务，安排完有具体时间点的会议讨论后，按照重要紧急性安排工作优先级。面对临时需求打断手头的工作固然难以避免，但是梳理任务有助于我们确定临时需求的优先级，避免错过真正重要的任务的deadline，得不偿失。

对于项目管理，最重要的就是明确项目对接人和预估完成时间点，对于难以立即确定的项目，至少也要明确下一次沟通的时间，避免只能被动的接受通知的局面，能够主动的把控进度，明确责任。另外，更好的项目管理意识是把每一项任务都看做一个自己主导的项目，去思考项目的目标，资源，方案，数据，进度。这样也有助于我们认真思考，提升，做好每一个小任务。

3.向上管理

向上管理是一套完整的理论体系，有幸在一次分享中有一些基础的了解，在这里稍微分享一下我的理解。最基础的向上管理就是站在上司的角度思考，了解上司的目标，需要上司决策时，提供上司最需要的信息，寻求上司的资源，项目完成后汇报项目结果。

要理解上司在给你传达了目标后，是要求你去执行，雇用你就是为了节省自己的时间和精力去为团队更多服务，对于执行的具体方法与细节并不如你了解，所以面对工作中的问题，要包装成一个”产品”输出一个尽可能的结果，从问答题变成选择题，从”这个事情我做不了”到”这个事情需要您决策一下方向，提供一下资源”，来降低上司的时间成本。

相比于直接寻求上司的帮助，不如同步事情的背景与问题，并提供相应的几套潜在方案供选择，帮助上司做决策，要求相应的资源。在快速解决问题的同时，这也有助于节省上司的时间，让上司明确项目进展，推动上司来进行决策。

回归主题，”不懂BI的产品，不是好运营”，产品，运营，BI，虽然在具体工作上有着不同的侧重，但对于基础的产品感，运营技能和数据分析能力的要求，应该是共通的，用实验与数据驱动，进行产品迭代，实现用户增长，也应当是大家的共同目标。

以上就是我的几点思考，自己系统的梳理成文的同时，也希望可以对大家有所帮助。

成长之路，与君共勉。