产品经理，需要一些必备素质

编辑：010 时间：2020-02-21

梁宁在《一个产品经理的奥赛德之旅》文中提到：

我们在学校里学习，熟悉学校的环境和应对方式，我们知道该如何学习和考试。一旦离开学校进入职场，离开这个熟悉的战场，我们就会开始一段新的寻找自己的理想国之旅。

在一次新的漂泊旅程里，从一枚小白开始，去学习新的能力，去探索自己的理想国在何处，不断历练、不断尝试，最终找到自己的理想国并成为国王。这种漂泊的状态可能有10年左右，一旦找到自己的理想国，然后经营和建设，最终稳定。

所以工作是一场修行，是一个持续探索和自我提升的过程。回顾刚入行产品时，常常被问到：“你觉得产品经理需要哪些必备的素质？”

那时候回答：“逻辑思维、沟通表达、需求分析、项目管理…..”

而如今，经过两年多的“锤炼”，再回答这个问题，只想说：好奇心、同理心、抽象思维、系统思维。

它们就像人的底层操作系统和CPU，它们越发达，我们越能处理复杂的问题，并且速度也越快。

我们常说一个人解决问题能力强，再往下一层，其实是他好奇心重，不停留问题表面，不断逼问问题本质，解决问题的第一步是要真正找到问题；

我们常说一个人沟通能力强，再往下一层，同理心是很重要的驱动因子，站在对方的角度思考问题，自然让彼此沟通更顺畅；

我们常说一个人逻辑思维能力强，再往下一层，其实是他的抽象归纳、框架感强；

我们常说一个人产品设计能力强，其实是他系统思维更全面，可以大而全的了解整个面貌，而不仅仅停留局部和片面。

一、好奇心

史蒂夫·乔布斯有一句名言：“Stay hungry，Stay foolish”，保持饥饿，保持愚蠢。曾经一次又一次向领导描述问题，总是被连着逼问四五个为什么，在第三个左右就败下阵来。

你是否习惯接收习以为常的东西？你是否习惯回答别人都是这么做的？你是否习惯相信别人描述的“事实”？为什么有些人思考问题的角度总是你没想到的点？为什么有些人提出的点子总是让人眼前一亮？为什么有些人看问题可以一针见血？

这是好奇心驱动的结果，在思考问题时，好奇心驱动你不断逼近问题本质的思考，而不仅仅停留在习以为常的“事实”表面，知其然且知其所以然。无论是好奇心，还是问题本质思考，连环追问法是最好的践行方法。

通过对问题的连环追问，我们能发现表面问题背后的真正问题到底是什么，可以帮我们看到冰山下隐匿的真正关键点，产品经理重要职责之一是帮助企业发现问题并解决问题，只有找对了问题，才能解决问题。

通过对人的连环追问，我们能弄清楚人真正需要的是什么。在需求调研的过程中，用户往往会从自己的经历出发提出很多“产品解决方案”，作为产品经理，你不能就这样接收了用户的表面诉求，首先需要发自内心的理解对方，多问几个为什么，找到用户提出某种需要背后的真正动机。

二、同理心

同理心原本是个心理学概念，主要指放下自我、换位思考、倾听能力，更好的理解对方想法以及表达尊重等与情商相关的东西。在工作中主要体现在沟通和需求分析上。

产品经理，容易自以为是，主观意愿过强的人，非常容易犯想当然的错误，陷入一种思路：产品具有某种功能特性，用户自然会用该特点去理解和使用它，用户对产品的需求由产品自身所具备的功能决定。而产品具有的某种功能特性，来源于产品经理本身“我觉得”，其实是在按照自己的意愿做产品。

我曾在做一个简单页面上列表字段排列顺序时，被吐槽没有理解用户使用场景，这并不是用户想要的展示顺序。我们常常认为事情应该是怎样，别人应该是怎样去想，用户拿到产品后应该按照自己的预期去操作。

个体都有差异，即使用户表面接收了会如何如何，在实际操作过程中也会出现“意外”，有时候，可能用户还不买单，表现的特别“不听话”。

所以，放下自我是第一步，倾听对方是第二步。

同理心也会明显的体现在职场沟通上，身边总有人可以和公司每个同事都相处融洽，尤其是和有直接利益关系的业务部门。从公司组织架构上来看，服务好了业务部门，极大程度也奠定了你在公司的重要程度。

