编辑导读：如果要说什么是互联网行业最普遍的职位，运营一定算一个。因此也有人认为，运营是互联网行业最没有门槛的一个职位，没有核心竞争力。事实上，近年来对于运营的要求越来越高，还要求掌握一些产品技能。本文作者对此进行了分析，与你分享。

前言：经常在某些平台上刷到对运营这个岗位的困惑“运营就是门槛最低的岗位了吧”、“迷茫，做了4年运营不知道掌握了什么技能，感觉随时都可能被替代”、“运营的天花板在哪里”。恕我直言，问出这类问题的人，往往没有什么核心竞争力，有随时被替代的风险。

1是运营专业技能不强，和其他竞争者一比较就自然的败下阵来；2是横向拓展专业技能的意识不强，没有认知到市场对运营岗位需求在发生什么演变。以上问题都可以通过掌握一门产品技能解决，按过去做过100+产品项目的成熟经验，依据有效方法论，是可以做到短期提升产品技能的。惯例，按照思维导图展开。

①岗位职责的硬性需要

小张最近在找工作，他的困惑是有些运营岗位职责看起来像产品，分不清企业到底要招什么，和HR一细聊才知道是运营岗，只是需要具备某些产品技能。不知道这是不是很多运营同学都会碰到的情况，大多数，绝大多数企业的立场，是希望招到的人越全能越好，对应的是可以创造更多的价值，间接节省用人成本，所以当有部分企业对应聘者产生多技能要求的时候，其他企业也很快跟进，进而变成对应聘者的普遍要求。

要求运营具备产品技能，有更多维的考量，1是产运结合确实能创造更多的价值，如平台活动、裂变活动，都是非常成熟的协作模式，如果具备对方的能力，就能够减少出错的可能，提升价值产出效率；2是平台赋予运营对用户生命周期的管理链路不断在拉长，随着互联网成熟度的提高，单一的流量引入、拉新、留存的关注已经不满足产出的需要，需要具备更长链运营能力。以上，就不可避免的需要运营具备产品能力。

②能同时适应多个工作岗位

如上，小张的问题是普遍问题，但如果今天他具备了产品技能，那他的困扰就从“我怎么才能找到匹配我的工作”变成了“适合我的这几个工作，我应该选哪个”。是的，在岗位适配度上，就至少可以从运营拓展为运营、产品运营和产品经理，从市场需求出发，产生这种差异的主要原因是组织结构决定的，比如一家公司成立时的基因就是产研主导，有很扎实的产研基础，随着业务发展，由产品带来的纯增长遇到瓶颈，需要招募运营挖掘新的增长方式，这种情况下，一个只会纯运营的同学是比较难在这种组织里有很好发挥的，因为组织有已经相对固定的组织运行模式，完全不懂产品技能的话，很难获得产研的信任，更别说主导了。

从以上市场需要和个人能适配更多岗位的角度出发，我们可以初步理解为什么需要掌握产品技能，接下来将从实际运营工作的角度来分析。

①和产品、UI、项管、技术等沟通时信息容易对齐，提升效率

不管一个公司的流程规范与否，推进项目总是绕不开和上述角色的协作，和哪个角色沟通量级越大，越需要具备对方的专业知识，这样一描述，沟通最多自然有了产品经理这个答案。运营输出的是行动语言，而产品输出的是交互语言，搞清基本面的差异，也就能理解同一个项目，用运营语言和UI、技术沟通不易顺畅，沟通的本质是传递有效信息，运营在项目中往往处于上游方，整个项目周期需要大量的沟通，一般采用文字和对话的方式在项目中传递信息，光掌握运营语言是不够的。从反向的角度看，产品、UI、技术等多个角色掌握运营语言的难度和运营人员掌握交互语言的难度比较，前者更大，这也间接导致由运营掌握交互语言的必要性更大。

②协同方有效理解需求，专业度高

有效理解的判断标准是信息表达是否唯一，举个例子：运营侧关于活动参与的规则是：每人可以参与一次。转换为产品语言，就细化成是活动期间还是每天，以及从源头开始的判断+穷尽路径（用不了Visio，用xmind将就展示一下）

