导语：数字化转型的大背景下，传统行业与新兴行业都开始抢夺软件研发的人才，“产品经理”这个岗位会不会有更大的发展空间？本文作者从不同维度出发，为我们拆解了产品经理岗位在不同领域都有哪些特点。

伴随着移动互联网兴起，“产品经理”也随之深入人心。火热的不仅是这个名词，它的概念也在不断外延，市面上更是有了“人人都是产品经理”的口号。

而当互联网步入下半场，行业不断被细分，产品经理的工作内容也越来越细。前段时间腾讯对职称进行了调整：“12 级（P4-1）以上才能称为「产品经理」，否则为产品策划或产品运营”。

比如产品经理按照工作职责划分，一般有“用户增长”、“增值营收”、“数据运营”、“策略设计”等，而一款成熟互联网产品的产品经理，需要对这些职责进行统筹、设计和管理。

按照腾讯新的职称规范，产品策划/运营承担起这些具体的执行职责，“产品经理”这个职称的祛魅和明确能更有效保证上述职责间分工合作上不会出现割裂。我们暂且不去纠结称呼上的变化，这件事本身象征着互联网企业组织形态越发规范，各角色职责划分和配合模式也更为成熟。

而随着这两年传统企业大范围地关注“数字化转型”，智能制造业如手机、电动车等行业也正在步入软件驱动硬件的阶段，未来中国社会各行各业会对软件研发、产品管理相关的人才进行更大范围的抢夺。

这对很多相关从业者或许都是个不小的机会，然而根据本人在银行、保险、消费品、汽车、手机等行业的相关从业经验来看，他们对“产品经理”这个岗位与互联网企业相比有着相当大的区别，所以本文会尝试从不同维度抽象地拆解“产品经理”这个岗位在不同领域的典型图鉴。

「“产品经理责任制”不应只是要求产品经理带领团队背负产品成败的压力，该模式工作的前提，一是具备走通业务所需要的各种能力，二是这些能力都围绕着产品进行协作。」

互联网管理模式里最广为人知的就是“产品经理责任制”，很多互联网人在大谈管理方法时也多认为这种明确的责任机制是保证团队战斗力的关键。

对，也不对。

对，是说范围圈定在标准的互联网企业时，其组织内所有的工作都需要基于互联网产品完成：落实一个业务需求需要产品功能的迭代，研发的生产结果也最终要表现在产品能力的进步，所以产品经理这个关键节点是在解决统筹所有角色协作的问题。

对于一个业务模式成立的产品来说，“产品经理责任制”确实是极为有效的。而业内普遍提倡的诸如“Design Thinking”这些方法论则能在这样的框架下帮助团队统一语言、更高效率地完成协作，也恰恰是被团队所需要并行之有效的。

说不对，是指当范围扩展到传统业务自我改造时，尤其是那种很早就进行信息化，但IT部门只是作为业务支撑部门的传统企业（如银行、保险、传统汽车等），“产品经理责任制”就不见得是最合适的模式。

因为在这种情况下，往往业务部门已经有着一套存量的成熟协作模式，而产品化就代表着首先要标准化这个协作过程，再让业务依托于产品而存在。

如果项目发起者是一位具备话语权的领域专家转型的产品经理，那么或许能克服许多阻力。但真实的场景是，很多由技术部门牵头做的产品化项目，因为缺少对业务的影响能力，已经失败在了这第一步，而该环境下孵化出的产品如果还要与存量业务并存，并走成独立的业务条线，可以说是千难万难。

归根结底，“产品经理责任制”不应只是要求产品经理带领团队背负产品成败的压力，该模式工作的前提，一是具备走通业务所需要的各种能力，二是这些能力都围绕着产品进行协作。

即使达成这个条件，传统企业还面临着一个更隐性的挑战：由于组织结构的差异，传统企业内产品经理承担了许多与互联网产品大相径庭的业务要求，更会受到很多来自企业文化的挑战，导致产品经理治理下职责（“用户增长”、“增值营收”、“数据运营”、“策略运营”）间无法互通。

也就引出了下一个话题：

「建设了强大的平台/中台，照抄了产品经理责任制，也从互联网企业挖了人才过来。缺少将平台能力对接到业务上的机制，即使有相应的人才，也很难发挥作用。」

以淘宝为例，这里对各类产品经理的配合方式做一个简化的模拟：

产品经理间配合方式的简化示意图

淘宝通过对买卖双方交易过程的免费吸引商家和用户流量。同时设计了多种功能帮助用户找到商品（比如模糊搜索、识图找物、直播间等），并用各种活动持续激活用户，这是“用户增长型”产品经理的主要工作。

当平台内商品数量和种类越来越多后，用户找到适合自己的产品所需耗费的时间就越长。于是“策略型产品经理”就需要对商品的搜索过程进行设计，给更优质的商品提高权重。

同时，商家希望自己的产品更容易被消费者看到，于是向需要淘宝购买流量、打广告、做营销，“增值营收型产品经理”就承担起这部分的需求和设计。

当功能因为各种原因可能对用户产生骚扰时，需要决策如何优化产品。这时“数据型产品经理”就要通过“埋点”、“A/B test”等方式对数据进行采集、分析和可视化，为决策提供数据支持。

