时间: 2021-07-30 11:30:32 人气: 7 评论: 0
工作与生活都是实践、思考、学习三者螺旋式循环上升的过程。实践中遇到问题则思考，思考中碰壁就学习，学习了新知识又再运用到实践中去，如此循环，不断迭代自己，上升到新高度。
从毕业创业当产品经理到如今在C轮互联网公司当产品经理，工作三年有余，对思考、学习及实践有一些感悟，其中有自己思考，有些不免拾人牙慧，在9102年结束之际，借着眼睛手术后不能看电脑手机的契机，将自己的感悟表达出来，和大家探讨。
每天有一亿人教张小龙做产品，每天哪怕有一个人愿意指出我的不足就非常棒了。
对事物本质的思考各类书籍文章提及太多了，我自己对思考本质能力的理解是透过事物的表象看到事物最底层的逻辑。所有的事物归根结底是围绕着最底层的逻辑叠加层层表象；但叠加多层表象后，很多人就看不清，容易被表象所迷惑，作出错误的决策，造成损失。
以全民热衷的炒股为例：
当我们思考炒股的本质**发现：短期的股票买卖行为本质上是负和博弈（短期内不考虑股票分红且存在交易手续费）——即短期的股票买卖从概率上是亏钱行为。
那为什么还是有很多人热衷于此？
总结起来有三个表象：
对事物本质的思考和认知，**决定你的行动，最直接的损失是经济损失。而作为产品经理，如果不能够做到思考本质，就无法弄清用户的真实需求，做出来的功能无法解决用户的实际问题，用户用脚投票，结果就是弃你而去，最终是导致整个产品团队甚至整个公司的辛苦工作都白费。
产品经理只有不断追问、思考本质，才能够了解到用户的真正需求；归根结底，产品经理要研究的是人的行为及行为后的本质原因嘛。
那么我们在日常工作生活中该如何做到思考本质呢？
我自己的几个方式是：跳出惯性思维、推演事物的形成规律、多与人交流看大牛怎么说。
跳出惯性思维。这并不是一个形而上的概念，而是可实操的方法。若你试着留意一下自己平时的说法方式，**发现自己经常用到“……应该是这样的”，“我觉得……”，“肯定……”这类的话语，这些就是你掉入惯性思维的信号。不妨试着给自己设一道闸，当你想说出这样的话时，马上阻止自己，然后再仔细想想你真的如此肯定吗？你脱口而出的话语**牵引你的思维，口头的快感助长思维的懒惰，所以先从遇事停一停，想一想开始吧。
推演事物的形成规律。当你已经不在掉入惯性思维，下一步应该多问为什么。提出自己的假设，证实或证伪自己的假设，一层一层地往下问为什么，抽丝剥茧一般。例如，用户在某个页面没有如你所愿进行相关操作，可以提出很多假设：引导没做好？对用户的属性判断不对？流程设置不对？如果是引导没做好，那么需要怎样的引导？诸如此类，一层一层，不断提出问题，回答问题，最终发现事物的本质。
多与人交流，看大牛怎么说。每个人的思维方式难免固化，避免思维固化最好的方式就是不断有新的思路来给予刺激。日常可以多和他人就一个问题进行交流讨论，不怀对错心，而是了解对方是从哪个角度去思考问题的，出发点是什么。
我自己在生活中特别喜欢和各式各样的人天南地北地聊，菜市场大妈、建筑工人、滴滴司机……都是很好的聊天对象，聊起来非常有意思，他们或许不能给出高深的见解，但常常有拓宽认知边界的快感。
而对于大的行业问题，则可以看下行业大牛是怎么说的——他们往往深耕行业多年，经历过行业周期，经历过反复试错，有着更多实践和踩坑的经验，他们的见解，往往高屋建瓴，不妨和自己的认识作对比，有醍醐灌顶之感。
工作生活中，碰到一些大问题，**出能力范畴，我们难免措手不及，这时就需要有拆解问题思考。不断拆解问题能够帮助我们将大的问题分解成小的问题，帮助我们明晰路径、把握局部细节、看到潜在风险。
例如，产品经理在分析一个大的需求时，**按场景、用户、问题的方式来拆解需求，拆解成不同用户在不同场景下遇到的不同问题，拆解完成后便可以按各个细分场景逐个思考解决方案。
至于如何锻炼自己对问题的拆解能力，我认为是多积累一些方法论——因为你遇到的问题，其他人一定也遇到过。
正如上文提到的用户场景问题的拆解方法，已经是产品经理必备的方法论，其他诸如5W1H分析法、SWOT分析法、思维导图分析法等等，都可以从书籍或文章中习得，再在实践中不断熟练运用。
这其中有一本非常经典的书籍——《金字塔原理》，可作为工作的手边书，反复研读。
最早接触这个概念是在王诗沐的文章里，当时只是隐约记下，后来在处理多部门协同工作时，让我对这个概念有了更深的思考。
所谓要在发现问题之上的层面来解决问题（来自爱因斯坦的精辟总结），现实中每个部门都只**考虑到自身部门层面的利弊，如果没有人能够从更上一层的层面来思考利弊，那么部门之间的冲突便无法妥善处理，达成一致。
往上层思考是产品经理非常重要的思考能力，当作为一个产品助理时，负责的是一个个独立的功能点，如果只是纠结功能点层面的问题，**发现功能点之间逻辑不清，无法协同。
这时应该往上层思考，从模块层面看问题：功能点是归属于模块、为模块服务的，在模块层面看问题能够更好地把控功能点之间的协同，而不**纠结于单个功能点的好坏。
同理，负责功能模块时，就该思考整个产品的方向，负责整个产品时，就该从行业的角度看行业趋势产品的进退。
例如最近互金行业一轮洗牌，如果作为产品负责人不能够从行业角度看到国家整顿互金行业的决心与严厉程度，继续沉迷在产品层面追求产品功能的好坏，那么不可避免的就是产品功能可能非常好，但由于合规问题直接被下架，倒下的已太多。
深度思考是一个很好的习惯，但在思考中难免受困，有些问题**出了认知范畴，就需要不断学习新的知识。对于学习，以下几点我深感值得分享。
学习一项新知识最好的方式是什么？
本人愚见，认为是输出。
这个观念从我高中开始就深有体**，输出方式包括多种，由浅及深大概是：总结输出成文字、在多人面前展示自己的学习成果、应用到工作生活中以及将学到的东西教授给他人。
总结输出成文字，恐怕大家都不陌生，高中大学时期的做笔记就是这样一种输出方式，也就是把老师所讲的知识按自己的理解形成笔记，后面再时时复习；只不过工作之后，老师变成了可以是书籍、视频教程甚至是工作上的经验，但其底层逻辑是一样的。
在多人面前展示自己的学习成果。之所以强调多人，是因为多人**让你有压力把所学的东西理解透彻以面对复杂的现场，另外一点是，听众**在现场或之后给到你充分的反馈，而这些反馈能够补充你理解不到或不到位的地方。
应用到工作生活中能帮助更有效地学习，这是工作以来体**最深的一点。之前看一些产品经理写的书，不免嫌弃——这么简单也拿出来讲？到真正工作中要运用相关**，解决实际问题时，才**发现这也不到位，那也不到位。所以当学习新的知识技能时，不仿找到一些实际运用场景，在运用场景中实践书中所学，并且不断总结成自己的知识。
将学到的东西教授给别人，是又一个我获益匪浅的方法。
高中时，**有别人问你问题，在你解答的过程中，你**去思考怎么把知识点解释得简洁而透彻，有时被人问倒了，还**赶紧去恶补知识点（虚荣心也可以是个好东西）。每个人理解和考虑问题的角度太一样，在你教授的过程中，对于一个知识点，有来来回回的反复探讨，有多个角度的反复咀嚼，可以提升自己对知识点的领悟。
所以之所以现在写下这些文字，之后还**写，就是希望能够保持不断输出，不断获得反馈，不断有更深的理解。
这是最近看一些知识点丰富而杂的书时有所感悟，读完之后感觉自己的大脑突然吸收了一麻袋的知识点，但是毫无逻辑，自然在想用的时候也无法拿出来用。
这个时候，最好的方式是将凌乱的知识点结构化，我用的是思维导图加有道云笔记。思维导图用来将杂乱的知识点进行分类，分类的标准按自己需要，但思维导图只记录知识点名称这个层级，然后用有道云新建一个文件夹，用来写明知识点的具体概念加上自己在实际运用中的案例。
结构化之后，每隔一段时间，我**拿出思维导图，从根到叶逐个回忆这些知识点，看自己是否还记得这些知识点以及自己的运用案例，如果记忆模糊，就再拿出有道云笔记里面的内容重新复习。几次下来这个知识点在你脑中便很难忘记了。
学习到的内容，并不是一成不变的，在这个场景下适用的内容，在另一个场景下并不一定适用，因而即使对知识点已经掌握，也需要在实践过程中对学习的内容进行不断地迭代。
我所用的方式是不断地补充实际案例，正如上文所说，当我对学习的知识点进行结构化整理时，**用有道云记录知识点的内容及实际运用的案例，而每过一段时间，我**重新去思考这个知识点，看看自己对这个知识点有没有一些更新的领悟，已经此前的案例是否需要修改，是否有更新的更好的案例进行补充。
以上是我在学习方式上的一些思考，细看下来你**发现，这又是一个小的螺旋式上升。
当我们开始学习一个知识点时，不管是阅读还是看视频教程，它只是输入，然后我们把它进行结构化整理，然后尝试输出，在输出过程中**有新的思考和领悟，而这，又是一次崭新的输入。
子曰：学而时习之，不亦说乎！意思是说学到了东西，能够付诸实践，是件很快乐的事情，确实如此！不能付诸实践的知识是团废纸，但实践中也有些问题需要注意，我说说我的一些看法。
很多人在实践中，往往追求完美，不把事情做到尽善尽美不肯轻易展示，我认为这是很错误的做法。产品经理在设计一个产品时，有个通用的方法论是先做出MVP（最小可用产品），即我把产品的核心功能先做成简单可用的产品，放到市场上去验证想法对不对，然后根据用户的反馈不断调整。
在《刻意练习》一书中提到了有效反馈的重要性，就是告诉我们不要闭门造车，要尽快将beta版拿出来，让大家给予你有效的反馈，然后再进行不断迭代。
我们可以回头看看微信V1.0版本与现在的差距，如果张小龙要等到所有功能都做出来再发布，那就不**有今天的微信了。
日常我在写一个需求文档的时候，**先按当下我能考虑的情况先写一个Beta版，这时候我将它命名为V0.7版本，然后隔一天我再重新思考，看自己昨天写的需求文档，这时能发现很多不足的地方，那就从头开始改一遍，这时的版本是V0.8版本；下一步找其他产品经理向他讲述一遍这个需求文档或在组内组织一次需求评审，综合意见，再修改一遍，这时的版本是V0.9版本，最后再找开发测试的同学评审一遍，从开发测试的角度对需求文档做一遍修改，形成最终的版本V1.0。
在这里我并不是否认完美的重要性，而是说当我们在做一件事情的时候，囿于个人思考的局限性（当局者迷，而且往往对于自己做的东西有谜一般的自信），无法一开始就做到完美，如果你不先完成一个初始版本，可能就永远无法输出胎死腹中了。所以先输出一个完成品，结合他人的反馈不断调整优化，是个比输出完美方案更可行的策略，completion is better than perfection。
产品经理在日常的工作中常常要做决策，并且从实际来看，平庸和错误的决策占大多数，我们是在不断地实践，不断试错，最终找到最优的解决方案。而在此过程中，我认为保持头脑的极度开放、极度透明是极为重要的。所谓开放，是能够平等平静地接纳所有人的建议，所谓透明，是公开自己的决策依据和结果，不惧怕别人看到自己犯错。保持开放，你能够获得更多的有效的反馈，保持透明，你不**自欺，别人也**给你更诚实的反馈。
有的产品经理做实验，效果好就优化，效果差弃用；有的产品经理做实验，想尽办法证明自己实验效果好，然后优化。愿我努力做到前一种。
吾日三省吾身，反思是很多人**常做的事，但我认为更重要的是反思后的执行效率，反思后不执行的反思就是空想，自己对自己的扭捏作态，只有反思后把思考内容落到实处，才能达到反思的效果。看客不妨记录下自己反思后定下的执行方案以及最终的执行结果，可以计算出执行率=执行成功数/反思后得出的执行方案数，用这个数值来看看自己到底反思了些什么，想来**非常有趣！
这是梁宁女侠说的，一针见血。恐惧**困住一个人的手脚，一个人对事有恐惧时，所有的大道理于他而言皆无用。所以当你面对一件事情喜欢拖延、喜欢找借口、总往坏处想，可能不是别的原因，是你的恐惧在作祟。不妨时时告诉自己更勇敢些，哪怕是匹夫之勇，不管事情成不成，先干了再说，直面恐惧，后面的事情就容易多了（又是一个知易行难的大道理，哈哈哈哈哈哈）。
啰啰嗦嗦一大堆，到此算是写完，第一次写，能写完很满意，希望各位看客多提意见，本人脸皮厚，不怕批评。
以上纯属，随便写写，如有雷同，算我抄你。
本文由 @Isaac 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
