刘锤：我也不写代码，但不是什么

雅思2024-04-12 16:12:21佚名

大家好，我叫刘翠。我2009年毕业，开始从事互联网工作。到现在已经整整7年了。

这七年里，除了写代码之外，我几乎干过互联网行业所有与产品/运营相关的工作，而且年数也几乎一样，三年半做产品三年半的操作，让我经常被称为笑话是万能的灵丹妙药。

一年半前我写了一篇总结运营的文章，很多朋友来找我交流。有的谈的是迷茫与迷茫，有的谈的是职业发展，有的谈的是是否转行，还有的谈的是具体的工作问题。我尽力回复并讨论它们。

但我现在感到非常内疚。我以前所说的，现在看来已经不再适合这个新时代了。

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

———————————————————————————————————

技术领域有一个非常有趣的新事物（并不新鲜，这个概念已经提出好几年了）叫做微服务。这个微服务并不是像微信做微信业务那样的一个概念，而是一个开发领域的技术。架构层面的创新。我也不写代码，但出于对技术的关心和乐趣，我买了一些书看了一下，结果如获至宝。

如果您对具体的事情感兴趣，可以看看这篇文章//15/0527/12/.shtml。

或者《微服务架构与设计》这本书：

///?from=标签

和“微服务设计”：

///

我对这个东西的理解是，这个开发架构完全解耦了之前封装的框架，每个应用被分解为与之对应的专用服务。举个可能不太恰当的例子，我们看一下58同城这样的传统分类信息网站。信息发布者和信息获取者由同一系统支持。这是基于每个人都可能同时是发布者和收单者的逻辑。现在，优步和滴滴等快递应用程序已分为专用的司机和乘客应用程序。你认为司机同时也是乘客吗？当然有，但为什么不把它们结合起来呢？因为拆开它可以为驾驶员和乘客提供更有针对性的体验。

当然，在实际技术开发中，这种解耦并不像58-滴滴对应那么简单。因为我们今天讨论的是产品和运营问题，所以不再赘述。

之所以要先介绍这个概念，是因为我认为在产品运营领域，未来3-5年，可能会出现和微服务非常类似的职业转变，也就是与微服务的“彻底解耦”。非开发工作。

我把这个概念命名为“产品运营去专业化”。缩写为 de-of pm。

首先我们看一下互联网行业传统的产品和运营划分。

产品：

运营：

为了方便对应，我就各写8个，就不多写了。

根据这种分类，我们似乎很容易得出一个人的工作是产品还是操作的结论。比如，如果你在公司的核心工作是投资各种广告平台，或者你负责在新浪微博/微信公众号上发布文章，或者一一拜访合作伙伴商讨合作项目，那么你无疑是100 ％操作员。。例如，你每天的工作是收集需求并制作原型，每天与其他开发人员交流业务逻辑，甚至你必须自己编写 SQL 来运行数据。 Axure是你最常用的软件，现阶段你似乎100%合格。产品人。

但从我这一年多来的感受来看，这种可以轻易定义的100%纯粹的作品越来越少了。很多和我交流的同学说的第一句话就是：“我不知道我到底算产品还是运营，总感觉我什么都能做。” 我相信这个观念会萦绕在很多人的心中，让他们对个人技能发展和职业道路感到困惑。

问：我应该把它算作产品还是操作？

衍生问题1：我的职业发展方向是产品还是运营？

衍生问题2：如果我是一个产品/运营，那么我应该做那些运营/产品的事情吗？我应该怎么做，我应该学什么才能做得更好？

导数问题...

...

而不仅仅是一线执行力的学员，更多的管理者也有这样的困惑。对于一个看起来很努力的年轻人，你到底是如何规划职业道路的呢？如果这家伙再升职的话，他应该被安置在哪里，应该被授予什么头衔？如果这些问题不解决，人才流失往往会发生。

说实话，三年前，这种麻烦还不算多。然而，时代已经变了。

在互联网公司，设计、开发，还有财务、人力资源、法务等作为职能部门，都有非常清晰的职业路径职位。假设我们正在谈论一位刚毕业的设计师。他的职业发展道路是从一个小设计师慢慢转型为行业大师。当然，他在发展的过程中，难免会有一些拓展，比如平面设计、UI等等，最终他可能还要了解一点广告、网页、app等。但假以时日，他一定会成为设计界特别精通x和y的高手，以行业领袖的身份存在。

