本源思维

我们在很多地方可能都看到过类似的表述：做产品经理要善于独立思考。

起初我总是不以为然，但等我真正的上手产品工作两年之后，才发现“独立思考”真的很重要。

在这个人人都自以为是产品经理的时代，是个人都会向我们发表一大堆建议与意见，如果我们缺少独立思考的能力，就会被他人的言辞以及事物的表面现象所蒙蔽。而独立思考最核心的就是“透过现象看本质”。

本源思维也就是刨根问底、实事求是的思维。

高级产品经理要善于思考事物的背后逻辑以及问题的根本原因，不能被表面的现象所迷惑。

举个例子：

很多用户都会吐槽“淘宝”APP设计的不够简约、过于眼花缭乱，淘宝在购物车页面、订单页面、物流页面、结算页面等地方都会添加“你可能还喜欢”的相关商品推荐，实在是有过度营销的嫌疑。

但是作为产品经理我们就要思考了：

◈ 淘宝这么做的目的是什么？

◈ 它是从哪些维度来思考这个事情的？

◈ 它到底是有损用户体验，还是会提升相关转化数据？

等等。

为了搞清楚这些问题，我曾专门请教过一个阿里的资深运营，对方给出的答案是：

阿里经过大数据分析发现，用户在浏览某个商品页面六次以后会大幅度的提升购买意愿，所以淘宝才会想尽一切办法的添加“你可能还喜欢”的商品推荐，目的就是让用户尽快的达到六次浏览，从而提升产品的购买转化率。而且实际的数据已经证明这个做法对于提升用户的购买转化率非常有效。

本源思维需要经常性的思考以下几个问题：

看到的究竟是事物的现象还是原因？
这件事情的原因到底有哪些？根本原因又是什么？
如何确定这是根本原因？
如何去建立假设？如何去验证？如何去优化？用什么方法？
……

阶段性思维

阶段性思维可以通用到很多事情上，小到个人的提升、大到国家的发展都需要分清楚阶段。

在不同的阶段需要做不同的事情，有些事情在某些阶段做是正确的，但是跨越了这个阶段去做就可能变成了错误的。

传统的产品生命周期理论将产品大致分为了四个阶段：启动阶段、成长阶段、成熟阶段和衰退阶段。

到了互联网时代，可能部分产品并不会进入“衰退阶段”，而是演化成了“生态系统”（比如微信、QQ、支付宝等）。

弄清楚自己产品当前所处的的阶段，才能搞清楚当前阶段的重点、做事情才能有的放矢。

很多初创团队的产品经理喜欢寻找对标产品，有时候会误把一些国民级的产品拿来和自己对标，让人啼笑皆非。

我就听我家程序员说过，他上家公司的产品经理在开发一个新的阅读产品时，要求他们照抄“微信阅读”，这一决定直接激怒了所有程序员，最终遭到程序员们的联合抵制。

要知道：支付宝、微信、淘宝、高德地图等等国民级的产品会精细化的打磨每一个体验细节，这是因为这些产品已经进入成熟期和稳定期，产品本身的需求已经被验证、且用户体量非常大，细节的打磨对于提升产品数据也非常的重要。

而创业团队的产品大多处于启动初期，这个阶段的主要目的是进行需求的验证，花大量时间和精力在产品的打磨上就有点本末倒置了。所以我们当然可以去研究和分析一些国民级的产品，但是不分阶段的去效仿和照搬，就是真愚蠢了。

阶段性思维具体需要我们思考以下几个问题：

当前产品处于什么阶段？
当前阶段的目标是什么？
当前阶段的重点是什么？非重点是什么？
……

颗粒度思维

颗粒度不同东西，可能是不同的事物。

举个例子：

我上初中时，QQ空间特别风靡，当时QQ空间的说说、日志等产品，限制的字数大概是10000字。同时期的新浪博客，限制字数是20000字。

——通过这些字数限制可以推断出当时的产品更强调内容表达的完整性和连贯性。