如果运营不具备对产品语言的理解，就没有办法在开始的时候就描述清楚自己的需求，这些细节对活动效果影响是至关重要的，以上述规则为例，假设平台有100万人，活动做10天，活动期间只能参与一次，对应的最大参与量是1000万，活动期间每人每天只能参与一次，对应的最大参与量是1亿，差了10倍。同时还有个隐性好处是，如果运营表现的专业度越高，越能赢得协同方的尊重，专业带来的影响是协作方也会加强专业度，同时减少因为运营不懂产生黑盒由产品自行决策的部分，最终都正向于这个项目。

③项目按策略1比1落地率的提升

成熟运营人都有一个自知就是：我的方案是造航空母舰，最终产出的是摩托车，这里并不是在影射产研能力，恰恰是常态，主要受几个因素影响：方案的不切实际、资源紧张、开发难度，项目永远都是投入产出的博弈，了解这个基本前提，就更容易接受实际结果。当运营具备产品技能后，就能大幅度降低方案的不切实际性，保证可落地性无限接近100%，举个大家当笑话的例子：老板向产品经理提了个需求，要求APP的主题颜色可以随着用户手机壳颜色改变而变化，因为过于荒谬而引起了互殴。

①产运博弈论

是时候好好说说运营和产品的关系了，首先没有约定俗成的双方一定要按照什么规则做事的规定，而是在实际的组织中，形成所谓的“规范”或“默契”的流程；其次就是由于双方的职能都在延展，耦合的部分逐渐变多，到底谁主导，谁说了算，变得动态了，其中既有组织流程演变导致的动态，也有因为产品、运营个人专业度、性格等个体差异导致的动态。以上都将导致产品和运营除了是合作关系外，还存在着“谁说了算”的博弈，这重要吗？这很重要，赢的一方拥有更大的话语权。

②谁主导谁更有价值

是的，在以产出为价值评估的组织中，总免不了争夺功勋的“厮杀”，谁是拔得头筹的、谁是不可或缺的，决定了更稀缺的奖励将会落在谁的头上，比如优秀个人、晋级名额，当有优先级排序时，主导者更容易获得，这是从稀缺角度来理解。另外还需要考虑组织结构的形式，是产研闭环还是分开，闭环模式下，对应一个大BOSS，更适用上述规则，非闭环的组织模式下，更体现在协作效率的提升上。

③隐形的手

这个部分，就是给高阶的同学看的了，在一个组织中，不是只有岗位职责划分在决定我们按照什么规范和边界做事，个人觉得仅占30%，另外的70%是由隐形的手决定的，这个隐形的手指的是，在协作中，你们达成了如何做事的默契，给对方感知到的做事边界是怎样的，最终形成了什么约定俗成的规范。

这么说有点抽象，举个很详实的例子：小张刚到二线A公司的Y部门，产研闭环，拥有5年工作经验的小张负责的是用户增长的工作，职责包括渠道拓展和效率提升，通过营销裂变的方式获取新客，业务快速发展，他是作为业务扩张新招进去的，在这之前，产品侧的一切都是产品老大说了算，所以一开始，小张是作为协同者推进项目，通过获得自己老板和产品老板的认可得以推进项目，这时候，小张在项目中只占30%的主导权，但小张毕竟专业，能拿结果，虽然方式上和之前产品老大惯用的不同，几次之后，逐渐在产研侧树立了自己的专业度和威信，半年后，小张在项目里已经能占70%以上的主导权了，不仅能调动产品，部分项目能直接调动研发，已经完全扭转了刚开始时由产品说了算的局面，而这一切，都是隐形的手在发挥作用，在潜移默化中演变，运营要能长期坚持，同时专业技能要过硬。

①活动项目类型

