关于产品，关于运营，关于全栈PM(上）思维导图

暖橙

2023-03-02

浏览量: 3

PM,

产品,

周推荐,

运营

导读：作为一个运营，在未来，你再也没有机会和产品撕逼，因为你们的界限会越来与越不清晰，或者说公司会在演变中形成项目制的小组，由一个人主导一个项目的开发流程，除了必要的技术，产品和运营将会整合。

树图思维导图提供《关于产品，关于运营，关于全栈PM(上）》在线思维导图免费制作，点击“编辑”按钮，可对《关于产品，关于运营，关于全栈PM(上）》进行在线思维导图编辑，本思维导图属于思维导图模板主题，文件编号是：6dd08d8d640932ef6c7e745efd659f91

思维导图大纲

导读：作为一个运营，在未来，你再也没有机会和产品撕逼，因为你们的界限会越来与越不清晰，或者说公司会在演变中形成项目制的小组，由一个人主导一个项目的开发流程，除了必要的技术，产品和运营将会整合。那么，这个演变的逻辑是什么，而我们在这个演变中需要什么样的能力呢？让我们看看知乎大神刘锤怎么说。

大家好，我是刘锤，09年毕业开始干互联网，到现在刚好7年。

这七年间，除了写代码以外，互联网行业几乎所有和产品/运营相关的工种都或多或少干过了，而且年限还几乎差不多，三年半产品和三年半运营，以至于经常被人笑话是样样稀松的万金油。

一年半以前我写过一篇总结运营的文章《高级运营和普通运营有哪些区别？》，很多朋友来找我聊。有聊困惑迷茫不解的，有聊职业发展的，有聊要不要转行的，也有聊具体工作问题的，我也都尽量能回复和探讨。

但我现在很愧疚，我之前说的东西，我现在认为已经不适合这个新的时代了。

所以我想说点不一样的东西，和我理解的产品和运营的发展趋势。

技术领域有个很有意思的新东西（也不算新，概念提出到现在好几年了）叫微服务，这微服务可不是什么微信做微商那种概念，而是一种在开发领域中技术架构层面的创新。我也不写代码，但本着对技术的关注和好玩，买了点书看了看，结果如获至宝。

具体的东西如果大家有兴趣可以稍微看看《微服务架构与设计》和《微服务设计》这两本书。

我对这东西的理解是这种开发架构，把以前的一揽子框架解耦的很彻底，每个应用被分解到有一个专门的服务与之对应。举个可能不太恰当的例子，就是我们看58同城这种传统分类信息网站，信息发布者和信息获取者，是同一套系统在支撑的。这是基于一种人人都可能同时是发布者和获取者得逻辑。而现在，优步滴滴等快车应用，就拆成了专门的司机端和乘客端。你说有没有司机同时是乘客呢？当然有，但为什么不合起来呢？因为拆开能更专注的提供司机和乘客分别的体验。

当然实际的技术开发中，这种解耦没58-滴滴这种对应那么简单，因为我们今天讨论产品和运营的问题，所以就不展开细说了。

我之所以要先引入这个概念，是我觉得可能在产品运营领域，下一个3-5年，有可能会出现和微服务极为相似的职业变化情况，即非开发工作的“彻底解耦”。

我给这个概念取了个名字，叫“产品运营的去专业化”。简称de-professionalism of pm。

首先，我们先来看看传统意义上，互联网行业的工作中，对产品和运营的划分。

为了好对应，我各写8个，多的就不写了。

基于这个分类，我们似乎很容易得出一个人到底的工作算是产品还是算是运营。比如你在公司的核心工作是投各种广告平台，或者你负责新浪微博/微信公众号的文章发布，或者挨个去拜访合作伙伴谈合作项目，那你毫无疑问算是一个100%的运营人员。再比如你每天的工作就是采集需求然后出原型图，每天和开发同学沟通业务逻辑，甚至你得自己去写sql跑数据，axure是你最常用的软件，现阶段你似乎也算是一个100%的产品人员。

但从我最近一年多的感觉来看，这种可被轻松定义的100%纯工作越来越少了。有很多和我交流的同学，上来第一句话都：“我也不知道我算产品还是算运营，总感觉什么都干”。我相信这个观念会萦绕着很多人的内心，让他们产生对个人技能发展和职业路径的困惑。

问题：我到底算产品还是算运营？

衍生问题1：我的职业发展方向到底是产品还是运营？衍生问题2：如果我是个产品/运营，那么那些运营/产品的事情我要不要做，要怎么做，应该学习什么来更好的做？衍生问题n….……

而且不光是一线执行的同学，更多的管理者也有这种困惑。到底怎么为某个看起来很卖力的小弟规划职业路径？这哥们再升职，应该放到什么地方给什么title？这些问题如果不解决好，就经常会发生人才流失的问题。

讲道理，三年前，这种困扰其实不多。但是，时代变了。

在互联网公司中，设计、开发、以及作为职能部门的财务、人力、法务等，都是有非常明确职业路径职位。假设我们谈论一个刚毕业的设计师，他的职业发展路径就是从一个小设计师慢慢变成一个行业的大师，当然在他发展的过程中，也不可避免的要有些拓展，平面，ui，广告，网页，app等等最后可能都要懂一些，但是假以时日，他一定会成为设计行业之中一个特别精通x和y的大师，并作为一个行业领袖存在着。

开发也是一样，一个程序员大约工作三年左右就会定性下来，他会有一个标签，例如”后端-java工程师“，他的技能发展方向可能就和”数据挖掘-python工程师”差别会越来越大，再往后四五年，他们就可能会是完全不同领域的不同专家，彼此之间切换很困难（当然其实也没那么大鸿沟，主要是他们这七年，踩过的坑差别会很大）。

人力财务法务就更不用说了，专员-经理-总监-更屌的公司的总监-更屌的公司的cxo这是一条非常明确的路径。

我们所谈论的这些，本质上是因为这些工作的“进深”（引用一个建筑上的词儿）很深，一个干了十年招聘的人力和刚毕业干了一年招聘的人力，差别可能是非常非常巨大的。在他们的职业发展路径当中，有足够的圈子内学习动力和机会，以及有明确的职级/薪水晋升路径。

但产品和运营不是。

互联网的这些工作里，是没有类似“平面设计”这种进深极深的工种的。换言之，没有那种能让你干一辈子干到老成为“xx大师”的工作。

假设某个叫小A的同学，今年刚毕业，到了一家公司做渠道投放，一开始这家公司只开了搜索引擎推广的账户，小A负责做SEM。小A做的不错，过了一两年老板晋升小A，又招了几个小弟分别负责搜索引擎，展示广告，新媒体广告等等，小A晋升为了渠道经理。

再下一步呢？

小A能做渠道经理做到自己60岁吗？

在传统的行业，这可以，尤其是那种传统意义上的渠道，各种经销商，定期开会喝酒，都是线下的生意，活到老学到老。

在互联网行业，有点难，因为搜索引擎一个智力正常，勤奋的人大约一年就已经是高手了，做内容运营大约也就8个月就到头了，采集各部门需求画原型图，不到半年就应该已经玩的滚瓜烂熟了。

然后呢？

很多和我交流的同学们的痛苦，就来自于“我现在干的事情已经很熟了但是限于环境我没法去拓展更多的东西了”，然后他们会问我下面干点啥，往什么方向拓展好。

对产品运营的工作来说，我们的职业路径不是纵向的。一个人写文案，写的再nb，不可能让他写一辈子，就算他专门去了以文案为生的公关公司，那他的职业路径也是成为那个公关公司的总监、副总、甚至自己当ceo开一家公关公司。

很多技术开发和设计领域的同学们，会纠结一个问题：我工作x年了，我要不要转管理，还是继续精研自己本身的职业方向？对产品运营来说不存在这个问题，因为单个工作的进深有限性，天然就是要转管理的。

以上废了这么多话，就是要先意识到“产品运营工作的进深有限性”。

那么我们再来看看上述的16个工作：

如果你工作了3年以上，你看看你曾经做过的事情能覆盖多少工作，是否你明明认为自己属于产品/运营，但是却干了很多运营/产品的活儿。自己出原型图来推push活动页开发的运营几乎和自己做市场调研的产品一样多。尤其是在规模较小的公司，你会跨界覆盖的更多。

以BAT为首的大公司致力于让人员专业化，比如调研就一个人专门负责调研，用户运营就一个人专门负责做一小波用户的维系。但这种专业化，天然就和岗位人的职业发展产生了矛盾。

从公司角度，希望人员稳定，产出稳定。一个工作一年的媒体监控人员总比刚来什么都不会的实习生要好。但也没法给这个工作在不晋升为管理者情况下更多的薪水了，因为残酷点说“这个工作就值这个钱”，为了公司管理利益，专业化是必然的结果。

从个人角度，希望有更好的职业发展，title和工资都能稳步上升。所以如果工作1-2年，如果想拿多点薪水，在纵向拓展没办法的情况下（公司不可能开高薪给一个只做媒体监控的人），只能横向拓展更多业务，而本公司内横向拓展，就面临着要成为管理者的问题（不然就会抢别人活儿了），而本公司内晋级毕竟有限，这时候就会跳槽去别的公司当经理了。

所以走上管理者岗位是产品运营人员天然的结果，无非管多大而已。

但公司又不可能让每个人都走上管理岗位，这就形成了天然的矛盾。

这个矛盾早已有之，但在近一两年尤甚。我看到的是在产品运营行业当中，大家平时日常使用的工具变得越来越便捷和易用。你可以用strinkly很快做一个酷炫的landingpage，也可以用mikecrm很快的组织一个用户调研的表单，用墨刀飞速攒出一个app原型，还有像epub360这种极快的h5页面制作工具。工具的易用性带来了工种门槛的降低和手段的多样化，这意味着产品和运营各个工种之间的边界会越来越模糊。

比如运营同学小A要做一个病毒传播的h5，研发说手头紧，产品说工作忙，设计说得排期。小A一怒之下自己用一大堆组合套件和现成框架自己做了一个，跑起来以后拿到数据证明这条路是可以的，于是说服老板投入更多资源做个好东西。

小A不依赖于任何人，某种程度上说抢了很多人的饭碗。

很多事情都变得可以“自己动手丰衣足食”起来，对那些能力强，不断渴求学习的人来说，是一件莫大的好事。

如果你是技术人员或者有技术背景，你会很容易想到一个概念叫“全栈工程师”。没错，我要说的就是这个。所以这里我要把”去专业化的产品运营“叫做”全栈pm“（抄一下概念）。

pm取百度的product & marketing之意，而不是产品经理那个product manager之意。

基于全栈pm，在业务构架上就有了更多可能，我们刚才讨论的公司需求和个人职业路径的矛盾可能也会得到解决。

新型的公司构架，很可能不会像现在这样，有一个产品部门，由一个产品总监lead，再来一个运营总监lead的运营部门，两边势如水火，经常扯皮和推诿。而是像微服务在架构层面上的改动那样，把公司业务打碎，粒度划分到比现在可能更细，每个细粒度业务由一个全栈pm负责来推进。如果遇到专业上的不熟悉，可以全栈pm之间互相学习和琢磨，继而去探索。这语言上比较难以描述，我画几个图大家感受下。

这是传统的产品运营金字塔架构，这个独立产品可大可小，如果大，那最下面可能就是不同的部门，如果小，那就一个人会干很多个事情，出现身兼多职的情况。

传统的金字塔架构问题是，当产品不可避免的发展大的时候，就会从一个人身兼多职，慢慢变成一个需要专业化的金字塔。这里面的变数在于：1，最开始这个人是否足以当一个合格的管理者；2、新招的人，是否在某个具体的工作上能超过一开始的人？

所以我猜测未来有可能是这样的（事实上很多公司已经在这么用了，包括bat某些独立的产品）。

这里把产品独立拆成若干业务线，每个业务线有几名什么都做的全栈pm来统一进行产品和运营工作，由一个较为资深的pm带领。具体拆的细分粒度看业务诉求了。然后每个人都有独立产品设计、对接研发、推向市场，接触用户的权限。不再区分到底是产品还是运营工作，而只是就事论事的看业务线本身所需要的。

这么做优势我认为主要有这么几个：

1、人力调配灵活：随时可以将不同业务线的全栈pm们调换或者借调，只不过每个人的技能侧重可能不一样。但这个侧重和传统架构里的“专业化”是不一样的，两个三年的全栈pm可能主要技能都在80分以上，但可能有几个技能在90或者100分，这也是合理和应该被鼓励的。

2、更有利于走上管理岗位，和更好的职业发展：在这样的架构中，每个全栈pm未来都不可避免的要成为管理者，而因为他们技能的多样性，导致接手不同产品的不同业务线非常快，而且因为业务线的细化，在大行业来讲是更容易重合的。而且如果公司里没有那么多管理的坑，这样晋升的方式就是资深的产品运营负责人，某种程度上，独立主导一个产品的产生和发展，这事情进深就已经足够大了。

当然也有缺点，比如你至少需要一个资深一点的全栈pm来作为这个业务线的负责人（相对于业务线的粒度来说），这类人目前在市面上是少的。但我觉得三五年之后，随着工具的进一步便捷和手段的进一步多样化，很多东西学起来是非常非常快的，全栈pm也会越来越多。还有缺点就是个别确实需要专业化的工种是不太适合作为全栈的，不过这也简单，抽出来作为独立的support就可以了。

当然，这只是一个泛化的模型，具体讨论起来细节有很多。

举一个例子：

ABC公司是一个刚刚拿到B轮融资的公司，公司的主要产品是一个赌球app（既然是假想咱们就讨论些非法的东西）。公司的app主要有3个大独立业务线：足球信息资讯，赌球竞猜，赌迷社区。

传统的架构（尤其是公司小的时候），很可能是有一个产品部，然后产品部里面有几个产品经理，分别负责这些业务功能的产品设计和跟进，再有一个运营部，有些人负责搜集足球信息，请一些资深足彩写手来写文章，再有些人负责监控每日竞猜数据和赔率支持，再有些人负责在赌迷社区里活跃，找一些ugc，搞线下社交等等。

我们不要这样搞。

我们先按用户的属性，分成三个组，五大联赛组，中超组和其他组。

每个小组的全栈pm负责各自用户可能会做的所有事情。比如五大联赛组的pm要从产品的设计，用户的运营，引导充值和下注以及活跃后续的讨论等等。因为用户虽然是割裂的（关心英超的人可能根本不会看中超），但用户行为不是割裂的，一个赌迷可能先看看资讯，再去下个注，再去球迷社区看看帖子等等。

而一旦有欧洲杯这样的大事情，就可以三个组里分别抽调一波人，来做一个专门叫欧洲杯的项目，这个项目里面也都是全栈pm，从欧洲杯产品的设计开发上线一直到推广运营赔率计算和球迷活动组织，一并进行。

这思路其实一点都不新鲜，项目化做事古已有之，但全栈pm的意义在于，把所有日常的事情都当成是特殊的一个项目（就像微服务那样），把项目常态化。

那么这里又会出现一个问题，业务组分到多细是合理的呢？我的倾向是，按用户来分，看用户重叠程度来确定。比如如果有必要，把五大联赛具体分为英超和非英超（毕竟英超球迷多商业化好赌金多），用两个小组去跟进。

而且为了保证产品整体的统一性（比如你不能让英超和中超用差别太大的UI界面吧颜色虽然可以换换），需要各个组例行进行标准的统一和规范的确定（有点像技术开发里面一个公司对于代码规范的要求，这是有必要的）

谈到这里，可能你会觉得有点理想化和纸上谈兵，但事实上是很多公司虽然没有这么说和这么要求，但其实已经在这么做了。尤其是以bat为首的公司，你但凡看他们那些近一年内推出来的新业务，几乎初期全是各个其他老部门抽调出来的全栈pm。随着业务顺利发展，会招一些工作经验不足的毕业生实习生来做一些基础的细分工作，但一段时间之后，很多人都具备了从需求采集画原型图跟进开发到产品上线以后的推广运营功能迭代等所有的技能能力。

用他们自己的话来说，这叫”被逼出来的“。

我们总会被逼无奈的去学一些东西，那么如果学习成本越来越低，不如主动去学习，职业进深不够深，那么就往更广的方向去走走。

因为产品运营工作不同于设计/开发等进深比较深的职业特殊性，全栈pm将是未来互联网对产品运营人才的大趋势。所以不要把自己局限在产品还是运营这种问题了，对于某一波特定的用户来说，你既是产品，又是运营。你所要做的是让你的用户觉得你的东西有价值，持续的用，围绕这个问题，到底是功能改进，还是活动的策划，已经不重要了。

总会有一些工作是那些连“是不是要招个专门的人来干这个”都不确定的类型，这时候就是全栈pm的价值了，因为如果某些细分的东西你不懂或者很快学习到了解的程度，连找外包你都可能会被坑。

当然了，在产品运营某个细分领域上一定程度的专业积累是很有必要的，所以2年工作经验内的新产品运营人，还是致力于积累2-3个核心技能，从实践到方法论都有了基础的保证，再去扩展其他技能点吧。

所以说到最后，我给全栈pm下一个定义：

互联网相关工作中，能利用多种技能和工具，在快速学习能力的基础上，可以独立完成产品的规划设计，开发上线，运营推广全流程工作的岗位。

成为全栈pm的人，工作不是为了成为某个资深的专家工匠手艺人，而是为了“做成一件事”。为了”做成一件事“，会去在学习成本可控的情况下，学习所有相关的技能。如果你致力于成为一个专家/工匠/手艺人，互联网行业的产品运营工作真的可能不是你好的选择。

每个公司的创始人，不就是第一个全栈pm么？

Control of Gene Expression思维导图