后来随着互联网的快速发展以及移动互联网的兴起，人们没有那么多时间和耐心去写长内容了，碎片化的“微博”就应运而生，字数限制是140字。

可以看到，同样是内容的传播，不同的字数限制（颗粒度）就是不同的产品，其目标群里、传播度可能就完全不同了。

作为产品经理也有必要思考自己所负责产品的颗粒度，因为颗粒度和产品的尝试成本是相关的，写一篇10000字的博客，需要我们静下心来，找个安静的地方梳理思绪，甚至还需要打个草稿。

但是微博的140字就非常简单了，随时划开手机就可以发表。

就拿我说从事的心理咨询服务行业来说，通常的线下心理咨询服务都是50分钟/次，开始我做产品时也是坚守的50分钟/次的设定，后来为了降低尝试成本、激活需求，在经过广泛的调研和分析后，我把产品的首次尝试时间改为了15分钟/次，愿意尝试的用户比例瞬间就扩大了1倍以上。

——这告诉我们，同样的内容，颗粒度变了可能产品的本质就变了。

颗粒度思维需要我们具体思考以下几个问题：

你所处的行业当前有哪几种颗粒度的产品？
你所做的产品的颗粒度是什么？
如何通过变化颗粒度改变产品的形态？
……

精确化思维

稍微观察一下，我们就会发现：日常生活中，人们普遍喜欢使用概括性的词汇：比如“好好工作”、“能力还不够”、“体验需要更好点”、“设计感不是那么强”等等。

人们为什么这么喜欢”概括性的表达“了？

我分析原因大概有以下几点：

空泛性的词汇所需要的思考成本较低、表达难度较小；
空泛的词汇更容易以偏概全、让人站在道德制高点上，产生优越感；
我们从小都是在空泛的词汇中长大，潜移默化的形成了这种沟通的模式。

作为产品经理，我们会收到来自各方的信息，这个时候就必须用精确化的思维对信息进行分析和确认。

举个例子：

运营向我们反馈“XX用户登录不APP，需要让技术解决一下“。

这个时候我们就应当询问：什么时间登录不上的？用户的是什么手机型号？手机型号的系统版本？软件的版本？登录不上是直接闪退还是有错误提示？等等。

只有把问题搞清楚了、定义清楚了，再去解决问题，才会比较高效。

在表达的时候，我们也应当尽可能的做到精确，我发现很多人在表述的时候为了强调自己的观点会用“夸张”的手法去描述，这样不仅不利于实际问题的讨论、也会给人形成一种不太靠谱的印象。

精确化思维需要我们从以下几个维度去思考问题：

问题的具体定义是什么？
问题的描述时、个人的表达时是否做到了足够的精确？
他人向你传递的信息是精确的吗？其中有夸张的成分吗？
在讨论时是否是精确的就事论事，而非空泛的以偏概全？
……

最小化产品思维

最小化产品的概念是硅谷创业家Eric Rise在其著作《精益创业》中提出来的，后被互联网公司广泛的接受和应用。

这可以说是产品经理的基础性思维之一，适用于很多种情况：双方针对产品的某些方面争执不下时；自己有了某些灵感或者想法，但不知是否应当进行大规模推行时；老板给了指令，自己有反对意见，但又不得不执行时……都可以进行MVP尝试。

尤其是当我们身处于创业团队，时间成本是很高的，这时我们更应当有最小化产品的思维，在很多产品的功能上进行小步快跑、快速迭代、搜集反馈、验证假设，而尽量避免闭门造车。

这种思维在很多文章里有相关的论述，我就不再展开讲了；作为产品经理，如果你的大脑中还不具备这种思维方式，你应该好好反省了。

系统性思维

系统性思维就是从整体的角度对事物进行全面的、多维度的、深入的分析，这是高级产品经理必须掌握的一种思维方式。

教育心理学在对“专家”和“新手”的对比研究时发现，他们两者的本质区别是：专家的思维方式是系统性的、全面的，而新手的思维方式则是零散的、片面的。

