一张图看懂产品经理能力层级

编辑导语：不同的企业，对产品经理的能力要求可能并不一样，让人不知从何学习，该学习什么样的方法。本文作者从实践层、方法层和认知层，对产品经理的能力层级进行了分析，一起来看一下吧。

产品经理在学习和成长的道路上，时常会感觉很迷茫，不知道未来应该朝哪个地方发力，也不知道应该学习哪些东西来继续成长。

有时候，不是我们不够努力，而是努力了发现方向不对。

尽管现在企业中有一套产品的等级晋升体系，但这种体系个性化很强，并且是管理化的产物，对产品的个人成长虽有一定的作用，但普适性不是很强。

不同的企业，可能在产品经理的能力要求上都不一样，让人不知从何处开始学起，该学习什么样的方法，这对产品经理产生了很大的困扰。

对于此，私以为可以将产品能力，从其方法学习和应用上，抽象出三个层级，分别是：实践层、方法层和认知层。

其中，实践层是指实际的操作和应用，方法层是指导实践层的方法论，认知层是指形成方法论所依据的信息认知。

一、实践层

实践层主要注重解决一个个实际的问题，即利用已有的知识或方法，快速有效地解决它，并形成自己的经验和方法。

这一层要面对两个主体，一个是问题本身，一个是如何解决问题。

1. 场景模拟

无论工作中还是生活中，问题无处不在，那么问题的本质是什么，如何尽可能详细地描述一个问题？

从冲突的观点来说，问题的本质是现状与目标的冲突，现状到目标之间的距离，就是我们要解决的问题。例如，问题描述是电脑坏掉了，现状是电脑不工作，目标是希望电脑能正常工作，为了达到目标，我们就必须解决电脑存在的问题。

实际的问题，一定是场景化的，即是某个具体条件下的要解决的对象。我们在实践中遇到的问题，基本都是场景化的问题。

在场景化问题描述时，可以从两个方面进行，一个是现象，一个是场景。

现象，是问题最直接的描述，即问题是什么。

场景，是问题发生的场景，可以用故事版的形式描述。描述方法为“6W1H”法，即何人，于何时，在何地，做什么事，怎样做，为什么这样做。

场景化的问题描述的越清晰，我们越能找到相同场景或不同场景问题之间的共性，也越能帮助我们快速掌握问题的本质并解决。

2. 方法碎片

问题找到之后，我们要做的事情就是解决它。其实，解决问题不难，难的是如何快速有效地解决，并考虑方法的共通性，即相同的方法解决一系列类似的问题。

所以，解决问题，在问题描述清晰后，最终要回归到方法上。

解决问题的方法，是一个从无到有，从有到优的过程。先强调能够解决问题，至于解决的效率和成本，则优先级较低。然后在能够解决问题的方法上，降低方法成本，提升方法效率。

我们之所以强调共通性解决方法的重要性，就是要减少前期从无到有的重复性工作，直接从最优的方法开始，快速且高效地解决问题。

方法，最终应用的对象是问题，又因为大多数的实际问题是场景化的，所以方法在这一层也是碎片化的。即使某些方法可以解决某一类场景的通用问题，但这也只是这一类场景的方法碎片。

方法碎片的来源有两种，一种是场景化的方法经验总结，然后再次应用，这种经验的总结本质上也是碎片化的；另外一种是基于实践的方法总结进行抽象，并结合事情发展的底层逻辑，形成一套通用的方法论，用以指导实践层。

二、方法层

实践层更多的是“就事论事”，重在解决问题。而方法层，则更注重解决方法的有效性和普适性。

在方法层，一方面是抽象出更加普适性的、更加底层的方法论，另一方面是变化中的方法有效性的动态迭代。

1. 方法模型

实践层的方法是一系列方法碎片的集合，而方法层则是方法碎片的方法。

简单来说，方法层的方法模型是实践层的方法碎片经过抽象，并结合事情发展的底层逻辑整合而来的，然后在此方法模型的基础上，可以新孕育出不同的方法碎片。

方法模型的形成，有两个最重要的环节，分别是抽象和边界。

1）抽象

方法碎片是具象化的，有很多的约束条件，这也限制了应用的局限性。所以，我们需要对方法碎片进行抽象，找到更上一层的方法模型。

抽象的过程，主要是寻找和定义实体的颗粒度和连接。

多大的实体颗粒度？颗粒度越粗越好，越少越好。颗粒度越粗，约束条件就会越少，覆盖的场景就会越多。颗粒度越少，复杂度就会越小，约束关系也会越少。

怎么样的连接方式？连接方式越简单越好。实体颗粒度之间的连接方式，最好不要加太多复杂的逻辑，越简单越好。这样一来，在向下应用时，就会有很多的操作空间。

抽象，更多的是在诸多变化中，寻找不变，然后基于这个不变的点去覆盖变化的部分。实体颗粒度，要尽量寻找不变的；实体颗粒度之间的连接方式，也要尽量寻找不变的。

2）边界

方法模型是基于客观科学依据的方法，是科学的方法论。在科学的方法论中，一个方法是否科学，可通过“证伪”来证明，即在哪些条件下，这个方法是适用的，哪些条件下是不适用的。这些条件约束，就是方法的边界。

