一、产品经理的由来和代表人物

这里先讲讲产品经理的由来。让更多的人知道互联网行业有产品经理这么个岗位，还得靠出自于阿里巴巴的苏杰老师，一本广为流传，可以说入门产品经理人手一本的《人人都是产品经理》。

2010年开始，产品经理开始与程序员并列作为一个”工种”逐渐在互联网行业被看见，并扮演越来越重要的角色，甚至能决定一个项目的成败，这是一个为”用户体验”而生的”新工种”。

但产品经理除了是一个职业以外，它同样代表了一种新的思维方式，打破了一些人们看待事物的传统视角和思维逻辑。

可以说，它就像”星巴克代表了一种新的生活方式”一样，代表了一种”新的思维方式”。

要说产品经理的顶流代表人物，自然在全球范围内，非乔布斯莫属了。而放眼国内，那或许就是神仙打架，往远了说，”微信之父”张晓龙，往近了看，靠小米汽车再次爆火一把的”雷布斯”雷军，都有着大批的忠实拥擘。很难票选出，到底谁才是最厉害的那个。但毋庸置疑，都创造了非凡的、影响直至改变了人们生活方式的产品。

二、优秀产品经理画像

像我们这样的普通人，作为千千万万产品经理中的一员，不求做到如雷总一般的顶流，但也希望能够成长为一名优秀的产品经理，这点志向还是可以有的。

那么，怎么才算一个优秀的产品经理呢？曾有位不愿透露姓名的业界人士说过：好的产品经理，大概率是一个六边形战士。怎么个六边形法？让我们来看：

确实，感觉这六个角都要拉满是挺难的。颇有一种”进可骑马打天下(做好战略和策略规划)”、”退可洗手做羹汤(为团队提供情绪价值，形成正向驱动)”的感觉。

但在实际工作中，依业务性质、工作方向及岗位特点等因素，体现在对不同维度的能力高低有所侧重。让我们来看看产品经理可以做哪些细分？每种类型的六边形图又存在哪些异同？

• 用户产品经理：即 通常说的C端产品经理，典型产品如微信、微博、抖音等，这类产品经理最重要的能力是”用户洞察”，需要对什么会带给用户好的体验，扩大用户量级，增强产品黏性有敏锐的嗅觉、洞察和创造力。同时，战略规划，合时宜的版本迭代也至关重要。
• 交付型业务产品经理：多是指以项目驱动，偏交付方向的B端产品经理，日常工作内容有一大块可能都是在支持投标工作、驻场客户业务调研、解决方案编写等工作，这类产品经理工作成果的好坏跟项目成败是绑定的，这就要求具备较高的方案设计和技术理解能力。
• 平台型业务产品经理：多是指以产品驱动，偏平台方向的B端产品经理，如腾讯云平台、商用化舆情分析系统、商用BI工具等SaaS服务类产品，这类产品要成功，本身的产品力和切中目标群体/场景解决问题的能力尤为重要，因此对于所服务业务场景的技术理解或背景知识、战略规划、方案设计及数据分析等都有较高的要求，属于综合强且多单科强的类型。
• 数据产品经理：这个方向比较垂直，主要指的是基于大数据类业务的产品经理，具体业务方向既包括对外商用化的数据应用类产品，也包括数字化转型中，服务于对内业务管理、增效、赋能的数据体系类产品。这里面可做的项目包括数据治理、主数据建设、数据指标体系搭建、数据服务平台、以用户画像为代表的数据赋能应用等常见范畴。这自然就要求数据分析、方案设计和技术理解等维度具备较强能力。

综上所述，无论属于哪一类产品经理，都有一个共同的重要维度——沟通协调，因为产品经理是一个跨多个组织或执行单位的角色，需要为驱动最终的项目成功推动形成无数个小的共识，因此”沟通协调”是一个非常底层通用的能力维度。

三、产品之道

在讲”产品之道”前，我们先来界定一下什么是”道”。

在道家看来，”道”即是 世间万物运行的规律。

那么”产品之道”又是什么呢？