我们作为产品经理，是整个产品、甚至可以说是整个行业的专家，也应当建立自己极强的专业性。

举个例子：

我打算把平台上某个产品的品类价格进行上涨，普通的人可能仅仅考虑到”价格上涨后对用户购买行为的可能会产生负面影响“这个层面就够了。

但是作为专家，我们应当有自己系统化的、结构化的思考：

◈ 该品类价格上涨对平台收益的影响？对商家收益的影响？对平台整体价格政策的影响？

◈ 是否对竞品产生了有效打击？对其他临近品类的影响？对新用户购买行为的影响？对老用户复购行为的影响？

◈ 调整后数据产生负面变化时的应对策略？是否需要先进行灰度测试？

等等。

高级产品经理务必做到系统的、全面的、深入的思考和分析。我通常用到的系统性思维的方法是“因素分析法”，因素分析法是指将一个复杂的事物拆解成不同的因素，然后通过分析该事物在每一个因素上的情况，进而得出整体性的结论（我自己的定义，不理解的可以查询一下相关文献）。

系统性思维需要我们具体思考以下几个问题：

这个问题可以拆解为哪些因素？每个因素需要考虑的层面又有哪些？
你在考虑问题时，相关的维度是否考虑全面了？
……

共识思维

在产品之路上走的越久就越让我意识到“共识”的重要性——一个项目的成功绝不是一个人的单打独斗，而是一个团队各司其职、通力合作的结果。

而是否有明确的产品共识——会从根本上影响到整个团队的工作效率。

很多时候我们说自己提出的方案其他部门不配合或者不支持，主要原因可能也在于相互之间没有达成共识。

可能你理解的行业是一回事，他理解的行业又是一回事，之间有大量的分歧和不同点。这就导致表面上我们好像都在朝着一个方向走，实际上对于道路的选择和发展的路径有着完全不同的认知和理解，简直就是同床异梦。

我们每个人的生活经历、工作经验都是不同的，这也就导致我们对于同一个事物会有不同的看法和观点。

我们不要一开始就期待共识——很多共识的形成不是一个结果，而是一个过程，大家在理性的讨论中反复的加深思考、进行多种尝试和验证，才有最终共识的形成。

比如：

我们公司老板很喜欢干预产品设计，我刚来公司时大概花了接近两个月的时间去和老板沟通一个观点：管理层决定产品行业和商业模式，设计师和产品经理决定产品交互和体验细节。

大概两个月之后，这一点才真正的形成团队内部的共识，此后管理层再也没干预过产品的细节，设计师的积极性才被真正的调动起来。

又比如很多产品经理和技术沟通的内容都是功能如何实现、技术方案如何选择，但是针对于为什么这么做、有没有更好的方案以及行业的动向是怎样的、用户的反馈是怎样的，这些方面产品经理基本上不和技术沟通（可能很多人认为技术不懂这些，没必要对牛弹琴）。

但是随着产品工作经验的增多，我会越来越花时间和技术沟通这些内容，把一些问题也抛给他们去思考，最后再经过讨论达成共识，这样会从根本上提升开发的一些效率和对需求的接纳程度。让技术人员不仅仅的去做，而是带着思考、带着想法、带着共识去做。

实际中我们会发现，很多事情就算我们充分沟通、充分讨论，也未必会形成共识。

这里需要注意一个点：共识的目的不是为了证明自己是对的，而是为了更好的做事情。

在讨论的时候尽可能的以开放的心态去沟通，避免过于坚持己见。在一些需要形成共识的事情上，不要一上来就给出结论，这样会显得自己过于强势，也降低了他人表达观点的意愿。

可以先把问题抛出来，相互的讨论和沟通，最后才是达成共识。

那么如果一件事情未形成共识，我们到底是做还是不做呢？实际上还是要做的，因为产品的发展本身就带有很多的不确定性，我们的原则是尽可能的达成共识，但并不追求完全的意见一致。