最终，淘宝的总产品经理，站在企业战略的层次上决定产品调性，并协调开发资源，最终决定上述各类需求的优先级和上线时间。

可以发现，在描述不同产品经理的工作目标时，淘宝的核心业务、业务运作模式以及不同业务间的配合或影响关系，也都借由对该数字产品实现方式理解的过程而清晰地呈现出来，而所有产品经理负责部分的集成，就构成了互联网企业运作的核心，围绕这个核心再构建其他诸如市场、HR等支撑部门。

用类似的方式去理解传统企业，这个核心并不见得是产品，更多情况是“基于资产管理能力的经营方式”。

企业的支撑部门也是为“投资回报率”这样的经济概念而服务，IT部门被视作“成本中心”，业务部门则被视为营收中心（互联网企业里则是根据产品经理负责的产品能力的区分而被视作是成本还是营收）。

从这个角度看，或许也能理解为何上市公司里，评估传统企业会看重资产负债表、市盈率等数据，而互联网企业则更关注用户量等产品数据；传统企业内的变革多是基于立项结项的项目制、互联网公司则往往是基于团队的产品制。

受组织结构的影响，传统企业的产品经理往往也承担着更重的、独立的经营压力，即使在华为这样在软件研发上走得极为靠前的企业里，一款产品下多个产品经理切分方式也往往是单纯从业务上进行划分，而缺少诸如“用户增长”、“数据运营”、“策略设计”等产品能力上的划分。

这也导致其产品经理间也很少发生合作，更多的关注在自己负责的业务条线上。

无论是互联网企业还是传统企业，业务属性的责任都更受关注，这无可厚非。问题的关键在于，产品经理下的支撑职能（“用户增长”、“数据运营”、“策略设计”等）由谁承担以及如何承担？

支撑能力或者说共用能力，是所有大厂都在尝试解决的问题，对其描述也有一个很形象的说法就是“重复造轮子”，这几年大火的“中台”概念也是由此衍生，当团队规模成长到一定程度后，大家都想通过把相似能力抽象出来形成一个能力中心，分别赋能不同业务，这似乎是成本和管理上都最优的选择。

平台/中台 的目标

这里暂且不去评价现在各大厂商建设中台的成效，但成熟的互联网企业，每个团队都具备各类产品经理的角色，也正是这些人承担起将共用能力对接到业务的职责，这是其角色最重要的意义，也是为什么“产品经理是团队能力的抽象”（他们能匹配这样的职责也是因为有着伴随产品成长而训练出来的经验）。

反观传统企业，建设了强大的平台/中台，照抄了产品经理责任制，也从互联网企业挖了人才过来。缺少的恰恰是将平台能力对接到业务上的机制，即使有相应的人才，也很难发挥作用。

互联网大厂里“产品经理的协作和管理体系”就是在其企业上下文里的这套机制，也是其企业能力的抽象。当然，这并不代表“产品经理体系”就是标准答案，否则产品经理与研发间的关系不会那么复杂，更不会有对996习以为常的工作制。

也衷心希望许多如“中台产品化”的尝试在未来可以走出一条新的道路。

尤其是在数字化的浪潮下，AI、大数据等技术能够大规模可复制地为传统领域赋能，可能就需要诸如“算法产品经理”、“嵌入式产品经理”、“生产线产品经理”的出现，将这些技术能力对接到传统业务上。

所以抽象来看，产品经理的任务就是：

我的一位大学同学在快手做算法工程师，他说快手有许多数学相关专业的人来根据平台的数据设计数学公式，有思路后还要拉着经济学家、社会学家来讨论，一起敲定公式里的初始权重和常数甚至还要颠覆掉已有公式。

其实当前许多“策略型产品经理”做的，就是在通用的公式下，根据业务表现调整各数值的权重，AI算法现在在逐渐替代这步人为的过程。

那么如果未来AI需要被应用在各行各业上，是不是可以假设都需要这样的过程：

从这个角度看，字节跳动、快手这样以“AI”作为核心竞争力的公司，他们构建起的护城河似乎正是这些通用公式的积累、以及把该能力复用在不同业务上的体系。

现在互联网公司下的“产品经理体系”，本质就是类似的一套，明确各典型角色职责，以“产品经理”作为合作的中心节点，将市场需求（需求）与研发能力（生产）在数字产品上完成对接的协作体系，产品经理的任务，就是保证完成市场需求的业务能力，能被完整表达在产品上。

用这个角度思考产品经理的日常工作（“产品设计”、“需求管理”、“工作量分配”、“技术方案”、“迭代/发布计划”等），就能明白为什么每个产品经理似乎都有不一样的职责和工作内容，产品经理是通过补齐团队协作中的短板和阻碍来保证业务能力能够表达在产品上的。

如果再抽象一层，类比于传统业务：

类比于智能制造：

归根结底，数字化转型的大背景下，一套新的协作机制正需要被建立，并深植到产业内所有的合作环节里，这也正是数字能力的核心优势。而每当一个产业完成了这样的进步，就会有大量具备该产业特色的“产品经理”涌现，或许也是当前很多互联网人突破的契机。

下一节：中国的数字化转型：电商与新零售

本文由 @清水舍 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议