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

2017-12-25

    一些机缘巧合,我开始认真回顾与总结自己的产品思路,翻看我做过的事情,复盘我帮别人分析过的事情,追溯我思考过的细节,回忆我与其他人的交流与分享。我逐渐发现,这里面的道理竟是如此之多,但是在行事中却很难将这些宝贵的道理学以致用。我们很多人,听了那么多道理,可是依旧做不好产品。我把这种现象称之为“知道什么是正确的事,却不知该如何正确地做事”。

    如何正确地做事并不容易,并不是因为我们缺乏正确地做事的方法论,而是在具体落实到我们工作中时,我们缺乏举一反三的能力。因地制宜地实施方法论是一件极其困难的事情——我曾经认真学习了别人做内容运营的方法论,依然很难在实际工作中做到完美。所以,我开始认真思考:为什么道理我们都懂,却始终做不好产品?道理不过脑,听了也是白听听起来有道理的,你还得好好再想想:我举一个有趣的例子。

    前段时间有个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理解不一致,目标不一致,资源不匹配,市场环境不可预期等等原因难以快速落实。这些实际发生的事情是在道理讲解中从来不会有人告诉你的,你真的掉进坑里了才会发现事情竟然如此复杂;在实践中真正考验的除了对于道理的理解和认知,还有自己随机应变的能力。唯有实践之后才有可能去总结,我并不爱听从无实战经验的咨询师的经验,没有实战经验的老师的话也没有多大的分量。


上一篇:产品转型凭借什么呢?

下一篇:创业公司产品经理学习