题图来自 Unsplash，基于 CC0 协议

全文共 4368 字，阅读需要 9 分钟

—— BEGIN ——

一些机缘巧合，我开始认真回顾与总结自己的产品思路，翻看我做过的事情，复盘我帮别人分析过的事情，追溯我思考过的细节，回忆我与其他人的交流与分享。

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

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

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

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

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

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

听起来有道理的，你还得好好再想想：

我举一个有趣的例子。

前段时间有个PM跟我说了一个道理，他说：

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

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

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

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

但我很快就反驳了他，原因有三个：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我举一个例子。

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

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

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

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

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

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

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

显然不是。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 第一级别产品经理，是看问题始终不得要领，只能执行，却不知道如何分析

• 而第二级别产品经理，是能够通过自己的逐步剖析逐渐看清楚问题的本质；

• 最高级的第三级别产品经理，是那种一眼到底的人，一眼就能看出问题的关键症结。

我想我们中的大多数人都处在前两个级别，更多人尚处在第一级别。

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

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

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

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

其一，不断地总结

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

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

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

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

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

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

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

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

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

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

其二，不断地学习

我把学习成长分为三种：

• 最差的一种是听别人讲，道理似乎都懂，但是该是别人的道理还是别人的道理，自己领悟个十分之一已是难得；

• 居中的一种是观察别人的成败，总结经验教训，把自己武装成有知识的理论派；

• 最好的是自己亲身经历，无论成败，坑里坑外都是自己的，每一步都顶的上别人千言万语，知行合一。

如此看来，最好的学习是自我总结，次之是不断阅读，最差是找人聊天。

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

其三，不断地实践

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

举一个小栗子。

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

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

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

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

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

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

小结

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

—— END ——