我认为是：产品工作或者说产品思维中安身立命的底层逻辑、精神内核和关联思考习惯。

那么，具体是些什么呢？请往下看。

首先，产品经理需要搞清楚自己在团队和项目中的”生态位”。一言以蔽之，那就是，必须通过合作来输出价值，无法独立产出价值。类似于古时候的军师，军师本身是无法冲锋陷阵，攻城略地从而获取战果的，他必须依靠将军和士兵，为整个军队输出策略价值，从而获得胜利。

因此，我们可以得出一个结论——产品的价值要通过帮助团队和项目成功来体现。

由此，我们应该知道，如果用人脑来类比产品经理的精神内核，那么：

左脑，是利他。

右脑，是赋能。

底层逻辑主要有两个。一是Owner意识，二是做一个动态的完美主义者。如何理解这两句话？下面展开讲讲。

1）Owner意识

首先是Owner意识，产品经理参与一个项目，不管是不是第一责任人，想要在做好项目的同时，提升自己的产品力，那么都需要有Owner意识。这里所说的Owner意识不是一句空话，有这样三个内涵：

（1）客户第一

其实这与上一小节所提到的“利他”是一脉相承的，正因为利他，所以才把客户放在第一的位置上，通过为客户提供价值来成就客户，帮助客户(更)成功。首先，我们要知道客户是谁，有些toB、toG的产品，客户是不等于用户的，客户是具有拍板购买这个产品的能力的人，通常是企业主、单位领导等，而用户则往往是他们所管理的员工/下属。如何击中客户的核心诉求，让客户从认知到认可产品价值或许是比从操作体验上取悦用户更重要的事。另外，需要想清楚的是，当发生利益冲突的时候，比如客户与平台产生利益冲突时，客户与第三方合作公司产生利益冲突时，如何对这些冲突和背后成因，认知到位，以最省力、利益最大化的方式解决冲突，也是值得认真思考，从实践中获得成长的一个好问题。

（2）产品价值观

产品价值观听起来是一个很虚的概念，但实质上则是决定了我们怎么去操盘一个产品项目的“基本盘”。我认为的产品价值观包含三个内容：

• 动态框架：产品经理必须搭建并随时更新自己的知识库与技能体系，认知框架是动态变化的，能保证快速接纳和理解新生事物，并与既有知识形成关联和理解，从而促进洞察和新知。
• 抽象解耦：在软件世界里，很多东西需要向上抽象一层，实现统一和复用；也有很多东西需要模块化，最后根据场景进行不同成熟模块的组合与组装，提高开发效率，减少重复工作，便于迭代维护。你可能听过的“高内聚、低耦合”就是这个意思。
• 双轮驱动：产品不能完全被市场和销售牵着鼻子走，那会丧失创新力和差异化创造性竞争力，沦为“工具人型”产品经理，需要构建自己的产品力作为竞争驱动力；但同时，又不能只服务于自身产品力，那样容易陷入“自嗨”和“赔本赚吆喝”的尴尬境地，要适度迎合市场，发展销售力，两条腿走路，让“产品力”和“销售力”相辅相成地作为可驱动项目与团队向前的“双轮”。

（3）担责意识

如今从超级大厂到创业型小公司，似乎都很喜欢搞“OKR”。当然不否认在管理上，“OKR”有它的优势和先进性在。但同时，“OKR”也容易培养一种“(自我)利益至上”的思维方式和行事风格，即使我知道将产品往某个方向推是一种好的尝试，需要协调其他部门配合，但就是推不动，大家都是“无利不起早”，看不到确定性利益绑定的事情，能不做就不做。再说得直白点，如果在季度之初没有极富前瞻性和预见性地与相关部门对齐、互相绑定了这个项目方向相关的OKR,那么是很难获得良好的推进和协作的，即使长远点来说对大家都有利。那么，作为具备“Owner意识”的产品经理，此时就应该为机会担责，不要被“OKR”过度绑架。

2）动态的完美主义者