发展也是如此。程序员工作三年左右就可以取得资格。他会有一个标签，比如“后端-java工程师”，他的技能发展方向可能和“数据挖掘-工程师”越来越不一样。差异越大，未来四五年，他们可能是完全不同领域的不同专家，而且他们之间的转换会很困难（当然，其实差距并没有那么大，主要是因为陷阱）他们在过去七年里走过了。非常大）。

更不用说人力财务和法律事务，专家-经理-总监-更好公司的董事-更好公司的CXO。这是一条非常清晰的道路。

我们所说的本质上是因为这些工作的“深度”（引用一个架构术语）非常深。一个已经招聘了十年的人力和一个刚毕业已经招聘了一年的人力之间的差别可能是非常非常巨大的。在他们的职业发展道路上，有足够的圈内学习动力和机会，以及清晰的职级/薪资晋升路径。

但产品和运营则不然。

网络上的工作中，没有“平面设计”这样有深度的工种。也就是说，没有任何工作可以让你工作一辈子，成为“xx高手”。

假设一位名叫小A的同学今年刚毕业，在一家公司做渠道广告。一开始，公司只开设搜索引擎推广账号，小A负责SEM。小A表现不错。一两年后，老板提拔了小A，又聘请了几个弟弟负责搜索引擎、展示广告、新媒体广告等，小A升任渠道经理。

下一步是什么？

小A到60岁还能当渠道经理吗？

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

在互联网行业，有点困难，因为一个智力正常，努力工作的人，要成为搜索引擎高手，需要一年左右的时间。做内容运营只需要8个月左右。收集各部门的需求并绘制原型，只用了不到半年的时间。现在你应该已经非常熟悉这个游戏了。

然后呢？

与我交流的很多学生的痛苦来自于“我已经很熟悉自己现在所做的事情，但由于环境而无法扩展”。然后他们会问我接下来要做什么，要去哪里。方向拓展得很好。

对于产品运营工作，我们的职业道路不是垂直的。一个人的文案写得再好，也不可能写一辈子。即使他去了一家以文案为生的公关公司，他的职业道路也是成为该公关公司的董事、副总裁，甚至自己成为首席执行官。开一家公关公司。

很多技术开发设计领域的同学都会纠结一个问题：我工作了x年了，是应该转行管理，还是应该继续研究自己的职业方向？

对于产品运营来说不存在这个问题，因为单个工作的深度有限，自然需要转入管理。

说了这么多，我们首先要认识到“产品运营工作的深度是有限的”。

那么我们来看看上面提到的16个职位

【

】

如果你工作了3年以上，看看你做了多少工作可以覆盖它。你是否明确认为自己属于产品/运营，但你却做了很多运营/产品的工作。制作原型来促进推送事件页面开发所需的操作几乎与对产品进行市场调查一样多。特别是在较小的公司中，您的跨境业务覆盖范围更大。

以BAT为首的大公司致力于人员专业化。比如一个人负责研究，一个人负责用户运营中维护一小群用户。然而，这种专业化自然与该职位人员的职业发展相冲突。

从公司角度来说，我们希望人员稳定，产量稳定。一个工作了一年的媒体监察员，比一个刚来、什么都不懂的实习生要好。但不晋升经理就没有办法给这份工作加薪，因为说句狠话，“这份工作值钱”。为了公司管理的利益，专业化是必然的结果。

从个人角度来说，我希望职业生涯有更好的发展，职称和薪资都稳步上升。所以如果你工作了1-2年，如果你想拿更多的薪水，又没有办法垂直拓展（公司不可能给一个只做媒体监控的人开高薪），你可以只能横向拓展更多的业务，而我们公司如果横向拓展的话，你就会面临成为经理的问题（不然就抢了别人的饭碗），而公司内部晋升毕竟有限，所以你就会跳槽、跳槽。成为其他公司的经理。

所以pm是什么意思，担任管理职务是产品运营人员的自然结果，无非就是规模有多大。

