对产品经理能力的认知重构:产品经理知行合一曲线模型

14 评论 25191 浏览 176 收藏 17 分钟

产品经理“知”决定了一个产品的高度,“行”决定了产品的实现效果。知与行,两者缺一不可。

当下我们对一个产品经理的能力进行分析、考察、判断时,基本上都是直接从逻辑思维能力、产品Sense、学习能力、数据分析能力、沟通能力···等这些产品经理所需具备的能力要素进行评估,然后聚合出一个综合评估结果(反应能力高低)。

这套考察路径执行下来虽然从理论上说似乎也没什么问题,涵盖了产品经理所需的各方面能力。但在实际操作过程中不知道大家有没有隐隐约约意识到,我们会潜移默化地只注重考察该产品经理知识方面的能力(说的能力),而常常弱化或忽略了对其实际落地、执行能力的考察。

而一个产品经理的实际落地、实现能力是不容忽视的,它与产品经理的知识能力一样重要,甚至更重要!产品经理实际产出的产品才是最终的价值体现。

一个产品经理,若有一个100分的idea,但最终落地只产出了20分的产品,那你价值就是20分,而不是100分!

产品经理的“知”与“行”

产品经理是当下最火爆的岗位之一,众多怀揣着梦想的年轻人及在其他行业待厌倦的从业者纷纷加入这股产品洪流之中。但我们知道任何事物都有正反两面,我们在享受该行业火爆带来红利的同时也要去面对它所带来的反面——正是由于该行业的火爆,吸引着很多或许不那么适合的人才进入,造成了该行业鱼龙混杂,同时变得比较浮躁。

所以当下市面上产品经理虽多,但高质量的优秀的产品经理还只是少部分。眼高手低、只有观点无实操型的产品经理随处可见。说起来头头是道,做起来千疮百孔的产品也不在少数。

这样的现象十分常见于很多公司招人——在面试的时候被面试者夸夸其谈,展现出了十分清晰的逻辑,各种产品方法论也说得条条是道,还拥有庞大的宏观认知、极高的智商以及很好的情商,于是乎公司上下都对其寄予了厚望,望其实现所规划的宏伟产品目标,在产品方面助力公司实现整个公司的宏伟蓝图。但当其加入后,到了实际执行时却慢慢发现似乎变了味,他的宏观认知听着挺养耳,但在实际工作根本没太多可落地的地方;各种方法论说的时候大体逻辑都能通,但一到具体项目中就出现各式各样的“水土不服”;产品规划说的时候各种高大尚,但落地出来了就是个小土鳖;等等。

这样情况之所以常常发生,是因为我们大部分时候都没有深刻意识到,一个能真正带来真正价值的产品经理实际上要有两种能力。

接下来我们就好好聊聊这两种能力:

  • 知:智力、知识、方法论、世界认知等理论知识的能力;
  • 行:落地、执行,把一个构思、想法实现的能力;

产品经理“知”决定了一个产品的格局高度,它可以让产品的战略、市场、方向尽可能地正确。通过产品经理的“知”所规划出的产品是该产品最理想时的状态,是产品最佳效果的上限。而产品经理的“行”就是在“知”的基础高度上,统筹各方资源,运用各种能力,克服各种困难,去尽可能地把产品按照最理想的效果实现出来,“行”决定了产品实际效果。知与行,两者缺一不可。

但由于当下社会因素的限制(了解一个人的“知”似乎比了解一个人的“行”容易些)及一些惯性使然,当我们看一个产品经理的能力时,会自主或不自主地把精力都放在了对“知”的考察上,而对于“行”的考察却不够重视。

之前所在的一个团队中有个产品同事,很聪明、策划出的产品也很Nice,表现十分突出,但每次最终绩效考核的时候并不是最好的,都只是中下,而做出来的产品也都没有在初期时所想的那么惊艳。最后,郁郁不得志的他选择离开。