所以，方法模型也是有边界的，我们需要找到这个边界，并将其定义出来。因为，如果边界条件发生了变化，那问题的解法可能就是另外一种方法了，而当前的这个可能已经不再适用。

边界并不是一成不变的，而是随着底层逻辑和场景演变而动态变化的。只有当这种变化超过了某种阈值，才会导向另外一种方法。

边界的意义在于，一是可以让我们更加有效地在边界内做事，二是可以让我们意识到边界的约束，鼓励后来者向边界外探索。

2. 认知演绎

我们经常听过一句话，叫“透过现象看本质”，这句话里透露出两点主要内容，一个是“先看到，再找到”，二是“本质的存在”。

“先看到，再找到”，是通过对现象的观察和总结，归纳出可以解决现象的方法论。“本质的存在”，是指这些现象的背后，一定有某些规律或逻辑，只不过不被人所知。

我们要做的事情，就是尽可能地透过归纳出的方法论逻辑，找到其本质逻辑。

1）演绎逻辑

我们为什么要找到本质逻辑呢？因为本质逻辑在其边界条件下是不变的，然后我们就可以通过演绎法，推导出适合不同场景的方法论。

演绎是从一般情况推导出特殊情况的过程，著名的“三段论”，即“大前提，小前提和结论”三要素推理，就是一种简单的演绎推理。

演绎特别重视“前提条件”，只要前提条件错了，后面所有导出的结论都是错的。所以，我们要尽可能的找到对的前提条件。

而对的前提条件，是基于我们对世界的认知的。从这方面来说，我们每个人的方法论，都是基于个人对世界的认知演绎而成的，即我们对世界本质的认知，映射到我们的种种行为中，就形成了我们的处事方法。

方法模型，也是基于我们认知的演绎。只有认识并了解到事物的本质逻辑，我们才有可能形成本质的方法模型，然后演绎出不同场景的方法碎片。

2）寻找不变

老子曾说：“道生一，一生二，二生三，三生万物”。其中，道是不变的，基于道而演化万物。

这与演绎逻辑的原理类似，演绎的前提条件是不变的，基于前提而演绎出不同场景的解决方法。

所以，演绎最重要的是寻找不变的前提条件。

不变与变，是相对的。在某个时期或某个空间内，“前提条件”是不变的，但在另外一个时期或空间，“前提条件”却是变化的了。

例如，牛顿力学的前提条件是绝对时间和绝对空间，即空间和时间是不变的。但在爱因斯坦的相对论中，光速是不变的，而时间和空间是变化的了。

那么，我们如何去寻找不变呢？

私以为需要从认知出发，并结合现象问题，逐步靠近不变。

其实，科学的发展史，也是对世界的认知史，从“地心说”到“日心说”，从经典力学到相对论，从元素到分子、原子，等等。都在寻找不变，靠近不变，并让我们认知并了解。

三、认知层

在方法层，我们知道了方法模型是对认知的演绎，我们认知的越深、越接近世界的本质，方法模型就会越准确。

所以，在认知层，我们需要提升我们的认知，并不断地追寻源头，去寻找那个不变。

1. 追本溯源

我们所处的社会环境都是表象的、场景化的，所遇到的问题，已经是某种规律作用之后的结果了，所以很难看到其产生的机理。

就像我们感冒一样，在感冒症状出现之前，已经存在病毒接触期、潜伏期和作用期了，只有当身体抵抗不了了，才会出现症状，而这个症状就是最终的表现结果。

如果我们想解决这个问题，就必须找到源头，从其本质规律出发，找到解决的方法。

寻找源头，是一件很困难的事情。不仅需要追本溯源的勇气，要敢于寻找下去，而且还需要克服种种困难，排除外界干扰，不断地与自己对话，与真理对话。

追本溯源，可以从我们身边的每一件事情开始做起。例如，最近的汽油涨价了，为什么会涨价？因为供需不平衡，什么决定了供需不平衡？因为市场经济和资源的稀缺性，市场经济的规律是什么？依赖的对象是谁？如果这个对象不存在了，还会有这个规律吗？其他对象是否有这个规律？

从问题表象，不断地追问到其产生的机理，如果想更深一层，还可以对这个机理不断地追问下去。所有的这些追问和思考，将会让我们更加接近问题发生的本质。

2. 我思我在

我们一直努力地在寻找不变的源头，那么找到源头之后，可能会忍不住思考：源头为什么会存在？什么是存在？存在的形式是什么？

所有的这些思考，都会让我们更深一层地对源头进行思辨，这也就上升到了哲学的维度。

著名的哲学家笛卡尔曾提出“我思故我在”的哲学命题，他怀疑一切的存在，房子、衣服、植物等，甚至个人身体，都是不存在的。那么什么才是存在？他提出只有当我思考的时候，思考这件事是存在的，所以我思故我在。

虽然这个命题后来被人证明并不是十分可靠，但这种对源头的思考和证明，是值得我们学习和借鉴的。

对于源头的追寻，前人已经做了足够多的哲学思考，像老子的“道”，柏拉图的“理念世界”等。虽然我们与源头的距离还很远，但我们可以做的，就是站在巨人的肩膀上，眺望远处的景色，然后辨别方向，努力寻找。

 

作者：白不记，公众号：有笔不记（ID：you_buji），关注产品的学习与思考，用有序的眼光观察无序的世界。

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

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