但公司不可能把所有人都放到管理岗位上，这就产生了天然的矛盾。

这种矛盾由来已久，但近一两年更加严重。我看到的是，在产品运营行业，大家日常使用的工具正在变得越来越方便、好用。你可以用它快速制作一个很酷的页面，也可以用它快速整理一份用户研究表单，用Ink Knife快速创建app原型，还有像这样极快的h5页面创建工具。工具的易用性降低了工作类型的门槛，方法多样化，这意味着产品和运营类型之间的界限将变得越来越模糊。

比如运营同学小A想做一个病毒式的h5。研发团队说资金紧张，产品说工作繁忙，设计需要排期。一气之下，小A用大量的组合套件和现成的框架，自己做了一个。运行之后，他得到了数据，证明这条路是可行的，于是他说服老板投入更多的资源，做出一件好事。

小A不依赖任何人，某种程度上，他抢走了很多人的工作。

很多事情都变得可以“自己丰衣足食”，这对于有能力、不断好学的人来说，是一件天大的好事。

如果你是一名技术人员或者有技术背景，你很容易就会想到一个概念，叫做“全栈工程师”。是的，这就是我所说的。所以这里我将“去专业化的产品运营”称为“全栈PM”（复制概念）。

PM取的是百度&的意思，不是产品经理的意思。

基于全栈PM，业务架构有了更多的可能性，我们刚才讨论的公司需求和个人职业道路之间的矛盾也可能得到解决。

新的公司结构可能不会像现在这样。有一个产品部门，由产品总监领导，还有一个运营部门，由运营总监领导。双方局势紧张，经常发生争执、推卸责任。相反，就像微服务在架构层面的变化一样，公司的业务被分解成碎片，粒度被划分为比现在更细的粒度。每一个细粒度的业务都是由全栈PM来推动的。如果你对专业的东西不熟悉，可以在全栈PM中互相学习、思考，然后探索。

这个很难用语言描述，所以我画几张图给大家感受一下。

这是传统的产品运营金字塔结构。这个独立的产品可大可小。如果规模大的话，底层可能有不同的部门。如果规模很小，那么一个人就会做很多事情，身兼多职。

传统金字塔结构的问题在于，当产品不可避免地发展起来时，就会从一个人身兼多职pm是什么意思，变成需要专业化的金字塔。这里的变量是： 1、这个人一开始就足够优秀，可以成为一名合格的管理者吗？ 2. 新招聘的人在某项特定工作上能比最初的人做得更好吗？

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

在这里，产品被独立地划分为多个业务线。每个业务线都有几位全栈PM，他们的职责是统一产品和运营工作，并由一位更资深的PM领导。具体细分的粒度取决于业务需求。然后大家都有自主的产品设计、对接研发、市场导入、获取用户。不再区分是产品还是运营工作，只看业务线本身需要什么。

我认为这样做的主要优点有以下几点：

1、灵活的人力调配：来自不同业务线的全栈PM可以随时互换或借调，但每个人的技能侧重点可能不同。但这种侧重点又不同于传统建筑中的“专业化”。两个三年经验的全栈PM可能主要技能在80分以上，但也可能有少数技能在90分、100分。这也是合情合理的。应该鼓励。

2、更有利于进入管理岗位，更好的职业发展：在这样的架构下，每一位全栈PM未来必然会成为管理者，而且由于技能的多样性，他们会接手不同的产品不同的业务线发展速度非常快，而且由于业务线的细化，在大行业中更容易出现重叠。而如果公司没有那么多管理坑的话，晋升的途径就是成为高级产品运营负责人。从某种程度上来说，独立主导一款产品的创造和开发已经是一件足够大的事情了。

当然，也有缺点。比如你至少需要一个更高级的全栈PM来担任这个业务线的负责人（相对于业务线的粒度）。目前市场上这样的人很少。但我觉得三五年后，随着工具的进一步便利，方法的进一步多样化，很多东西会学得非常非常快，全栈PM也会越来越多。还有一个缺点是，有些确实需要专业化的工作类型并不适合全栈，不过这个也简单，拉出来单独用就可以了。