后来有一次机会他跟我聊到这个话题时,说了他事后对当时进行分析的结果:虽然他很聪明,产品的认知很高,但由于自我感觉太过于良好,因此常常怀有自我优越感,做事都以自我为中心,造成相关的设计、开发、测试等同学并不乐意跟他合作,所以造成了在产品开发落地过程中总是磕磕绊绊,得到的资源也不是最好的。因此最终做出产品总有点虎头蛇尾的感觉(当然,说蛇尾夸张了点,但意思是那个意思哈)!

知就如理想,行就是现实,理想与实现有差距,但不同的人差距不一样。

知行合一曲线模型

现在我们假设一个场景流程。你作为一个产品经理,经过你九牛二虎之力,借助你高深的认知及丰富的知识、经验,在你的脑海有了一个100分的产品,这个100分的产品就是其最理想的状态。这时你大体上要经过以下几步去把你的理想产品实现出来。

首先,你需要把你的产品构思变成产品语言,输出各类图、文档。可在输出过程中你发现一些原来想实现的酷炫功能具体落实到每个细节的时候,发现并没有带来你当时所想要的效果,所以你纠结一把之后决定把这些功能丢掉,这时你的产品从100分降到了90分。

然后你带着相应的产品输出找到了设计师,设计师瞟了你两眼说:这种交互真正做出来很怪异,而且你所想要的色系、颜色渐变、视觉效果有点难度,不过我尽量调吧,下周给你。你苦苦等到下周,结果看到的效果根本不是你想要的,找到设计师又调了两版本,结果还想再调的时候设计师说你刚开始也没把需求说得特别清楚,现在绕了这么大一圈到底还想怎样!然后抛下一句“我现在要干其他项目的活了,先就这样吧,以后有时间再说”!这时产品从90分降到80分。

把设计好的源文件、切图交给前端同学。前端同学只是快速做到了设计稿的物理还原(只是按照设计稿的颜色、字体、大小、间距等的参数构建开发出来,但由于展示媒介的不同,会有一些地方跟设计稿视觉上不一致),当你想让他们再打磨一下实现视觉还原(以视觉效果与设计稿一致为准,这对前端工程师的水平、经验有较高要求,要靠自己的“感觉”去微调一些参数值)时他们也只是简单做了一些,而且很多功能实现出来也并非最初所想的。这时产品降到70分。

在后端开发那边,开发老大突然说某个功能的技术难点攻克不了,要直接砍掉,你找他理论,结果由于各种因素主观、客观因素公司老总还是偏向于开发那边的结论。产品慢慢又降到了60分。

好不容易产品上线了,要做运营推广,这时运营同学跟你说要想把产品推广出去的话就要加进一个活动功能,同时把某个功能先隐藏起来,否则难以推广。最终用户见到的是50分的产品。

我们把上面的过程表现成如下图(注:为了说明问题我们都是等比递减,所以图中是下降的直线,在实际过程中应该是不规则的曲线):

到此,借助上图我们可以看出,想要打造出优质产品,除了产品起点(产品策划)要高,同时在落地(执行)过程中要尽可能不“失真”,从图中来说就是要尽可能不让整条曲线有太多的下降。

回到产品经理能力角度亦是如此。一个全能优秀的产品经理除了要有较高的知产品认知,还需有产品落地执行能力。

我们继续从知、行双维度的曲线全面分析产品经理的能力:

通过上图的产品经理能力曲线,我们能够看到即使拥有相同的产品理论、认知,但在由于执行的能力不一样,最终的产生的价值是不一样的。这也就不难解释为什么平时我们只通过“知”来判断时看起来差不多的经理,到了产品实际落地时得到的是完全不一样的结果了。

产品经理“知”的能力体现在曲线的起点,而“行”的能力体现在曲线的坡度。在起点一致时,曲线越平缓(坡度越小)就说明对应产品经理的执行能力越强,也即说明该产品经理的能力越全面、越能产生实际价值。图中三条曲线所对应的产品经理的能力为A>B>C。

