产品经理是企业协作框架的整合节点

产品经理是企业协作框架的整合节点

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

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

对，也不对。

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

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

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

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

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

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

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

也就引出了下一个话题：

二、产品经理是团队能力的抽象

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

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

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

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

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

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

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

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

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

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

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

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