当然，这只是一个概括的模型，还有很多细节需要讨论。

举个例子：

ABC公司是一家刚刚获得B轮融资的公司。该公司的主要产品是一款赌博应用程序（因为这是假设的，所以让我们讨论一些非法的事情）。该公司的App主要拥有三个独立的业务线：足球资讯、投注投注、投注球迷社区。

传统的架构（尤其是公司规模较小的时候）很可能有一个产品部门，然后产品部门里有几个产品经理，负责产品的设计和这些业务功能的跟进，还有还有一个运营部门，有的人负责收集足球资讯，邀请一些资深的足球作家撰写文章，有的人负责监控日常投注数据和赔率支持，有的人负责活跃在赌迷社区，寻找一些UGC、从事线下社交等。

我们不要这样做。

我们首先根据用户属性将用户分为三组：五大联赛组、中超组和其他组。

每个组的全栈 PM 负责各自用户可能执行的所有操作。比如，五大联赛集团的PM应该重点关注产品设计、用户运营、引导充值和投注、积极跟进讨论等。虽然用户比较碎片化（关心英超的人可能不看英超）中超联赛根本没有），用户行为并不碎片化。赌迷可能会先阅读信息，然后下注，然后去粉丝社区看帖子等。

一旦有像欧洲杯这样的大型赛事，可以从三个小组中各分配一批人来开展一个专门称为欧洲杯的项目。这个项目还包括全栈PM，从欧洲杯产品的设计和开发开始。一路到推广、运营、赔率计算和粉丝活动组织都是同时进行的。

这个想法其实一点也不新鲜。基于项目的工作已经存在很长时间了，但是全栈PM的意义在于将日常的所有事情都视为一个特殊的项目（就像微服务一样）并将项目常态化。

那么这里又会出现一个问题：业务组件详细到什么程度？我的倾向是按用户划分，确定用户重叠程度。比如，如果有必要的话，将五大联赛分为英超和非英超（毕竟英超球迷商业化程度更高，赌博性更强），用两组来跟进。

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

说到这里，你可能会觉得有点理想化、理论化，但事实上，很多企业虽然没有这么说，也没有要求这一点，但他们实际上正在这样做。尤其是以BAT为首的公司，如果看他们近一年来推出的新业务，几乎都是初期从其他老部门调来的全栈PM。随着业务发展顺利，会招募一些工作经验不足的应届毕业生实习生，做一些基础的细分工作。但经过一段时间后，很多人已经具备了从需求收集、绘制原型、后续开发、产品上市后推广的能力。运营功能迭代等所有技能和能力。

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

我们总是会无奈地被迫去学一些东西，所以如果学习的成本越来越低，不如主动去学，事业还不够深，那就往更广的方向走。

由于产品运营工作不同于设计/开发等更深入的专业专业，因此全栈PM将是未来互联网产品运营人才的一大趋势。所以不要把自己局限于产品或运营的问题。对于特定的一波用户来说，你既是产品，又是运营。你要做的就是让你的用户觉得你的东西有价值并继续使用它。对于这个问题，无论是功能改进还是活动策划都已经不再重要。

总会有一些工作是你甚至不确定是否需要聘请专门的人来完成的。这就是全栈PM的价值，因为如果你对一些细分的东西不理解或者很困惑，那么学得足够快就能理解它，即使找外包也可能会被骗。

当然，在产品运营的某个细分领域有一定的专业积累是必要的，因此工作经验不足2年的新产品运营者仍然致力于积累2-3项核心技能，从实践到方法论。现在基础知识已经保证了，我们来拓展一下其他技能点。

所以最后我会定义全栈PM：

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

成为全栈PM，你的工作不是成为高级专家工匠，而是“做好一件事”。为了“把事情做好”，在学习成本可控的情况下，我会学习所有相关的技能。如果你致力于成为一名专家/工匠/工匠，那么互联网行业的产品运营工作对你来说可能并不是一个好的选择。

每个公司的创始人不都是第一个全栈PM吗？

—————————————————

在后续章节中，我将与大家探讨核心技能的具体学习路径、切入点和工作计划，以及基于全栈PM思维的企业业务架构转型等一系列问题。

第二章学习路径：/p/