相信大家都听说过“完美主义者”，有些人会理解为“褒义”，说明这个人认真负责，做事严谨，交付标准高，容易成事；有些人会理解为“贬义”，认为这样的人容易对别人有过高要求，自私自利，控制欲强，吹毛求疵；甚至有些人还能往星座上联想，认为“完美主义者”是“处女座”的代名词。哪个才是正确的呢？或许没有标准答案，我也尊重每一种观点。

但在产品经理这个领域，传统的“完美主义者”并不见得是个助益类特质，“动态的完美主义者”才是。怎样才算一个“动态的完美主义者”？我认为需要具备如下两个认知：

（1）没有万事俱备的时候

不要总想着等到万事俱备、前置条件无一不足够完美的时候才开工、上线或交付。

（2）在迭代中趋于完美

迭代是一个重要的底层逻辑。先让MVP产品跑起来,再来根据用户诉求和产品本身价值导向的优先级来排布迭代计划,使得产品处于一种动态向完美靠近的状态中。

这里所说的关联思考是一种思维习惯，指的是如何通过关联思考的方法或习惯把新生事物与自身既有知识体系联系起来，从而加快对新生事物的理解、记忆及运用。同时，在表达上，如何让别人更容易理解自己向传达到的信息，站在他人或者通识的角度，以类比、老事新讲等手法，也是一种高效且受欢迎的手段，这也是关联思考思维在沟通表达、行事方法上的延展。

这里举一个例子来说明“关联思考”的具象化应用。让我们先来思考一个问题“怎么向一个非IT领域人士解释【RBAC权限模型】，从而让人快速、精准理解其中的概念和要点？”

首先，让我们先从专业性角度，简要介绍一下【RBAC权限模型】是什么，有哪些要素以及要素之间的关系。

RBAC权限模型是一种在系统设计中常用的逻辑模型，可用于满足大多数场景下合理管控用户权限，避免发生安全性和合规性风险。这个模型里涉及到三个要素：用户、角色、权限。

• 用户：用户即是具体的某个用户，如张三，可以用userID(C001)来唯一标识，但前端页面上展示的通常是用户名称(张三)。
• 角色：角色即是类似于“头衔”的对象，如采购部经理，在业务意义上，代表拥有一定的职权。
• 权限：权限即是某个具体的事情是否有权去做，如A页面可见权限，在业务意义上，代表具体的可见/可操作对象(是否可见/可被操作)。

RBAC模型最终要实现的是什么效果呢？让合适的用户拥有职权范围内的合规权限。怎么才能做到呢？定义角色对标拥有相对固定职权的“职位/职务”，将职权范围对应的权限打包赋予该角色，再将该角色挂到对应的用户上即可。当用户的岗位发生调整，职权也对应调整时，更换该用户的角色即可，从而不需要大刀阔斧先删减再增加权限。

先讲清楚了这个，再让我们来切入正题，如何讲给非IT人士听并让人快速理解？

关联思考，类比绑定。

火遍中文区的《甄嬛传》，开播至今十几年了仍然经久不衰，相信广大人群都看过。而里面的后宫体系正好可以完美类比【RBAC模型】，让人秒懂RBAC模型的概念和要点。

《甄嬛传》的后宫体系里也有三个要素：后宫妃嫔、位份、规制待遇。

• 后宫妃嫔：后宫妃嫔对应的即是RBAC里的用户，用户指代具体的人，如张三，后宫妃嫔同样指代具体的人，如甄嬛、年世兰等。
• 位份：位份对应的即是RBAC里的角色，如皇后、贵妃等，对应的是总经理、部门经理等有头衔的职务，同样代表拥有一定职权。
• 规制待遇：我们知道，在后宫体系里，对于不同的位份，有不同的份例，也就是规制待遇。比如皇后的规制待遇是着凤袍、掌凤印，执掌六宫事务，宫内可配备X名太监、Y名宫女等，这些都是不同规格的具体待遇，可对标权限。

通过以上的类比讲解，可以快速帮助业外人士理解概念，这就是关联思考和表达的魅力所在。

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

题图来自 Unsplash，基于 CC0 协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。