活动项目的一般特征是为了完成某个指标（常见GMV）的达成，而在节日、平台促销节点、规律频率发起的平台活动，产出的大多是可量化的效果，载体一般是自控的APP、小程序和H5，常见的有：双十一、618活动、网易云传播H5、平台周年庆活动、月度活动、日常活动等。对应的产品技能分前台和后端两大块，前台分活动规则和交互流程两大块；后端主要关注可配置项，包括展示文案的可配和活动参数的可配。前台和后端的最大差异是前台是向用户展示了什么，后端是运用了什么逻辑。弄清楚差异，方便后续分模块掌握。

②产品功能类型

产品功能向的技能，是更复杂的交互语言，一般掌握入门即可，即理解基础逻辑就够用了，它的特征是基于提升用户使用体验和优化产品提供核心服务来进行的优化，常见的较难归纳，举个例子：你进入淘宝，从搜索到点击物品到加购购物车到结算，像这类流程向的就是产品功能。

①判断掌握的必要性

虽然运营掌握产品技能是好事，但并不是掌握的越多越好，而是够用为佳，判断够用的标准更多的是参考外部的因素，而不是个人无前提的认为越多越好（职业发展规划为产品经理的除外）。

外部因素主要参考两个方向，一是公司内部，目前和产研协作情况的评估，比如项目由产品主导、项目日益复杂自己拥有的产品技能跟不上、公司未来一段时间战略方向的要求；二是市场行情，市场一般的需求是以结果为导向的，比如基于目标达成而需要运营具备什么技能，21年的市场行情和18年的相比，岗位职责中包含产品功能的部分至少上涨了50%，且一般市场需求反应大多情况下是先于运营意识的，所以需要对市场抱有观察，当某个趋势起来的时候，先人一步快速掌握，就有身价更高的可能。先判断完掌握进阶产品技能的必要性后再进入到学习积累阶段。

②进阶产品技能类型简述

还是按照活动项目和产品功能来划分进阶活动项目技能。

• 能把控同期2个以上并行活动或平台A级及其以上项目。
• 活动对应的用户状态≥5种的，比如活动期间用户有开始、结束、已参与未发起、已参与已发起但不达标、已参与已发起但活动时间截止等等。
• 能独立handle产运角色出一支H5。
• 熟悉倒排并能够根据活动时间协调UI、前端、后端、测试工作量的。
• 已经参与过（这里的标准是有独立负责的模块）10个以上活动型项目的。

以上并不是一个客观的标准，他们的共同标志是运营人员的角色从依附走向独立。

进阶产品功能技能：

• 能够理解并穷尽展示用户2个以上的交互流程（展示方式可以是文字描述、页面文案、交互图、prd等），比如：购物过程中用户选品和加购物车的全流程，包括主动搜索选品和算法推荐、选品排序受地域、用户标签、商家出价等，加购物城的增减、受选品库存影响而产生的状态、历史购物车物品排序等影响的以上所有状态。
• 能够产出产品原生性功能交互流程（展示方式同上），包含但不仅限于：弹窗逻辑、广告位配置逻辑、push/短信逻辑等。
• 其他涉及多状态/环节的产品向功能。

初级和进阶的掌握方式是相同的，这里作统一阐述

①建立基本认知

注意：市面上通用的产品入门是去做一个主流APP的产品分析方式并不适用，原因是主流APP背后的逻辑已经做的非常非常非常复杂了，再怎么穷尽分析都无法窥视全貌，只能得到一个大概的认知，投入时间和产出不成正比，而初期我们需要的是一个全局视野的建立，而不是盲人摸象。

产品需要具备的三大技能和不同级别的差异

三大技能：

一是需求分析

初级产品可以分析比较详细的业务需求，可以满足客户或用户要求来设计产品。

中级产品可以分析粗略需求甚至是一句话需求，通过与业务沟通来达成共识，并可以引导业务来设计产品。

高级产品可以通过分析，发现业务风险以及业务没有想到的提升点，并可以挖掘隐含的业务痛点来设计产品。

二是交互设计

包括交互模型、任务流程、信息架构、页面原型、交互说明等，是基本功的部分，初中高级产品都需要掌握，输出简单或复杂的需求。

