这是《进阶之路》系列的第二篇，我已拟好一个主题列表，计划后续不断完善这个系列。半年前我写了一篇《进阶之路：站在高视角看产品是一种怎样的体验？》，尝试与更多PM们一起开始探讨高级别产品经理的思维方式。我希望后续的系列讨论中，逐步剖析各种关于产品的思考，成功和失败的经验和教训，帮助更多的产品人逐步进阶。 既然这是一个系列文章，我并没有计划罗列一个足够全面的提纲，我怕自己会因为有了提纲而漏掉什么更重要的观点。所以在这个系列文章中，每一篇文章的观点都会显得随机一些，但我可以保证的是，内容绝对干货，不拖泥带水。 一些机缘巧合，我开始认真回顾与总结自己的产品思路，翻看我做过的事情，复盘我帮别人分析过的事情，追溯我思考过的细节，回忆我与其他人的交流与分享……我逐渐发现，这里面的道理竟是如此之多，但是在行事中却很难将这些宝贵的道理学以致用。正如我们很多人，听了那么多道理，可是依旧做不好产品。 我把这种现象称之为“知道什么是正确的事，却不知该如何正确地做事”。 如何正确地做事并不容易，并不是因为我们缺乏正确地做事的方法论，而是在具体落实到我们工作中时，我们缺乏举一反三的能力。因地制宜的实施方法论是一件极其困难的事情，我曾经认真学习了别人做内容运营的方法论，依然很难在实际工作中做到完美。 所以，我开始认真思考，为什么道理我们都懂，却始终做不好产品？
道理不过脑，听了也是白听
听起来有道理的，你还得好好再想想
我举一个有趣的例子。 前段时间有个PM跟我说了一个道理：“任何的产品未经验证之前，都不该贸然投入资源和市场，应该去市场里验证，然后再做定夺。”这是某书中的道理，乍一听很有道理，的确应该验证用户需求，验证市场，然后再投入精力。在很多产品团队中，大家都很喜欢做用户调研，听取用户的反馈。曾经有本书中提到惠普当年的CEO花费了上千小时和客户泡在一起，听取客户的意见和反馈。 这些道理自然而然地汇聚成了这位PM和我说的这句话，我们不该贸然行动，应该去问问用户和客户。 但我很快就反驳了他，原因有三个：
- 首先，我们不能确定我们有多少用户。我们究竟该听取100人的意见，还是10000人的意见？抽样的结果一定准确无误吗？这些都不能确定。
- 其次，我们作为PM，应该首先尝试站在用户视角去认真分析所有的可能。如果我们需要解决一个100分的问题，依靠我们一群臭皮匠的深入分析和求证，至少我们可以解决80分。剩下的20分，我们起码也需要有一个不确定的答案。
- 最后，我们向用户去求证的是剩下的20分不确定的答案。我们要带着准备好的东西去求证，也就是需要拿出一个version 0.9的产品去测试求证，迅速调整。如果你自己都没有想清楚，你指望从用户那里拿答案，那么你拿回来的也是混乱不堪的各种观点。
忽略了道理的核心，就会舍本逐末
我记得5年前我初入微软时，在那里的外企环境中，BrainStorm（头脑风暴）是一件很酷的事情，大家各抒己见、滔滔不绝，而主持者往往也是热血沸腾，往往都聊得不亦乐乎。 当年我被灌输了一个道理：新产品在立项之前都需要一次集体的BrainStorm，目的是邀请权威且有能力的其他PM一起来拍砖讨论，在进行设计之前得到大家的经验帮助，从而提升产品的成功率。这又是一个“乍一听很有道理”的道理，但实则是一个彻头彻尾的强盗逻辑。 BrainStorm的目的不是让大家来出主意的，而是带着准备充分的背调和问题，采集大家的意见，微调自己的观点，进而形成知识库来支撑后续的工作。 如果我是一个新产品的负责人，若我把最大的期望寄托于BrainStorm，那么可能带来的结果是：在BrainStorm会议上，我觉得A说得很有道理，B说得也不错，C虽然和他们的结论恰好相反，却也十分中肯有意义。一场一小时的BrainStorm之后，我听得很过瘾。但事后我会发现，我好像什么也没得到，我并不能很有效地明白该怎么继续接下来的产品设计。 原因很简单：作为产品负责人的我，如果我已经花费数十个小时的时间来认真分析用户、分析需求、分析功能设计，依然不能搞定产品设计，凭什么其他的PM在BrainStorm会议上几十分钟的畅谈能够一下子把问题讲清楚？ 换句话说，如果我不花费数十个小时的努力，不是带着一大堆问题来找大家一起来讨论，不在开会前要求其他人先准备一些背景资料再来讨论，我如何能保证这一小时的BrainStorm的讨论是有效的呢？ 这就是为什么很多大公司开了一大堆的会，却效率颇低。大家搞了一大堆的BrainStorm，但收效甚微。我们太习惯搞时髦了，太喜欢追随哪些看起来很有道理的道理，进而忽略了这个道理本源的核心。
听了道理，却未能坚持贯彻始终
有时候道理听多了，就忘了做事情的原始初心了。追随一个道理，一定需要确立正确的目标，然后带着目标有目的地做事情。 我们在工作中做每件事情都需要带有目的，无论是产品、研发、运营、市场、设计或者哪怕是维系人际关系。在职场上，我们每个人都是利益纠结体，没有目的就没有做事情的欲望，也就无法为结果负责，没有人来到职场里是为了做公益善事。 可是我们中的很多人并不明白这个简单的道理。 我举一个例子： 假如一位PM需要设计一个开放平台产品，那么他可能会遇到一些麻烦事。 开放平台是一个和技术关联比较深刻的产品，他在设计的过程中，最经常遇到的问题是——如何和技术团队确定开放平台的架构、如何确定某个功能能否通过技术实现、如何驱动前后端技术团队在开放平台接口层面保持一致。几乎任何ToB的产品在系统架构层面上的讨论都会耗时耗力。 那么，这个产品经理可能会在工作中变成怎样呢？他可能会陷入和技术团队研讨技术解决方案，甚至可能会开始享受这种参与技术讨论的快感，他可能会为解决了某个技术难题而感到兴奋快乐，他可能会成为其他PM崇拜的偶像，因为毕竟不是所有的PM都有能力和技术团队讨论技术方案，这种关于系统架构的讨论，的确是一件快乐而美妙的事情。 但是，这些该是这位PM做这个平台产品的初心目的吗？显然不是。 当一个PM把经历花费在技术层面时，他已经把自己的目的完全跑偏了。作为产品经理，他的目的在任何时候都是为用户负责，设计产品的思路从来不是优先考虑技术方案，而是产品是否能够快速解决用户的问题。 作为一个开放平台，它的用户显然都是个人或企业开发者，PM的工作是确保这些开发者能够快捷便利地使用开放平台快速完成一个Demo的搭建，并且快速发布，以及后续的一些列在运营和营销层面的支持。为什么PM的关注点应该是这些呢？原因很简单，因为PM要为产品的成败负责，产品要有人用，PM需要想尽一切办法来解决用户的问题，PM关注的点永远是“我的产品有多少人在用，还能有多少人用，还能有多好用”。 其实我们很容易在琐碎事情中，逐渐就忘了当初为什么做这件事情了。在大公司时候，忙着抢夺资源打起口水仗来，就忘了当初为什么做这件事；在小公司里一个PM承担了产品、运营甚至培训师，一旦忙碌起来就什么初衷都不记得了。 在执行中跑偏几乎是我们的通病，特别是我们抗压能力、经验积累、知识存储都不够充分时，容易把自己淹没在了不停歇的状态中，难以坚定地确保在具体工作中，始终坚持目标。 在这里再次安利我的偶像导师王阳明先生的那一句话——此心不动，随机而行。道理不该是脑子记住的，而应该靠基因记住
曾经有一个明星企业的CEO大佬跟我说了一句话，他说：“好的PM应该把用户为先这句话记在基因里，而不是脑子里。”我当时被深深地shock到了，虎躯一震。 让道理深入骨髓，进入基因是一件极其困难的事情，我开始思考到底怎样才算深入基因。 如果把PM的能力分级，第一级别PM是看问题始终不得要领，只能执行，却不知道如何分析；而第二级别PM是能够通过自己的逐步剖析逐渐看清楚问题的本质；最高级的第三级别PM是那种一眼到底的人，一眼就能看出问题的关键症结。 我想我们中的大多数人都处在前两个级别，更多人尚处在第一级别。 我认为第三级别PM就是那种用基因来记忆道理的，也就是我们所说的直觉，我见识过一个投资人，他对很多问题的认知都是直觉很准很狠，比如他直言医疗的本质就是“疗效”。拥有这种能力的人，需要经历非常久的经验积累，这大概就是我们所听说过的“十万小时理论”的结果。在《眨眼之间》这本书中，关于这种能力的案例记载了一大堆。 我们如果想通过基因来记忆道理，我认为需要做好三件事情：
其一，不断地总结
无论是多大多小的一件事情，都值得总结。 总结未必是非常有仪式感地记录下来，在脑海中碎片化总结的好习惯也是一种很不错的方式。我自己经常在讨论中、思考中、实践中进行碎片化总结，把看到的事情复盘一遍，又复盘一遍。我特别喜欢带着团队做复盘，回顾过去的成败得失。 但我发现很多团队的复盘都是流水账，形式大于实质。 我们需要奖励做得好的事情，同样需要严厉惩罚做得差的事情。总结的目的是吸取教训，获得经验知识，下一次不再犯相同的错误，为了总结而总结自然本末倒置。 总结的关键是看我们是否达到了当初定下的目标，是否已经完成了既定任务，是谁的锅谁就老老实实背好，是谁在为其他人填坑就该拉出来表扬（决策性错误就该怪罪老大，执行力不强既是老大的锅，也是执行人的问题）。 每一次深刻地总结都是将这些经验教训深深地烙在我们的骨髓里，深刻而认真地理解失败和成功。我认为，一次深刻的总结不亚于一次伟大的成功或者残酷的失败。其二，不断地学习
我把学习成长分为三种：- 最差的一种是听别人讲，道理似乎都懂，但是该是别人的道理还是别人的道理，自己领悟个十分之一已是难得；
- 居中的一种是观察别人的成败，总结经验教训，把自己武装成有知识的理论派；最好的是自己亲身经历，无论成败，坑里坑外都是自己的，每一步都顶的上别人千言万语，知行合一。
其三，不断地实践
实践永远是检验真理的唯一途径。 举一个例子： MVP（Minimum Viable Product，最简化可实行产品）是几乎每个PM都明白的道理，但是做好MVP却相当难，我自己也是掉进坑里很多次。MVP强调的是最小单元的产品，最小代价的试用，最快速反馈调整，可以理解为打了一个小样Demo丢给市场来看反馈。 可是，在做MVP之前，我们对市场情况一无所知，到底哪个才是MVP是相当考验功力的。此外，当我们做起来MVP时，却经常因为不同团队对于MVP理解不一致，目标不一致，资源不匹配，市场环境不可预期等等原因难以快速落实。 这些实际发生的事情是在道理讲解中从来不会有人告诉你的，你真的掉进坑里了才会发现事情竟然如此复杂，在实践中真正考验的除了对于道理的理解和认知，还有自己随机应变的能力。 唯有实践之后才有可能去总结，我并不爱听从无实战经验的咨询师的经验，没有实战经验的老师的话也没有多大的分量。小结
在这篇文章中我讨论了关于道理的一系列基本观点，从需要深入理解道理，到贯彻始终地坚持左右目标的事情，最后分享了讲道理融会贯通的三个方法。 这篇文章是我《进阶之路》系列的第二篇，但关于“道理”这个话题，我希望在后续的文章中继续讨论几个回合。我会逐渐讨论一些更加深入的观点，譬如，“同样是道理，视角不同理解各异”，“作为PM，如何通过可控来落实道理”，等等。 如我在文初提到的，我希望这个系列文章能够帮助我和其他PM朋友们在工作中保持专注，一起解决我们遇到的各种棘手的问题。欢迎交流~相关阅读
进阶之路：站在高视角看产品是一种怎样的体验？#专栏作家
帅帅的帅（赵帅），“优护家” 联合创始人兼COO；前微软小冰初创团队产品经理；北京大学计算机系硕士。专注产品、运营和商业的分析，热衷产品方法论的总结。热爱足球、民谣音乐、吉他弹唱、软笔书法、阅读和旅游，热爱生活。 本文原创发布于人人都是产品经理。未经许可，禁止转载。 题图来自 PEXELS，基于 CC0 协议 爱盈利-运营小咖秀 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容；是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台；【转载说明】 若上述素材出现侵权，请及时联系我们删除及进行处理：8088013@qq.com
