道理我们都懂,却始终做不好产品

 

知道什么是正确的事,却不知该如何正确地做事...

题图来自 Unsplash,基于 CC0 协议

全文共 4368 字,阅读需要 9 分钟
—— BEGIN ——
一些机缘巧合,我开始认真回顾与总结自己的产品思路,翻看我做过的事情,复盘我帮别人分析过的事情,追溯我思考过的细节,回忆我与其他人的交流与分享。

我逐渐发现,这里面的道理竟是如此之多,但是在行事中却很难将这些宝贵的道理学以致用。

我们很多人,听了那么多道理,可是依旧做不好产品。

我把这种现象称之为“知道什么是正确的事,却不知该如何正确地做事”。

如何正确地做事并不容易,并不是因为我们缺乏正确地做事的方法论,而是在具体落实到我们工作中时,我们缺乏举一反三的能力。

因地制宜地实施方法论是一件极其困难的事情——我曾经认真学习了别人做内容运营的方法论,依然很难在实际工作中做到完美。

所以,我开始认真思考:为什么道理我们都懂,却始终做不好产品?

道理不过脑,听了也是白听

听起来有道理的,你还得好好再想想:

我举一个有趣的例子。

前段时间有个PM跟我说了一个道理,他说:

任何的产品未经验证之前,都不该贸然投入资源和市场,应该去市场里验证,然后再做定夺。

这是某书中的道理,乍一听很有道理,的确应该验证用户需求,验证市场,然后再投入精力。

在很多产品团队中,大家都很喜欢做用户调研,听取用户的反馈。

曾经有本书中说到:惠普当年的CEO花费了上千小时和客户泡在一起,听取客户的意见和反馈。

这些道理自然而然地汇聚成了这位PM和我说的这句话:我们不该贸然行动,应该去问问用户和客户。

但我很快就反驳了他,原因有三个:

首先,我们不能确定我们有多少用户。我们究竟该听取100人的意见,还是10000人的意见?抽样的结果一定准确无误吗?这些都不能确定。

其次,我们作为PM,应该首先尝试站在用户视角去认真分析所有的可能。如果我们需要解决一个100分的问题,依靠我们一群臭皮匠的深入分析和求证,至少我们可以解决80分——剩下的20分,我们起码也需要有一个不确定的答案。

最后,我们向用户去求证的是剩下的20分不确定的答案。我们要带着准备好的东西去求证,也就是需要拿出一个version 0.9的产品去测试求证,迅速调整。

如果你自己都没有想清楚,你指望从用户那里拿答案,那么你拿回来的也是混乱不堪的各种观点。

这三个原因归结起来便是“精益创业”的核心——在具体做事时,我们并不是需要通过各种道理来故步自封,而是需要审时度势,一步一步小心求证;在这个过程中,我们很清楚自己的观点和目标,不盲从道理。

显然这位PM同学只是听说了这个道理,但他并没有搞明白这个道理的核心。

道理并不是听听就过去了,你不假思索就贸然行动,可能得不偿失——孔夫子强调的三思而后行,便是这个道理。

讲到这里,我突然想起我的偶像导师王阳明先生的一句话——此心不动,随机而行。

忽略了道理的核心,就会舍本逐末

我记得5年前我初入微软时,在那里的外企环境中,BrainStorm(头脑风暴)是一件很酷的事情,大家各抒己见滔滔不绝,而主持者往往也是热血沸腾,往往都聊得不亦乐乎。

当年我被灌输了一个道理:

新产品在立项之前都需要一次集体的BrainStorm,目的是邀请权威且有能力的其他PM一起来拍砖讨论,在进行设计之前得到大家的经验帮助,从而提升产品的成功率。

这又是一个乍一听很有道理的道理,但实则是一个彻头彻尾的强盗逻辑。

BrainStorm的目的不是让大家来出主意的。而是带着准备充分的背调和问题,采集大家的意见,微调自己的观点,进而形成知识库来支撑后续的工作。

如果我是一个新产品的负责人,若我把最大的期望寄托于BrainStorm,那么可能带来的结果是:

在BrainStorm会议上,我觉得A说得很有道理,B说得也不错,C虽然和他们的结论恰好相反,却也十分中肯有意义。

