个人核心能力是什么（核心能力的四个特点）

一般来说，工作能力跟工作年限和工作经验强相关，同样的岗位，我们普遍会认为一个工作3年的人比工作1年的人厉害。但为什么有的人工作1年能力就很强，有的工作5年好像还在原地踏步?抛开智商、机遇、背景这些因素不谈，从个人能力的提升方面来说，我认为从工作内容中有效地归纳和总结是一个必要条件。

工作内容之间一般都是有关联的，而且更多是重复的。将不同的工作经验进行合并同类项、分类归纳、总结提炼，化繁为简才能举一反三。

下面我以产品经理为例，聊聊我理解的如何从实际工作内容提炼出核心能力。

本文逻辑：

高度提炼的重要性

建立职业目标与能力框架

项目复盘总结

建立能力归纳表

有倾向性的思考

01 高度提炼的重要性

项目都是公司的，产品经理只是打工的，但是从项目中学到的东西才是我们自己的财富。不断从大大小小的项目中归纳总结技巧，可以让我们提高效率，更游刃有余地完成后续的工作内容。

在支持公司项目的同时，也要时刻关注项目对自己能力的建设作用，否则容易被具体业务绑架，一旦离开了这家公司，或离开了自己熟悉的项目，就会显得无所适从。

从项目中总结经验技巧是第一步，帮助我们从散乱重复的项目中找到规律、提取经验。但当我们经历的项目越来越多时，这些技巧经验也越来越多，我们的大脑是难以记忆的。

这时就需要将经验技巧再次进行高度提炼，形成高内聚、拓展性和通用性强的能力，你可以称之为能力模型、能力图谱等等都可以，当它足够精简时，可能就只有一张简图、甚至几句话。当再次遇到工作中的问题时，不需要再考虑过于细节的技巧，而是从脑子里高度提炼的能力模型中找到正常的方向。

这样的自下而上的高度提炼方式还可以移植到其他领域，超出产品经理的工作内容，延伸到对生活的理解中，搭建个人的哲学。

02 建立职业目标与能力框架

要从工作内容中提炼出能力，首先要自己搞清楚职业目标，以及自己理解的产品经理能力模型是怎样的，否则提炼出来的东西只会散乱无章，无法高度概括。

对于产品经理的能力模型，业界比较有名的是腾讯产品经理能力雷达图，它对每个职级的产品经理需要掌握的能力和程度都有详细列举。

但它的缺点是有些笼统，对能力的维度没有进行很好的区分，比如“心态和情商”、“主人翁精神”这些内容跟能力好像不是一个维度，属于职业素质方面的内容，“知识传承”、“人才培养”又有点超脱于能力模型，偏重职业发展和企业建设层面。

还有网易云音乐王诗沐对产品经理能力模型的概括，对处于不同工作年限的产品经理提出了不同的能力侧重内容。

但这个模型缺点是比较偏重于C端产品，比如对于B端产品来说非常重要的技术理解能力都没有提到，还有将“思维方式”这种偏底层的内容放到3~7年资深产品经理对应的模块显然也不太合理。

网上还有很多能力模型图，我们会发现，每个领域的产品经理的能力侧重是不一样的，套用别人建立的模型是无法通用的。我认为一个合格的产品经理应该充分发挥主观能动性，基于自己所在的产品方向和对产品的理解，搭建自己的能力模型图，并不断的完善。

以下是我自己搭建的金字塔产品能力模型图，底部的思维和素质是偏底层的基础层，中层是核心能力层，顶部是锦上添花的丰富认知层。

不管产品经理的资历高低，这个金字塔都是可以适用的。资历较深经验更丰富的产品经理，他的金字塔就会更高更大，每个层级的内容丰富度也更高。但不管什么阶段，金字塔的结构是不会变的，都是从底层往上搭建。如果把过多精力放在上层，忽略了基础的建设，整个能力模型就会变得根基不稳，花里胡哨。

蓝色的两层都属于能力层，但我把偏重于实际操作的归纳为技能层，把偏重分析决策的归纳为洞察决策层。要提高这两层的能力，除了阅读、与人交流等方式，我认为更多的是靠自己从实际工作中进行总结提炼，也是本文的主要内容。

03 项目复盘总结

搭建好了能力模型后，我们需要去实际经历的项目中先提炼技巧经验，而项目复盘的提取技巧经验的必经之路。我将项目复盘总结为以下四点：

1. 复盘的时间节奏

较大的项目可以结束后一段时间有数据反馈后开始复盘，小的零散的项目可以季度或半年整体复盘一次。

2. 产品上线是否满足真实需求

用户第一，上线的产品是否解决了真实需求是首先需要复盘的。

1)真实用户的反馈

可以直接与用户沟通，或者平台的意见反馈中心找到用户的使用吐槽。我个人做后台产品比较多，一般上线后直接跟使用的业务方收集使用反馈。

2)数据分析的反馈

用户反馈的掺杂了很多主观的因素，而且存在幸存者偏差，因此还需要通过较为客观的数据统计了解功能的使用情况。数据分析的粒度可大可小，C端产品埋点多一些，可以分析用户操作路径的数据，而B端产品数据少一些，主要从功能使用率、工单数等方面评估。

