在产品经理的成长路径中，执行力常被视为起点，但真正的跃升，源于影响力的建立。本文深入剖析从“能做事”到“能成事”的底层能力演化，帮助你识别关键转折点，构建可持续的产品影响力体系，迈向更高维度的职业价值。
很多人谈产品经理的能力模型，却只是在列技能表：需求分析、用户访谈、PRD……
但真正优秀的产品经理，靠的不是技能堆叠，而是能力结构。
产品经理在个人能力和职业发展中，都需要具备非常多的专业能力。很多大厂也对产品整理了相关素养模型。
下面这张表是目前行业比较认可的一份能力表：
表格里划分通用能力、专业知识、专业技能、组织影响力四个大模块。通用能力是所有产品必备的能力，随着级别的提升，其他模块能力需要随之提升，但后续可能会根据不同的产品方向侧重点不同。
上面的内容挑选几个跟大家分享一下：
1）学习
学习和提炼能力是产品最基本的能力，产品需要掌握非常多的知识内容，所以我们要保持学习的热情。除了工作中学习产品、项目经验，跟运营、技术同事学习运营和技术能力外。需要增加阅读量，看书、在媒体平台学习。除此之外可以参加培训、沙龙、以及线下讲座等活动来获取知识。
在工作中和平时的学习积累过程中找寻有价值的信息。
2）提炼并联想
如果只是学习知识，很难形成自己的知识体系，可能过段时间就遗忘了。所以提炼并联想转化知识也很重要，把提炼的知识联想到我们工作、生活中，遇到的问题上，这样就能加深我们的印象，为我们自己所用。
首先是执行力，执行力大家认知里就是完成老板给的任务，定义是没问题的，但其实可以做得更好。
老板：小明、小赵调研下关于社区中，踩评论的功能，尽快给我答复。
小明：XX平台和XX平台都做了这个功能，他们都是我们竞争平台，所以我觉得我们也需要做。
小赵：踩评论的功能可以帮助用户针对评论做判别，平台可以根据踩评的数据，针对评论做降低权重操作，而且可以增加未来坏评论的过滤机制等，所以我觉得可以尝试添加这个功能，做A/B test….
从上面的例子可以看出，小赵不单考虑了问题背后的机制，而且给出了结果。
“完成任务不等于结果”，很多老板的问题其实是要一个结果的，但很多老板提出了问题，但不会跟你说问题的原因。
所以好的执行力，是需要追溯问题背后的原因，在给予结果，这才是老板想看到的。
1）可以把控需求，同时可以提升沟通
早期产品经理遇到的最头疼的问题就是，没有技术能力。好多朋友新入行或者打算入行的同学，问的最多的问题就是，我没有技术能力能做产品吗。没有技术能做产品，但想要做好产品，一定要加强对技术的理解。
这样一方面，能更好的把控需求，另一方面也大大提升技术的沟通效率。
社区主页加载过慢，需要进行方案上的优化
社区主页加载渲染的过程，需要调用多个接口，其中很多接口三方系统，怎么处理呢？抛给技术处理？
技术：接口请求已经非常快了，你们要加载这么多信息，技术解决不了。产品拿方案出来。
产品：….
上面问题虽然看上去是技术问题，实际跟产品策略有关系。技术在性能优化方面也会有阈值，可以减少加载时长，但请求数据大的情况，还是会无法达到想要的体验。
所以如果产品懂一些技术知识的话：
社区主页数据有些不需要实时请求，把这些数据做下缓存处理，用户在使用程序的生命周期内，进入页面加载缓存处理。
所以这样无论在需求，还是技术沟通上，就能很好的规避一些问题。
2）创造新功能
对一些底层的技术理解，也会创造出新的功能。大家最熟知的例子：
比如微信摇一摇，为什么摇手机，能触发匹配机制。摇手机的行为是怎么被系统知道的，实际上是调用了手机内置的加速度传感器功能，可以检测手机X轴、Y轴、Z轴的加速度变化。当加速度变化到一定阈值，服务端接收数据，再来执行接下来的匹配功能。
同样是匹配附近的朋友的功能，但是借助一些技术能力，就会让功能变得更有趣，更吸引人。
1）结果为导向
我们在做功能设计的时候，不单单是要考虑功能实现，用户如何去使用。而要更多的以结果导向思考。
比如我们设计一个评论功能，功能其实很简单，用户可以在社区内容下进行留言互动。
但这个功能目的是什么呢？
实际上是为了增加内容的互动，从而增加社区的活跃度，增加用户的粘性，从而提高所谓的：留存率
2）产品设计要适当
这里其实想说两部分，一部分内容是要符合用户体验，另外一部分要考虑清楚产品的复杂程度。
怎么理解复杂程度呢，不要过度设计，例如：社区图片预览功能，需要保存图片，在这个场景下，预览图片是重点，下载是次要。在下载的过程中，增加了“暂停”“取消”功能，这种就是典型的过度设计，弊大于利。
要考虑功能的拓展性，预留口子，例如：在设计社区模块，在验证初期，可能社区的内容类型上，做了单一类型，便于快速的市场验证。但后期会考虑做多类型的内容。如果在设计初期没有把口子留出来，第二阶段去增加的时候，对于技术来说可能要把这功能结构重写，这样成本就会增加很多。
所以在初期设计，需要考虑拓展的问题，功能上可以不做出来，但是要预留出口子，让后台或者技术结构上支持。
3）一秒变小白用户
这个早期是小马哥和小龙哥提出的能力，也是我们现在产品需要具备的能力之一。
之前内容里提过，所有功能都会在某个场景下，被使用。使用的核心链路是否能被用户理解和认可是很重要的。
所以我们在设计功能的时候，要考虑如果是一个小白用户，在使用功能时是不是会用，这个是很重要的一点。
数据这部分对于产品来说，实际上会分为两部分，一部分是数据体系搭建，另一部分是数据分析。
1）数据指标建立
数据体系搭建实际跟我们设计产品类似，首先需要分析业务，针对业务进行数据的核心指标建立：
例某平台核心指标是内容订阅数，为了达到这个指标，可以拆开几个维度。首先提高用户订阅数，其次提升订阅内容吸引力，第三拉长用户订阅周期。然后可以再细分。
核心指标建立后，再细化拆分过程与指标：
2）数据分析与改善
建立了细分指标后，接下来需要进行指标的数据分析，常规的方法漏斗分析法：
例消息触达的效果，圈选人群包用户10000，下发用户5000，下发曝光用户1000，消息点击用户20。
这里能看到最后消息点击的转化很少，就需要考虑为什么，如何进行优化？
是推送时机不对？人群包用户画像不匹配？内容不够吸引力等等。
3）数据导向的总结优化
数据分析后，需要根据结果来制定后续的策略。效果好，怎么扩大，效果不好，需要定位原因。也是我们常说的数据驱动产品。
之前的内容有提到过，方法实际是解决问题的一类工具。方法论的建立也可以用方法来帮助思考，这里分享一个通用的方法论建立的过程：
我们看过很多产品方法，这些总结方法的人都需要大量的实际经验+构建知识框架+应用，最后提炼出可行的方法。
例如我在之前文章里提到过的，“如何理解和绘制产品架构图”，在看了大量架构图的绘制，拆解之后，总结了一套我个人认为很好理解的流程，来映射出架构图的理解和绘制方法一样。
总结：
产品经理的能力/素质表有很多内容，这些都是产品向上晋升的必要能力，文章里抽离几个重要部分来举例说明，后续有时间会继续拓展。
本文由 @Robbie 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。