一场一小时的BrainStorm之后,我听得很过瘾。

但事后我会发现:我好像什么也没得到,我并不能很有效地明白该怎么继续接下来的产品设计。

原因很简单:作为产品负责人的我,如果我已经花费数十个小时的时间来认真分析用户、分析需求、分析功能设计,依然不能搞定产品设计,凭什么其他的产品经理在BrainStorm会议上几十分钟的畅谈能够一下子把问题讲清楚?

换句话说:如果我不花费数十个小时的努力,不是带着一大堆问题来找大家一起来讨论,不在开会前要求其他人先准备一些背景资料再来讨论,我如何能保证这一小时的BrainStorm的讨论是有效的呢?

这便是为什么很多大公司开了一大堆的会,却效率颇低,大家搞了一大堆的BrainStorm,但收效甚微。

我们太习惯搞时髦了,太喜欢追随哪些看起来很有道理的道理,进而忽略了这个道理本源的核心。

听了道理,却未能坚持贯彻始终

有时候道理听多了,就忘了做事情的原始初心了。

追随一个道理,一定需要确立正确的目标,然后带着目标有目的地做事情。

我们在工作中做每件事情都需要带有目的,无论是产品、研发、运营、市场、设计或者哪怕是维系人际关系。

在职场上,我们每个人都是利益纠结体,没有目的就没有做事情的欲望,也就无法为结果负责——没有人来到职场里是为了做公益善事。

可是我们中的很多人并不明白这个简单的道理。

我举一个例子。

假如一位PM需要设计一个开放平台产品,那么他可能会遇到一些麻烦事:

开放平台是一个和技术关联比较深刻的产品,他在设计的过程中,最经常遇到的问题是——如何和技术团队确定开放平台的架构、如何确定某个功能能否通过技术实现、如何驱动前后端技术团队在开放平台接口层面保持一致。

几乎任何ToB的产品在系统架构层面上的讨论都会耗时耗力。

那么,这个产品经理可能会在工作中变成怎样呢?

他可能会陷入和技术团队研讨技术解决方案,甚至可能会开始享受这种参与技术讨论的快感。

他可能会为解决了某个技术难题而感到兴奋快乐。

他可能会成为其他PM崇拜的偶像,因为毕竟不是所有的PM都有能力和技术团队讨论技术方案——这种关于系统架构的讨论,的确是一件快乐而美妙的事情。

但是,这些该是这位PM做这个平台产品的初心目的吗?

显然不是。

当一个产品经理把精力花费在技术层面时,他已经把自己的目的完全跑偏了。

作为产品经理,他的目的在任何时候都是为用户负责;设计产品的思路从来不是优先考虑技术方案,而是产品是否能够快速解决用户的问题。

作为一个开放平台,它的用户显然都是个人或企业开发者,产品经理的工作是:确保这些开发者能够快捷、便利地使用开放平台快速完成一个Demo的搭建,并且快速发布,以及后续的一些列在运营和营销层面的支持。

为什么产品经理的关注点应该是这些呢?

原因很简单:产品经理要为产品的成败负责。

产品要有人用,PM需要想尽一切办法来解决用户的问题,PM关注的点永远是:

我的产品有多少人在用,还能有多少人用,还能有多好用。

其实我们很容易在琐碎事情中,逐渐就忘了当初为什么做这件事情了。

在大公司时候,忙着抢夺资源打起口水仗来,就忘了当初为什么做这件事;

在小公司里,一个产品经理承担了产品、运营甚至培训师,一旦忙碌起来就什么初衷都不记得了。

在执行中跑偏几乎是我们的通病。特别是我们抗压能力、经验积累、知识存储都不够充分时,容易把自己淹没在了不停歇的状态中,难以坚定地确保在具体工作中,始终坚持目标。

在这里再次安利我的偶像导师王阳明先生的那一句话——此心不动,随机而行。

道理不该是脑子记住的,而应该靠基因记住

曾经有一个明星企业的CEO大佬跟我说了一句话,他说:

好的PM应该把用户为先这句话记在基因里,而不是脑子里。

我当时被深深地shock到了,虎躯一震。

让道理深入骨髓,进入基因是一件极其困难的事情,我开始思考到底怎样才算深入基因。