产品经理提高“行”的能力的过程,就是不断把这条线往上提的过程!

那对于产品认知不一样的产品经理,是否认知越高该产品经理就越优秀呢?不一定!

上面图示也充分说明了第二节内容中提到的那个例子,例中所提到的那位前同事能力模型如曲线B,起点(产品认知)虽高,但“行”的过程中产品是急速失真;而另外的小伙伴的能力模型如曲线A,或许起点没那么高,但是曲线下降去很平缓,所以最终的输出价值要远高于B。

因此,今后对于一个产品经理能力的高低评判,应该抛开之前只从知的单维方式,而从知、行两个维度考察,知行合一。

其实文中的提到的执行合一还有另外一层含义。在本节所假设的产品流程中(或者大家的实际工作中)会经常碰到这种情况,就是开始的时候策划好了,但到执行的时候发现又不可行了,不是想漏了一些东西就是存在思维漏洞踩了坑。而造成这些的原因是因为我们在打造知识体系时,很多时候是脱离执行的实际情况的!因此,在建立自己的“知”时要尽可能是符合“行”的“知”,而不是纯理论不具备实际可操作性空中楼阁的“知”。

几点说明

第一,这个模型怎么跟我们之前的方法相融合?

先说明一下,提出这个模型并不是完全否定我们之前的方法,而是作为往上一层的提炼。

其实这个模型跟之前我们从直接逻辑思维能力、学习能力、沟通能力等方面评判的方法并不冲突,只是之前的方法很容易把我们带偏到只考核到“知”,而忽略了“行”。所以有了这个模型后,我们就可以一开始提升到从知行两个维度来切入考察,然后在这两个维度下我们再利用以前的方法去得出这两个维度的判断。

第二,只是做策划,是否需要重视“行”的能力?

在很多大公司里面,有些产品的分工或许就是负责做产品策划等一些理论工作,那是否还需要“行”的能力?回答是需要的!在上一节的末尾也已经提到了相应的说明。要想成为一个优秀的产品策划,那你就需要有执行的能力(大多数的产品策划都是从产品执行做上去的),否则你策划的产品就是纸上谈兵,很有可能交给其他产品经理去执行的时候就会各种踩坑。

就如现在很多大的咨询公司,他们的“知”是建立在“行”的体系上的,除了给客户提供方案,大部分情况下还需要去给客户落地执行。

第三,助力自己成长重于评估别人

文中大多都是从评估别人的角度出发去论述,其实,本文的初衷更多的是希望我们用于自己的成长指导——除了在产品理论方法、知识认知上不断成长、提升,还需要时刻注重实际的落地、执行能力,从而让自己成为一个知行合一的全面产品经理,而不是一个说起来头头是道,做起来千疮百孔的纸上派。

总结

让我们回顾一下产品经理的知行合一曲线模型。

曲线的起点代表了一个产品经理“知”的能力高度,曲线的坡度代表了“行”的能力,终点则是最终产出的产品。整条曲线体现的是产品经理知行合一能力(实际贡献价值的能力)。

真正优秀的产品经理的能力曲线应该起点高,坡度小(尽可能水平)。

最后,总结一下。

说了这么多,就是想大家能够借助这个模型,时刻意识到自己的能力要知、行并重,做到知行合一,通俗上讲就是一方面既能够产生高质量的产品、信息,同时又能在产品、信息落地的过程中尽可能地做到不失真。从而能够成为一个能带来真正高价值的全面产品经理。

产品之路,长路漫漫,共勉之。

 

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