3. 产品设计是否合理

由于我主要负责B端产品，以下总结更多适用于B端设计。

1)产品功能是否足够简化，是否过度设计

B端产品主要为了提升效率、满足业务诉求，因此要避免过多花里胡哨的设计，先解决核心需求。

2)是否有遗漏的异常流

规划过程中应该全面考虑异常流，但如果当时确实遗漏没有考虑到，在产品运行过程中会暴露出来，应该及时与业务方、客服寻求反馈，发现这部分遗漏的异常逻辑，及时修复。

3)关联系统的影响

对于平台型产品，调用方较多，每一方的需求也不一样，产品上线后也需要定期确认其他关联系统的影响，比如数据调用、权限区分。

4)系统拓展性设计如何，是否有预留逻辑

系统的拓展性跟过度设计听起来很像，但其实有本质区别。拓展性好的系统可以快速适应相似的需求接入，且预留逻辑一般不会单独消耗过多的开发量。复盘过程中可以结合多版本的迭代内容，仔细审视最初系统的拓展性如何。而过度设计是多做了很多没用的功能，工作量大，价值很低或者后续很难用到。

5)功能迭代的节奏是否合理，是否有重复内容

对一个长期升级迭代的系统，当回顾它的多次迭代时，我们可以回顾自己对每一版迭代内容的决策是否合理，是否将被依赖项的内容先完成后，再进行依赖项的开发?是否存在多次对同一个点进行迭代?为什么没有一次解决?这些问题只有回过头去看的时候才能评价自己当时的决策水平。

4. 项目过程回顾

以下针对推进项目开发到上线的过程中可复盘回顾的内容，这个过程可以邀请需求方、开发同学一起参加，也是提高团队合作效率和执行力的好方法。

1)需求方沟通是否明确，有无较大修改，什么原因

项目启动前需求是否足够明确，在项目进行过程中有哪些较大的需求变更，什么原因导致的变更，需求文档是否有记录。

2)需求评审是否一次过，哪些是评审后调整的

需求评审时如果有核心流程考虑不周，或者需要有较大的改动，会被开发同学怼的，产品经理是很没面子的。一般刚开始做产品都会有这个过程，通过回顾自己被怼的过程，总结经验，下次获得开发的肯定，这比看无数篇别人的方法论更有用。

3)开发进度是否delay，具体哪一项导致

过程很重要，但结果更重要。对于提前定好了上线时间的项目，一般是不允许延期的。但对于没有上线要求的项目很容易延期，需求方、产品、设计、开发、测试，5个环节都延期1天的话，项目就会延期一周以上。通过回顾整个项目的时间进度，严肃客观的讨论延期的具体环节和原因，可以提高团队对时间概念的重视程度。

4)外部合作是否顺畅，哪些原因影响进度

当遇到与外部公司合作的项目，变量和不可控因素变得更多，一般这种项目的推进效率会比较低，特别是首次对接的时候。但通过回顾已经对接过的项目，对一些主观可控的内容进行梳理，记住踩过的坑，可以提高我方的项目合作能力。

04 建立能力归纳表

项目复盘后，我们会总结出自己的技巧经验。以下是我设计了一个能力归纳表，可以将每一个项目的内容和经验总结填充进能力表，找到对应的位置。也可以先将工作内容先记录到这个表，然后再定期复盘填写后面对应的内容。

这个表格有三个作用。

1. 客观记录工作内容

绿色部分用于记录工作内容，客观、有序的整理记录方便回忆和复盘，从而提炼出技巧经验。

2. 总结技巧提炼能力

黄色部分用于记录总结的技巧经验，然后思考这些技巧对应了产品能力模型中哪些项，再进行深度思考提炼。

把总结的技巧这一列再进行深度思考和归纳，提炼出高共性高内聚的真理，这个过程并不容易，会受到自身思维方式的影响，我个人也还在不断学习中。我建议可以多阅读关于底层思维模型的工具书和大咖的经验，如《金字塔原理》、《穷查理宝典》。

3. 评估所在业务的价值

橙色部分用于思考业务的发展现状和想象力，天花板越高的业务对能力提升越有益。如果业务方向太窄，产品经理的工作内容过于重复，容易沦为一颗螺丝钉，对整个职业发展是很不利的。

这三个作用是有先后递进顺序的，这张表格需要定期进行补充迭代。

05 有倾向性的思考

现在产品经理越来越细分，每个人需要将更多精力投入到自己所在的领域中。同时也是为了适应T形人才的发展需求，应该先对自己所在领域挖掘深度，再横向拓展其他方向。

但实际工作中，项目划分的边界没那么清楚，可能会有模糊地带，每个产品经理可能都会涉及到不同类型的项目。因此，在一些实际项目中，可以更有倾向性的向自己的产品方向靠拢。

比如同样是做运营支持的需求，有的人比较专注于拉新转化的用户增长方向，有的人更专注于数据分析方向，还有的人主要是负责后端业务，只是辅助性的在支持运营相关需求，那他可以更多从提炼运营工具及通用性的角度来思考问题。