如果把产品经理的能力分级:

  • 第一级别产品经理,是看问题始终不得要领,只能执行,却不知道如何分析
  • 而第二级别产品经理,是能够通过自己的逐步剖析逐渐看清楚问题的本质;
  • 最高级的第三级别产品经理,是那种一眼到底的人,一眼就能看出问题的关键症结。
我想我们中的大多数人都处在前两个级别,更多人尚处在第一级别。

我认为第三级别的产品经理,就是那种用基因来记忆道理的——也就是我们所说的直觉。

我见识过一个投资人,他对很多问题的认知都是直觉很准很狠,比如他直言医疗的本质就是“疗效”——拥有这种能力的人,需要经历非常久的经验积累,这大概就是我们所听说过的“十万小时理论”的结果。

在《眨眼之间》这本书中,关于这种能力的案例记载了一大堆。

我们如果想通过基因来记忆道理,我认为需要做好三件事情。

其一,不断地总结

无论是多大多小的一件事情,都值得总结。

总结未必是非常有仪式感地记录下来,在脑海中碎片化总结的好习惯也是一种很不错的方式。

我自己经常在讨论中、思考中、实践中进行碎片化总结,把看到的事情复盘一遍,又复盘一遍。

我特别喜欢带着团队做复盘,回顾过去的成败得失。

但我发现很多团队的复盘都是流水账,形式大于实质。

我们需要奖励做得好的事情,同样需要严厉惩罚做得差的事情。

总结的目的是吸取教训,获得经验知识,下一次不再犯相同的错误,为了总结而总结自然本末倒置。

总结的关键是看我们是否达到了当初定下的目标,是否已经完成了既定任务;是谁的锅谁就老老实实背好,是谁在为其他人填坑就该拉出来表扬;决策性错误就该怪罪老大,执行力不强既是老大的锅,也是执行人的问题。

每一次深刻地总结都是将这些经验教训深深地烙在我们的骨髓里,深刻而认真地理解失败和成功。

我认为:一次深刻的总结不亚于一次伟大的成功或者残酷的失败。

其二,不断地学习

我把学习成长分为三种:

  • 最差的一种是听别人讲,道理似乎都懂,但是该是别人的道理还是别人的道理,自己领悟个十分之一已是难得;
  • 居中的一种是观察别人的成败,总结经验教训,把自己武装成有知识的理论派;
  • 最好的是自己亲身经历,无论成败,坑里坑外都是自己的,每一步都顶的上别人千言万语,知行合一。
如此看来,最好的学习是自我总结,次之是不断阅读,最差是找人聊天。

但这不代表你只做总结就好——阅读和从别人处汲取都能帮自己拓宽眼界,听课、参加培训、找大牛“系统性地”聊天都是有价值的;但重要的是一定要把这些有价值的道理融会贯通,总结为自己的道理。

其三,不断地实践

实践永远是检验真理的唯一途径。

举一个小栗子。

MVP(Minimum Viable Product,最简化可实行产品)是几乎每个PM都明白的道理,但是做好MVP却相当难,我自己也是掉进坑里很多次。

MVP强调的是最小单元的产品,最小代价的试用,最快速反馈调整,可以理解为打了一个小样Demo丢给市场来看反馈。

可是,在做MVP之前,我们对市场情况一无所知,到底哪个才是MVP是相当考验功力的。

此外,当我们做起来MVP时,却经常因为不同团队对于MVP理解不一致,目标不一致,资源不匹配,市场环境不可预期等等原因难以快速落实。

这些实际发生的事情是在道理讲解中从来不会有人告诉你的,你真的掉进坑里了才会发现事情竟然如此复杂;在实践中真正考验的除了对于道理的理解和认知,还有自己随机应变的能力。

唯有实践之后才有可能去总结,我并不爱听从无实战经验的咨询师的经验,没有实战经验的老师的话也没有多大的分量。

小结



在这篇文章中我讨论了关于道理的一系列基本观点,从需要深入理解道理,到贯彻始终地坚持左右目标的事情,最后分享了讲道理融会贯通的三个方法。
—— END ——
点击“阅读原文”下载APP


    关注 人人都是产品经理


微信扫一扫关注公众号

0 个评论

要回复文章请先登录注册