题图来自PEXELS,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 如果给你一句话,你能写篇文章

    来自北京 回复
  2. 作者写的很用心。

    来自浙江 回复
  3. 学习了,,下班一起撸串

    来自安徽 回复
  4. 作者更多是针对开发一个新产品的。我觉得产品更重要的,在于掌控好产品的生命周期,什么周期给什么功能争取相应的资源支持。其次不要产品经理很多想法,个个都想要实现,更多的还是以用户为中心。

    来自江苏 回复
  5. 道理懂了,但如何做到更好的“行”,貌似没说。

    回复
  6. 知行合一,不止产品,做人也是。两方面都要加强。面试的时候确实更重于知,但是表现出你行的能力会加分不少。

    回复
  7. 感谢前辈分享

    回复
  8. 这位大佬,我就是属于那种“知偏弱”“行偏强”的产品(从UI和交互干到产品的)。最近面试,好多HR和面试官,都是侧重于了“知”,完全忽略了我“实际落地的能力”,优势表现不出来,劣势却一直被戳。导致目前屡屡碰壁。大佬可否赐我一良方,以解心结啊。

    来自北京 回复
    1. 知行合一讲的是两个能力的相互结合,缺了哪块都不好。然后再说说知行合一中“知”,它决定了产品认知的高度(决定了一个产品最好的状态),只有高度够高了你的行才有体现出价值的机会,不然曲线的起点就低了,你的“行”再怎么把这条曲线往上抬,即使做到把曲线无限接近水平,最终落地出来的结果也是很低的。而且,如果你“知”很弱的情况下说“行”很强,很有可能这强只是自己觉得的强,实际上并非真的强(只是根据你的描述进行理论逻辑分析,或许实际情况并非如此,如有冒犯,十分抱歉)。知行合一说的“行”并非是简单地把一个事情快速做完,而是要结合认知的高度并把它高质量落地。

      不过话说回来,既然你提到“行偏强”,那就肯定也会有一些能看到的现象。那为了面对面试,如果想要展示出来的话可以带上一些具体可以展示的内容,比如说原型图是否绘制得很好?那就打印出来带上;评审会议是否组织得很好?把真个的会议纪要也展示出来;你的逻辑流程是不是输出得既清晰又全面?是那就打印出来带上,然后请求面试官给你一个机会讲讲;跟设计、开发是不是混得很好?是,那就讲讲你和跟他们相处好所在项目时进行时跟你带来的好处;······· 等等。或许能加一点分。所以只要面试聊得还是产品的问题都可以尽量拉到你所擅长的地方,结合你带的资料进行表述。如果HR聊得那些天花乱坠的话题那就只能看你发挥了。

      以上分析不一定符合你具体的情况,以上建议也不一定管用,因为大环境确实也是这样,否则也就不会想着写这边篇文章。最终解决还是靠你自己多加摸索,如果就靠这个简单的问答就能解决的话那你早就解决了,所以上面这些话也只是提供了一些分析的方向、思路。

      最后还是希望“知”这一块也一定要加强,以为它是“行”的天花板!

      来自广东 回复
    2. 多谢前辈

      来自北京 回复
  9. 模型很棒,学习了~

    来自上海 回复
  10. 说得有点道理,我觉得自己有点理论很多,但落地就千仓百孔;自己的经验缺乏是一方面,另一方面还因为公司的创始人没规划做事,一会儿这个需求,一会儿那个需求,没有明确的目标,有点扰乱计划,而且老总提的需求又不得不做

    来自广东 回复
    1. 这也是我们在“行”的过程当中碰到的困难,这也需要产品经理有个成长的过程。很多产品都会抱怨说公司的高层不听自己说的,那是因为自己的能力、看问题的深度还没有让那些高层觉得值得去听、去参考。需要当你成长到一定程度、剖析事情能跟他们在一个level、看问题能看到深层次逻辑的时候,他们才会去注意到你的意见。任何事情存在都是有他底层的道理。因此,建议我们还只能扮演执行角色的时候就想办法在当下情境条件做到自己能做到的最好程度,尽可能锻炼自己的能力,然后快速成长~~ 共勉~~

      来自广东 回复
    2. 公司老板的风格和我们还挺像,而且我们是老板做需求评审

      回复