一般来说,工作能力跟工作年限和工作经验强相关,同样的岗位,我们普遍会认为一个工作3年的人比工作1年的人厉害。但为什么有的人工作1年能力就很强,有的工作5年好像还在原地踏步。抛开智商、机遇、背景这些因素不谈,从个人能力的提升方面来说,我认为从工作内容中有效地归纳和总结是一个必要条件。
工作内容之间一般都是有关联的,而且更多是重复的。将不同的工作经验进行合并同类项、分类归纳、总结提炼,化繁为简才能举一反三。
下面我以产品经理为例,聊聊我理解的如何从实际工作内容提炼出核心能力。
本文逻辑:
1、高度提炼的重要性
2、建立职业目标与能力框架
3、项目复盘总结
4、建立能力归纳表
5、有倾向性的思考
01高度提炼的重要性
项目都是公司的,产品经理只是打工的,但是从项目中学到的东西才是我们自己的财富。不断从大大小小的项目中归纳总结技巧,可以让我们提高效率,更游刃有余地完成后续的工作内容。在支持公司项目的同时,也要时刻关注项目对自己能力的建设作用,否则容易被具体业务绑架,一旦离开了这家公司,或离开了自己熟悉的项目,就会显得无所适从。
从项目中总结经验技巧是第一步,帮助我们从散乱重复的项目中找到规律、提取经验。但当我们经历的项目越来越多时,这些技巧经验也越来越多,我们的大脑是难以记忆的。
这时就需要将经验技巧再次进行高度提炼,形成高内聚、拓展性和通用性强的能力,你可以称之为能力模型、能力图谱等等都可以,当它足够精简时,可能就只有一张简图、甚至几句话。当再次遇到工作中的问题时,不需要再考虑过于细节的技巧,而是从脑子里高度提炼的能力模型中找到正常的方向。
这样的自下而上的高度提炼方式还可以移植到其他领域,超出产品经理的工作内容,延伸到对生活的理解中,搭建个人的哲学。
2建立职业目标与能力框架
要从工作内容中提炼出能力,首先要自己搞清楚职业目标,以及自己理解的产品经理能力模型是怎样的,否则提炼出来的东西只会散乱无章,无法高度概括。
对于产品经理的能力模型,业界比较有名的是腾讯产品经理能力雷达图,它对每个职级的产品经理需要掌握的能力和程度都有详细列举。
但它的缺点是有些笼统,对能力的维度没有进行很好的区分,比如“心态和情商”、“主人翁精神”这些内容跟能力好像不是一个维度,属于职业素质方面的内容,“知识传承”、“人才培养”又有点超脱于能力模型,偏重职业发展和企业建设层面。
还有网易云音乐王诗沐对产品经理能力模型的概括,对处于不同工作年限的产品经理提出了不同的能力侧重内容。
但这个模型缺点是比较偏重于C端产品,比如对于B端产品来说非常重要的技术理解能力都没有提到,还有将“思维方式”这种偏底层的内容放到3~7年资深产品经理对应的模块显然也不太合理。
网上还有很多能力模型图,我们会发现,每个领域的产品经理的能力侧重是不一样的,套用别人建立的模型是无法通用的。我认为一个合格的产品经理应该充分发挥主观能动性,基于自己所在的产品方向和对产品的理解,搭建自己的能力模型图,并不断的完善。
以下是我自己搭建的金字塔产品能力模型图,底部的思维和素质是偏底层的基础层,中层是核心能力层,顶部是锦上添花的丰富认知层。
不管产品经理的资历高低,这个金字塔都是可以适用的。资历较深经验更丰富的产品经理,他的金字塔就会更高更大,每个层级的内容丰富度也更高。但不管什么阶段,金字塔的结构是不会变的,都是从底层往上搭建。如果把过多精力放在上层,忽略了基础的建设,整个能力模型就会变得根基不稳,花里胡哨。
蓝色的两层都属于能力层,但我把偏重于实际操作的归纳为技能层,把偏重分析决策的归纳为洞察决策层。要提高这两层的能力,除了阅读、与人交流等方式,我认为更多的是靠自己从实际工作中进行总结提炼,也是本文的主要内容。
03项目复盘总结
搭建好了能力模型后,我们需要去实际经历的项目中先提炼技巧经验,而项目复盘的提取技巧经验的必经之路。我将项目复盘总结为以下四点:
一、复盘的时间节奏
较大的项目可以结束后一段时间有数据反馈后开始复盘,小的零散的项目可以季度或半年整体复盘一次。
二、产品上线是否满足真实需求
用户第一,上线的产品是否解决了真实需求是首先需要复盘的。
1、真实用户的反馈
可以直接与用户沟通,或者平台的意见反馈中心找到用户的使用吐槽。我个人做后台产品比较多,一般上线后直接跟使用的业务方收集使用反馈。
2、数据分析的反馈
用户反馈的掺杂了很多主观的因素,而且存在幸存者偏差,因此还需要通过较为客观的数据统计了解功能的使用情况。数据分析的粒度可大可小,C端产品埋点多一些,可以分析用户操作路径的数据,而B端产品数据少一些,主要从功能使用率、工单数等方面评估。
三、产品设计是否合理
由于我主要负责B端产品,以下总结更多适用于B端设计。
1、产品功能是否足够简化,是否过度设计
B端产品主要为了提升效率、满足业务诉求,因此要避免过多花里胡哨的设计,先解决核心需求。
2、是否有遗漏的异常流
规划过程中应该全面考虑异常流,但如果当时确实遗漏没有考虑到,在产品运行过程中会暴露出来,应该及时与业务方、客服寻求反馈,发现这部分遗漏的异常逻辑,及时修复。
3、关联系统的影响
对于平台型产品,调用方较多,每一方的需求也不一样,产品上线后也需要定期确认其他关联系统的影响,比如数据调用、权限区分。
4、系统拓展性设计如何,是否有预留逻辑
系统的拓展性跟过度设计听起来很像,但其实有本质区别。拓展性好的系统可以快速适应相似的需求接入,且预留逻辑一般不会单独消耗过多的开发量。复盘过程中可以结合多版本的迭代内容,仔细审视最初系统的拓展性如何。而过度设计是多做了很多没用的功能,工作量大,价值很低或者后续很难用到。
5、功能迭代的节奏是否合理,是否有重复内容
对一个长期升级迭代的系统,当回顾它的多次迭代时,我们可以回顾自己对每一版迭代内容的决策是否合理,是否将被依赖项的内容先完成后,再进行依赖项的开发?是否存在多次对同一个点进行迭代?为什么没有一次解决?这些问题只有回过头去看的时候才能评价自己当时的决策水平。
四、项目过程回顾
以下针对推进项目开发到上线的过程中可复盘回顾的内容,这个过程可以邀请需求方、开发同学一起参加,也是提高团队合作效率和执行力的好方法。
1、需求方沟通是否明确,有无较大修改,什么原因
项目启动前需求是否足够明确,在项目进行过程中有哪些较大的需求变更,什么原因导致的变更,需求文档是否有记录。
2、需求评审是否一次过,哪些是评审后调整的
需求评审时如果有核心流程考虑不周,或者需要有较大的改动,会被开发同学怼的,产品经理是很没面子的。一般刚开始做产品都会有这个过程,通过回顾自己被怼的过程,总结经验,下次获得开发的肯定,这比看无数篇别人的方法论更有用。
3、开发进度是否delay,具体哪一项导致
过程很重要,但结果更重要。对于提前定好了上线时间的项目,一般是不允许延期的。但对于没有上线要求的项目很容易延期,需求方、产品、设计、开发、测试,5个环节都延期1天的话,项目就会延期一周以上。通过回顾整个项目的时间进度,严肃客观的讨论延期的具体环节和原因,可以提高团队对时间概念的重视程度。
4、外部合作是否顺畅,哪些原因影响进度
当遇到与外部公司合作的项目,变量和不可控因素变得更多,一般这种项目的推进效率会比较低,特别是首次对接的时候。但通过回顾已经对接过的项目,对一些主观可控的内容进行梳理,记住踩过的坑,可以提高我方的项目合作能力。
04建立能力归纳表
项目复盘后,我们会总结出自己的技巧经验。以下是我设计了一个能力归纳表,可以将每一个项目的内容和经验总结填充进能力表,找到对应的位置。也可以先将工作内容先记录到这个表,然后再定期复盘填写后面对应的内容。
这个表格有三个作用。
1、 客观记录工作内容
绿色部分用于记录工作内容,客观、有序的整理记录方便回忆和复盘,从而提炼出技巧经验。
2、总结技巧提炼能力
黄色部分用于记录总结的技巧经验,然后思考这些技巧对应了产品能力模型中哪些项,再进行深度思考提炼。
把总结的技巧这一列再进行深度思考和归纳,提炼出高共性高内聚的真理,这个过程并不容易,会受到自身思维方式的影响,我个人也还在不断学习中。我建议可以多阅读关于底层思维模型的工具书和大咖的经验,如《金字塔原理》、《穷查理宝典》。
3、评估所在业务的价值
橙色部分用于思考业务的发展现状和想象力,天花板越高的业务对能力提升越有益。如果业务方向太窄,产品经理的工作内容过于重复,容易沦为一颗螺丝钉,对整个职业发展是很不利的。
这三个作用是有先后递进顺序的,这张表格需要定期进行补充迭代。
05有倾向性的思考
现在产品经理越来越细分,每个人需要将更多精力投入到自己所在的领域中。同时也是为了适应T形人才的发展需求,应该先对自己所在领域挖掘深度,再横向拓展其他方向。但实际工作中,项目划分的边界没那么清楚,可能会有模糊地带,每个产品经理可能都会涉及到不同类型的项目。因此,在一些实际项目中,可以更有倾向性的向自己的产品方向靠拢。
比如同样是做运营支持的需求,有的人比较专注于拉新转化的用户增长方向,有的人更专注于数据分析方向,还有的人主要是负责后端业务,只是辅助性的在支持运营相关需求,那他可以更多从提炼运营工具及通用性的角度来思考问题。
最后
每一段工作经历其实都有可挖掘的财富,关键看我们能不能发现它们、提取它们、再利用它们。以上是我结合了两年多工作经历,对从实际工作中提升个人能力的思考与总结,希望对你有帮助。
END
交流欢迎关注公众号:PM何小泽
网友评论