每个互联网从业者能够听到的高频次语就是产品思维，其重点是“产品化”的思维模式。那么，我们该如何理解产品思维以及提高自己的产品思维呢？
“产品思维”是每个互联网从业者都会高频听到的词汇之一，但“产品思维”绝不应简单理解为产品经理的思维，其重点是“产品化”的思维模式。我们常用“产品思维”作为一种idea或方案的评判标准，而不是将某个“产品经理”的想法视为“产品思维”。
思维模式是现实社会的一种投影，优秀的思维模式能够很好地还原和预测物理世界的真实规律。而在一个完整的软件产品开发周期里，会出现三种标准模型。
实现模型：代表研发工程师开发产品的代码模式。比如是云端服务，还是混合服务；是用分布式架构，还是集中式架构；是用机器学习，还是正则表达等……
呈现模型：代表工程师（包括PM和QA）设计的产品功能界面及系统。好的呈现模型能做到和用户的心理模型基本一致，差的呈现模型会和实现模型没什么两样。
心理模型：代表真实用户使用产品时的心智模型及操作预期。有些模型是对现实生活的投影，比如：看到手推车的图标，知道是选购商品的清单；浏览照片时，知道左右滑动可以翻看下一张照片。还有一些模型是由主流产品培养出来的，比如：下拉内容列表刷新内容；扫描二维码打开网页或APP；滑动接听电话，等等……
那么结合现实的分工情况，呈现模型就是产品思维的一种投影和落地；相应的，实现模型和心理模型分别对应技术思维和用户思维。
优秀的产品思维才能把呈现模型变成用户和技术之间的最佳桥梁，所以怎样强调产品思维的重要性都不为过。
产品思维本质上是一种实现思维，它天然存在理想和现实的矛盾性。正如我们无法脱离用户和开发的角度去描述“产品”本身的好坏。如何对产品思维下一个完整的定义，需要我们先理清它与“用户思维”和“技术思维”之间的关系。
用户思维本质是一种需求思维，即“我”需要得到什么样的服务或则体验。它的特点如下：
最典型的例子是大多数产品的用户反馈都是希望添加新功能，而每个人在其描述的立场都是非常合理的。以微信为例，很多人提议希望能收到删除好友的通知，而不是等到自己发消息时才尴尬地发现消息已无法发出。站在被删除用户的角度上，他的提议是合理的；站在主动删除好友的角度上，现有的模式又是更得体的。所以，用户思维不是一种普世思维，它是个体在某个场景下的思考方式。
更有趣的是，真实的产品用户一般不会主动提及“用户思维”，这个词往往在产品或市场内部被广泛传播，其目的是设定产品边界，避免没有价值的设计，是“同理心”的另一种表达方式。当然也没有任何一个产品可以满足所有人的需求，“用户思维”不等于无条件妥协，比如“技术思维”在很多时候就站在了“用户思维”的对立面。
技术思维本质上是一种成本思维，即“我”需要付出什么样的资源来达到既定目标。它的特点如下：
最典型的例子是需求评审会上开发经理和产品经理的各种争端：
这些都是开发人员diss产品缺少“技术思维”的实例。在技术人员的视角里，真正的特例是极端条件下的输入和输出，而不是大客户。技术思维的最贱实践是用最少的技术成本实现最大的吞吐量，同时还能随着系统负荷地增加保持稳定。相比之下，产品界面是否难看，功能是否易用，都属于次优先级的目标。
和“用户思维”类似，开发人员也很少主动提及“技术思维”。而且开发人员理解的“技术思维”往往是更偏向于专业性的编码思维。“技术思维”一般是产品内部用来权衡ROI的部分论据，当然也有更高阶的产品经理会把“技术思维”贯穿在自己的产品设计里面，比如对未来产品功能的可扩展性和复用性的考虑。
产品思维是平衡“需求”和“成本”的链接器，是一种“实现”思维。它的特点如下：
所有的商业产品都是产品思维的最佳体现。无论是实物商品，还是软件应用，客户都会用脚投票，让那些真正具有产品思维的团队获得商业上的延续。通过以下四个关键词来延展讨论产品思维的最佳实践：
（1）多系统
产品思维是一种多系统层级的思考模式；正如客观世界里面，很多事物都有着不可见的彼此关联性，而产品思维则要求我们囊括所有，脱离孤立的系统看问题。
以“双十一”大促为例，直觉上这是一次边界清晰的年底集中促销活动。对于平台而言是营销系统的服务范畴，只需提供商品打折及优惠券的分发和核销即可。但是营销系统的高负荷远转会同时引起支付系统，客服系统，物流系统的高并发。在没有提前考虑的情况下，营销系统的功能会引起其他系统的灾难级事故。
对于商家而言，一次促销活动除了市场部门主导营销策略，还需要品牌部门确认对品牌商誉的影响，以及客服部门提前准备常见问题话术，同时财务部门还需要做好活动前期和后期营销额急速下降的准备。对于消费者而言，除了准备选购自己心仪的商品外，还要激活自己的决策系统，确定下单时间，优惠券的组合，凑单策略等等……
就算我们缩小讨论范畴，以简单的页面设计为例，多系统的视角仍然是产品思维的必备项之一。比如我们考虑给“人人都是产品经理”的文章阅读增加一项“点赞”的功能，看起来只需要在文章的列表页和详情页增加一个“小红心”入口和点击效果就可以了，但实际上简单一个页面会影响多个业务系统：点赞过的文章是否允许重复点赞？“个人中心”是否需要添加一个“点赞过的文章”合集？个人推荐feed的算法是否需要将点赞数量纳入推荐因子？
系统是多个部件组合在一起，并达成1+1>2的有机组合；多个系统之间的协同工作组成了真实的业务系统。产品思维是站在上帝视角，煽动“蝴蝶”翅膀的操盘思维，而不是立足于一个功能点的工具思维。
（2）复杂性
现实世界的多系统耦合，预示了产品设计中长久存在的复杂性。唐诺曼在《设计心理学 2 – 与复杂共处》中旗帜鲜明的表达了复杂性是不可避免的，设计师应该通过更巧妙的设计方式将复杂性隐藏或则将其从用户侧转移。
产品思维首先是尊重复杂性的存在，没有消除复杂性的妄念。同时力求将复杂性转移到用户不可见的一侧，通过设计或则技术去处理现实世界的复杂性。搜索引擎的演变是一个非常好的例子，Yahoo在2000年时搜索界面是下面这样的，占据整屏的各种广告位和搜索类别推荐。
而Google是一个简单，且清晰明了的搜索框。
大家都知道故事的结尾是Google横扫了搜索引擎市场，以破坏式创新的方式重塑了用户的搜索方式。看起来Google让搜索变得更简单了，但其实让Google起家的算法“PageRank”复杂度远远超过Yahoo早年自研的搜索算法。只是Google没有把这些复杂性交给用户，没有层层往下的面包屑导航，也没有铺天盖地的广告banner，只有最简单的搜索结果排序，用户没有必要理解复杂性，但是机器可以理解，也可以应对人类并不擅长的海量数据统计。
高级的产品思维往往会优先提炼出产品的复杂性，并将它从用户的注意力中转移，甚至完全在客户的交互界面消除。次级的产品思维则是我们常常吐槽的那些产品：超长的表单，重复多次收集的信息，难以理解的提示文案。仿佛是电脑程序在吐槽用户，“你连这些基本的系统知识都不懂？”。把复杂性留给用户，等同于和用户“道别”。
（3）溯源
对需求的理解程度取决于产品思维对需求源动力的抽象高度。而且来自用户侧的需求描述，往往视角较低，正如福特说“客户只想要更快的马车”，而不是福特重塑汽车工业通过流水线生产的T型车。
需求溯源的方式和路径有很多，比如Musk追求“第一性原理”，站在工程师的角度去解构现实问题；也有常见的“5 Whys”式提问法，通过层层逻辑递推得到根本原因；也可以通过“5W”的原则，再现需求的真实场景；互联网产品一般通过user story的方式，把需求发起方，功能和目的串联在一起。
高级的产品思维往往会将日常需求抽象到人类的顶级需求。正如张小龙主张“微信是一个生活方式”，完美对应了Maslow定义的第三层级需求-“love and belonging”，所以微信也超脱了大多数即时通讯软件的服务层次，成为当之无愧的国民应用，也正因为早期对社交需求的理解极深，微信的产品框架从诞生至今没有结构性的调整。也有不少产品利用了人性弱点去达成产品目标，比如美国最近大火的高中生匿名社交APP- Gas，充分利用了青少年的好奇心，通过匿名的方式提问并夸奖自己的中学好友，这也很好的对应了Maslow定义的第四层级需求-“Esteem(尊重)”。
当然并不是所有的产品都需如此，很多工具产品只是为了解决个人生活或工作的效率问题。强行拔高没有必要，也没有任何意义。但是溯源本身是非常有价值的，一个是认清需求背后的动机；一个是挖掘需求共性，增加产品单位投入辐射的用户数量。
（4）平衡
产品思维是被海量产品决策培养出来的平衡术。大到产品商业化的主赛道，未来一个季度的营收目标；小到产品界面的按钮颜色，页面的加载效果，这些都是产品思维在权衡背后的利益体后做出的决策。
但是归类到底，产品经理的大部分决策是在多个维度去平衡产品目标和用户需求。
开发资源永远都是有限的，但是用户的需求是无限的。正如一个商业产品从上线的第一天开始，它的roadmap就是一个永无止境的蓄水池。但是高级的产品思维并不体现在这长长的表单里面，有选择地说“不”才是。如果一个产品盲目追随用户的声音，会变成一个什么都有的四不像；如果一个产品一味追求产品目标，比如商业价值，它会变成被用户唾弃的垃圾应用。
张小龙曾说每天都有一亿的用户在教他怎么做产品，但是微信一直都坚守着自己的迭代路径和产品目标。所以做产品就是回归商业的本质 —— 平衡供需关系，只是我们通过应用程序和市场博弈。
人人都是有用户思维的“产品经理”，但不是每个“产品经理”都有产品思维。提升产品思维也没有捷径，多思考，多决策，多复盘。产品决策数量会影响决策质量，进而构建优秀的产品思维。
本文由 @One 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。