三是项目管理

初级产品可以把控项目进度，对暴露出的风险或问题能及时解决。

中级产品可以把控项目的整个进程，规避各种风险，并保证项目可以按时上线。

高级产品可以在前期预判到后期的风险问题，在设计阶段就将这些问题有效解决；并可以预留时间解决各种突发问题，保证项目按时上线或者提前上线。

②实操、还是实操

实操是最重要的，如果没有这一步，上面就等于白看，产品技能是实践技能不是概念技能，是需要有实际运用才能掌握的，记住这一点，下面主要分两种情况分析如何实操。

一是公司有条件进行实操的，包括工作职责或可创造条件尝试，工作职责包含是最好的，积极主动争取多次的实操机会，可创造条件的包括产品分担不过来主动请缨、或者和boss说你的想法创造尝试的条件，不要在意需求的大小，而在于量级的积累，每一次都尽全力去完成，同时需要关注一个重点：尽可能画流程图或原型图，每次完成后都检查下，是否穷尽所有状态了。完成后多向产品前辈请教，并针对指导意见优化。

二是公司没有条件进行实操的，也能进行尝试，只是方式从在职场变成了私人时间，以及需求从实际需求变成了虚拟需求，举个例子，公司在推进的1234个需求，你可以找一个自己感兴趣的，最好是前辈已经产出PRD文档之类的，自己输出一遍，然后和相关的产品经营好关系，向他请教请教，基本沿用一的逻辑，也能达到积累的目的。

发现了吗？方法总比苦难多，最重要的还是个人得有想法和行动，这里再推荐几个实操会用得到的工具：画流程图的Visio，画原型图的Axure，画脑图的xmind，基本够用了。

①个人能力提升向

上面描述的部分内容有在说明个人能力提升的好处，就职场的长期发展来看，个人能力是最保值的一种，运营掌握产品技能，和掌握市场、数据分析这些比，是更难但收益更高的能力，它对应的是解决问题能力的提升，升职加薪是一件横向竞争的事情，即我需要优于市场上/同部门的其他人，你掌握了而别人没有掌握，优于他人的可能性就大。

②公司老板认可向

老板会在哪几种场景认可下属能力呢，不外乎两大类：1是帮老板解决了问题；2是用超出老板认知的知识或方式解决问题。

两者看起来很相似，但实操上差异是比较大的，举个例子：老板提出了一个A方案，目标是为了GMV的达成，让你去落地，需要解决跨部们协同和推进的问题，核心节点还是老板在把控，你在解决的是执行层面的问题；但第2种分两种情况，一种是在执行中提出更好的解决方案说服了老板去落地并达成，二是如何完成GMV由自己产出想法，且这个想法不在老板的射程范围之内，但重点是需要说服老板接受，做成了效果就会非常好，能在短期内获得老板的认可。

①行业未来发展

从近几年运营岗位需求由单一技能延展为1+N技能的趋势看，互联网未来的运营人才要求趋势一定会往全面具备的方向发展，一是由于互联网自身发展至高度成熟阶段，各赛道已趋存量饱和的状态，解决问题从“新行业/平台怎么找到合适的解决方案”演变成“同质化竞争严重的情况下，哪些解决方案更有效”，核心指标也从增量转移为存量；二是运营技能也在进阶，从“获得先发优势，先到先得”演变成“组合拳效果最大化”，从外部渠道获取转移为内部效果最大化。行业未来发展也一定会指导工作者具备对等的能力。

②先于市场需求

能力稀缺性是市场溢价的利器，在市场趋势将要或者刚发生的时候，是能力进阶的最恰当时机，仅仅出于通过工作赚到更多的钱，掌握产品技能也是合适的进阶方向，先于市场需求具备，就有溢价能力。同时一个成功的经验积累方法还可以复用到掌握其他技能上，以上，掌握产品技能是长期在运营方向发展的较优选择。

作者：列克星敦，公众号：列克星敦

本文由 @列克星敦 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Pexels，基于CC0协议