产品需要跨多个部门协调资源，很多也许是你不熟悉第一次打交道的同事，如何让对方更好的协助自己也会影响项目的推动进展。如果一开始，以自我为中心，不顾对方所处环境和情绪，只要求对方帮自己完成自己想要的结果，对方自然不乐意帮你。

想对方所想，婉转的换一种说辞，需要对方协助的工作是为了更好的推动对方想要的目标，沟通结果会很大程度不一样。

三、抽象思维

抽象思维在做后台系统或者B端产品时，尤其重要，后台系统或者B端产品对接系统多，业务复杂度高，涉及各种流程、角色和规则等等，如果你没有抽象思维，你会陷在各种细节里。

而且你很难向别人去描述清楚，因为大多数人对细节的了解需要建立在完整的背景下。但是我们在跟别人沟通描述过程中，习惯直奔主题，没有背景，即使你想讲背景，很少人有耐心想听你讲这么多内容。

这时候抽象思维重要性就体现了，尤其是我们在做汇报时，与完全不了解背景的人沟通时，你要尽可能的用鱼骨架来讲述，避免提到鱼骨架上的鱼肉。

在做项目过程中，有一个真实的案列，让我第一次意识到抽象思维能力也是人的底层思维能力。

我做支付系统，对接不下十几个第三方支付网关，每个支付网关的退款功能情况不相同，可能本身就不支持自动退款，可能支持自动退款。但是由于各种原因导致退款失败，退款失败后的需要人工处理流程也不一样。

实际发生退款的场景也有正常支付退款和重复支付退款两种，本身支付系统还和订单系统对接，支付系统作为一个平台，不仅仅对接一个业务方的订单系统，还同时对接其他两三个业务方，这让整个退款流程变的十分复杂。

我一度陷在细节里无法做到各个系统彼此关联又要相互解耦独立，最后反复沟通思考，发现问题不过是下图所示，对于支付系统而言，所有不能自动退款成功的订单，全部放至人工退款界面。针对不同的支付方式，设定不同的角色，专门负责跟进退款处理。

把性质相近的元素合并到一类，随着观察视角的升高，产品的骨骼就会逐步显露出来。因此，抽象的过程实际上就是个先分类、再提升视角的过程。

作为产品的创造者，我们十分清楚鱼骨架上的所有鱼肉细节，但是也要从鱼肉中找到串起鱼肉的鱼骨架。这不管是我们与人沟通还是做产品设计，更能呈现出全局观和框架感。我们需要来回切换在具体与抽象之间，既能用“火眼金睛”看骨架，也能切换到“肉眼”模式看细节。

我做支付的各种项目，每个项目有不同的项目目标，但最后抽象出来的核心是：简单、安全和便宜，所有的项目目标都会围绕这三个标准。现在写需求文档或者做PPT汇报，会采用小标题+正文形式，用简短的小标题（一般不超过六个字）表达我的想法，正文是解释说明。

当刻意强迫训练提高抽象能力时，慢慢也发现，逻辑思维能力好像变强了些。我个人理解，逻辑思维能力，更多在于框架思维、抽象和归纳、演绎等。

四、系统思维

去年这时候做项目，产品设计常常缺胳膊断腿，在需求评审会上，开发常常发问，极端和异常情况的处理，对其他系统的影响。

在开发过程中，也是被各种产品设计时没考虑到的问题，让开发、测试咨询的抽不开身，处于边开发，边完善需求的状态，头痛医头，脚痛医脚。或者项目上线后，新老版本兼容性等问题没考虑到位，线上救火。

现在才知道，真正原因是缺失的系统思维，当时的我完全是“站在产品内部做产品”。由于毫无系统思维看整个全局，只能被动地作出反应，哪里出问题就修补哪里，产品功能设计极易停留表面，解决眼前问题，反复折腾几轮，陷入“打补丁”怪圈。

也许昨天冒出了一个A问题，用最直接的解决方案去修补好了，今天却又冒出了B问题，而B正是由A的解决方式引发的。这样的情况一再发生，就好像“打地鼠”游戏，刚把这边按下去，另一边又翘起来了。

建立系统思维后，找到真正“治本”的解决方案，而不是忙着“治标”，在项目真正投入开发前，和涉及所有系统的技术负责人沟通方案，确实可行再投入开发。这样当项目需求评审完，进入开发过程，就不再需要你花太多时间跟进，你可以转身投入到下个项目，以此良性循环，工作也会越来越轻松。到现在，做的项目，开发过程几乎不再需要我花时间跟进，定期询问进度就好。