一般来说，工作能力与工作年限和工作经验密切相关。同样的职位，我们一般认为工作3年的人比工作1年的人强。但为什么有的人工作一年后能力很强，而有的人工作五年后似乎还在原地踏步？抛开智商、机遇、背景等因素，我认为从个人能力提升方面对工作内容进行有效的归纳和总结是必要条件。

内容大体相关，多有重复。只有把相似的条目组合起来，把不同的工作经验分类总结，化繁为简，才能举一反三。

我以产品经理为例，谈谈我是如何理解如何从实际工作内容中提取核心能力的。

这篇文章的逻辑:

高度提炼的重要性建立职业目标与能力框架项目复盘总结建立能力归纳表有倾向性的思考

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)是开发进度延迟，是哪一个造成的

过程重要，但结果更重要。一般不允许对已经提前设定上线时间的项目进行延期。但是，如果没有在线要求，项目很容易延期。需求方、产品、设计、开发、测试推迟一天，项目就推迟一周以上。通过回顾整个项目的进度，认真客观地讨论延迟的具体环节和原因，可以提高团队对时间概念的重视程度。

4)外部合作是否顺利，什么原因影响进度

遇到和外部公司合作的项目，变数和不可控因素变得越来越多。一般这类项目的推广效率会比较低，尤其是第一次对接的时候。但是通过回顾接手的项目，整理一些主观可控的内容，记住被踩过的坑，可以提高我们的项目合作能力。

04能力汇总表的编制

项目复工后，我们会总结自己的技巧和经验。我在下面设计了一个能力汇总表，可以把每个项目的内容和经验总结填入能力表，找到对应的职位。也可以先把工作内容记录在这个表格里，然后定期查看，填写相应的内容。

这个表单有三个功能。

1.客观记录工作内容。

绿色部分用于记录工作内容，记录的客观有序排列便于回忆和回顾，从而提炼技能和经验。

2.总结技能和提炼能力。

电影部分是用来记录总结出来的技能和经验，然后思考这些技能对应的是产品能力模型中的哪些项，再深入思考提炼。

深入思考，总结归纳总结技巧，提炼出具有高度概括性和凝聚力的道理，并不容易。会受到自己思维方式的影响，我还在学习。建议可以多看一些关于底层思维模式和大咖经验的参考书，比如《金塔原理》和《可怜的查理的收藏》。

3.评估你企业的价值。

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

这三个函数是递进的顺序，这个表需要定期补充迭代。

05倾向性思维

现在产品经理越来越细分，每个人都需要在自己的领域投入更多的精力。同时，为了满足T型人才的发展需求，先深挖自己的领域，再横向拓展其他方向。

但在实际操作中，项目划分的界限并不是那么清晰，可能会有模糊的区域。每个产品经理可能参与不同类型的项目。所以在一些实际项目中，可以更倾向于向自己的产品靠拢。

比如也是作战支援的需求。有些人更专注于新转型的用户增长方向，有些人更专注于数据分析方向，有些人主要负责后端业务，只是辅助性地支撑运营相关需求。然后，他可以更多的从细化运营工具和通用性的角度去思考。