无论是在实际的工作中还是短视频的搞笑段子中，程序猿和产品经理之间似乎总是一对欢喜冤家。我相信大家在现实项目中也经历过程序员和产品经理为了需求吵得脸红脖子粗的场景。产品经理觉得某个需求实现起来应该很简单为什么研发总是各种理由推脱。而技术人员觉得这个需求做出来没有用，而且对现有的产品有冲击增加复杂度，为什么产品总是提这种很 SB 的需求。造成这种互相不理解的情况的根本原因，实际上就是技术同学与产品同学在面对产品需求的时候所使用的思维模式是不一样的，技术同学使用的是技术思维、产品同学使用的是产品思维，不同的思维方式最终造成了谁都无法理解对方的情况。那么今天就和大家聊聊为什么技术同学需要产品思维才能更好地推进工作落地。

什么是产品思维？

在说明技术人员为什么需要产品思维之前，我们先来看看到底什么是产品思维?在我看来，产品思维需要具备四种看的能力，分别是看大局、看体验、看运营以及看趋势。这四种看的能力构成了产品思维这门武功的外部招式。我们来分别看下这四种看的能力分别指的是什么。

产品四种“看”的能力

所谓看大局就是需要我们站在全局以及整体的角度上对产品进行通盘思考，重点梳理清楚产品这几个问题，我们的产品的定位是什么？产品面向的用户群体是什么样的？用户在什么场景下会使用我们的产品？用户通过使用我们的产品会给用户带来怎样的价值？

只有清楚明白的想清楚以上几个问题，我们才能保证产品不会往错误的方向发展，才能确保产品的定位不会发生根本性的变化，同时也是我们在纠结一些业务细节时，可以跳出来衡量产品定位的一个标尺，正所谓不忘产品的初心，以终为始。

我一直认为用户体验也是产品质量重要的衡量指标之一，即便一个产品代码质量很高很少出 Bug，但是用户体验非常差，它也是得不到用户的认可的。看体验就要求我们要站在用户的角度，从产品使用细节出发，切身感受产品使用过程，产品功能用起来是否方便？能不能减少用户操作而达到用户使用产品的目的？产品有没有帮助用户解决他们的痛点问题?另外用户通过使用我们的产品有没有提高他们的生活效率以及工作效率？这些都是我们在进行交互设计以及自己使用产品的时候需要不断问自己的问题。

当前互联网行业已经进入深水区，如何进行存量用户的精细化运营已经成为各大互联网公司不得不面对的现实问题。对于软件产品来说，运营实际就是从产品数据出发，分析提炼业务数据价值。从数据中获取新的业务创新以及用户维护。同时通过一些活动策划实现用户拉新、用户价值转化等增加用户粘性。

所谓看趋势就是要用发展的眼光看待产品的需求迭代，以动态变化的趋势思维思考产品的未来。以市场竞争力为基准，对产品的发展方向进行规划。只有洞悉未来，才能在变化更迭中寻找新的业务机遇并进行提前产品布局。

五种思维类型

上文提到的四种看的能力实际上是产品思维的外在表象，实际上它的底层是依赖于五种思维模型作为其支撑的，分别是本质思维、相对思维、抽象思维、系统思维以及演化思维（来自《腾讯产品法》）。实际上有的思维方式是和技术人员的思维模型是相通的，比如抽象思维、系统思维。

所谓本质思维就是洞察问题本质的能力，实际上就是一种深度思考的能力，通过不断的追问 Why 来发现问题表面背后真正的根本问题到底是什么，以及搞明白人们真正的需求是什么，用户的真实意图到底是什么。

在产品设计的时候需要正向思维也需要逆向思维，主要和次要并不是绝对的，而是在动态发展中交替变化的。因此在产品迭代过程中需要辩证的进行相对性的进行思考。这就好比光与影子，有的时候我们为了突出一个物体部分的光亮不一定是通过增强它的亮度，而是将环境中的零度调得暗一些，实际也可以达到目的。

抽象思维是一种分析提炼的思维方式，通过对于事物的观察分析，提炼事物的特征属性。实际上我们技术人员在进行编写代码设计的时候，也是使用这种抽象思维。从业务流程中抽象出可以用程序语言表达的业务模型。那么在商品设计中如何应用抽象思维呢，举个简单的例子，大家肯定都用过音乐 APP，这些音乐 APP 都对歌曲进行各种分类，比如情歌、民谣或者摇滚等，而这种分类实际就是对歌曲属性的一种抽象，通过这种分类可以将喜欢某一分类的歌曲不断推荐给用户，从而更好的满足用户的对于该类型歌曲的需求。

产品是一堆功能的集合，是为用户解决问题的工具。因此产品的本质就是如何更好地帮助用户，与用户共生。而产品反馈就是我们对产品进行系统思考的有力手段，通过不断的获取产品反馈才能使得产品朝着好的方向发展。从以前惯用的线性逻辑思维方式拓展为网状、面状甚至立体状的系统思维方式综合考量各方面影响因素。

产品设计的顶层思维，在确定的大目标下，以极简的方式识别错误路径，进而可以通过快速试错的方式逐渐逼近那个正确的目标。产品的好的演进方式就是给用户的感觉是没怎么变，但是每次迭代都是推陈出新，降低用户学习成本。真正的演化、真正高明的设计是自下而上涌现出来的。

技术同学为什么需要产品思维？

在我们的日常工作中，PRD 需求评审会议是产品迭代过程中非常重要的一个环节，同时它也是是技术同学与产品同学交锋的主战场。产品同学将业务方的需求或者规划的功能需求转化成 PRD 文档，在评审会议中向技术同学、测试同学、交互同学也许还有老板们进行澄清说明。

这里以曾经评审过的一个业务需求来作为我们分析的例子。这个需求大概是这样，在一个监控告警平台中，需要对产生的重要告警进行通知，让接收到的运维或者技术人员进行介入处理。而此次的需求就是在原来通知的基础之上增加告警通知升级流程，通过配置的方式设置多层通知人员，根据告警未被处理的时间长度，进行告警通知升级通知更高层次的人员。我们来分别看下技术同学以及产品同学是怎么思考这个需求的。

技术同学的思考

1、目前的通知方式已经可以满足通知的需求了，为什么又新增加这种升级的通知方式，增加了业务复杂性。

2、告警通知采用的是告警次数累加一定阈值时，触发告警通知，如果按照通知升级的方式那么无疑需要对告警通知的业务流程进行全链路的改造，其中涉及到延时队列的实现。增加了技术复杂度。

3、在进行升级告警的过程中，由于涉及到三次逐级通知，业务节点明显增多，如果出现异常如告警信息未升级、丢失等，很难在业务层面实现数据对齐。

产品同学的思考

1、运维团队正在慢慢扩大，团队长正在慢慢走向正规化。原有的全部通知的方式明显不适用于现有的业务发展。

2、通过分层的通知方式，可以充分调动值班人员的处理问题的积极性，以前全部通知的方式在实际的落地过程中容易造成大家互相等对方去处理告警的情况。

3、如果一次性修改告警通知链路存在排期困难的问题，我们可以通过迭代的方式来进行，根据实际的研发资源来进行。

从上面的例子我们可以看得出来，正是因为技术同学和产品同学思考问题的关注点不同，导致大家都无法站在对方的角度上思考问题，进而彼此在同一个需求中产生的分歧越来越大，最终很容易陷入沟通的僵局。 

 通过上文，我们分析了技术同学与产品同学陷入需求沟通僵局的根本原因，即大家在分析需求方面存在的思维方式不同。那么接下来我们从技术人员的角度来看下技术思维存在哪些不足之处以及技术人员如果具备了产品思维有哪些有益之处。

技术思维的不足

过度关注技术细节

从上述的例子中我们可以看的出来，技术思维存在一定的局限性，技术人员在讨论需求的时候总是会将需求细节理的特别的详细，主要原因是技术同学需要将需求进行实际的代码落地，要用编程语言描述业务逻辑，因此就会非常关注业务细节甚至是编程细节。

细节当然很重要，但是在前期需求沟通中如果过度关注细节，就会导致技术同学陷入细节的泥泞中不能自拔。所以在前期的需求沟通中，我们要关注整体，看这个需求给用户带来什么样的价值，帮助用户解决什么场景下遇到的问题。如上文所提的关于告警升级的例子，如果一开始就考虑升级通知的实现细节，规则怎么定，通知失败了怎么办这些编码细节，那么需求评审就会变成设计评审了，失去了它本来的价值。

缺乏迭代演进思考

技术人员是天生的完美主义者，做需求的时候总是想着可以一步到位完全实现，后面最好不要给我出什么幺蛾子再搞个需求变化之类的东西让技术人员各种改代码。但是实际上产品是一个渐进完善的产物。很难说一步到位。因此技术人员在设计的时候就需要考虑到未来这部分是否存在变化的可能，提前预留好便于后期变化扩展的部分。

技术同学具备产品思维后的优势

更好地理解需求

在具备产品思维之后，我们在进行 PRD 需求评审的时候除了从技术人员的角度考虑需求实现的可行性，同时也会从产品的角度明确需求或者项目对于业务方的价值，搞清楚需求背后的 why，而不是简单的执行编码。

更远的设计思考

我们在进行需求设计开发的时候，实际上平台中会有各种业务模型来承载业务的流转。在做产品需求的过程中，技术同学最难受的就是产品同学的需求变来变去，而这种变化对技术同学的设计以及编写代码都有比较大的影响。但是如果具备了产品思维，我们在设计业务模型以及数据模型的过程中，就不会只盯着当前的业务现状，而是用发展变化的眼光进行设计，业务模型不仅是对当前的业务描述，同样也需要留出适当的扩展能力来应对未来可能出现的变化。这样当变化真正来临的时候，我们也可以沉着应对。

更广的产品视角

如果技术人员具备了产品思维，那么在看待产品的时候就不仅仅是技术视角，还包括了产品视角。那么就会将自己置于用户的角度，思考产品到底好不好用，业务流程对于用户实际操作到底有没有掣肘的地方，有哪些交互步骤可以省掉节省用户的操作步骤等等问题。那么在这些问题的思考过程中就会发现当前产品中存在的不足之处，而自己可以主动推进产品优化需求的落地，利用技术实现更高的产品价值。

这里举个栗子，曾经做过一个设备管理的平台，平台主要实现设备全生命周期的在线管理，每个设备上面都有一个二维码，扫描后会展示设备的基本信息。设备维护人员会对设备进行维修和保养，维护和保养维护后会进行记录提交到平台中。我在实际使用的时候发现扫描二维码只能展示设备基本信息，查看不了设备的维护记录和保养记录，对于维修人员来说非常不方便。于是通过和用户沟通，发现他们也觉得如果有了维保记录，对于他们来说可以知道哪些设备需要换零件了，使用起来更加方便。分析后，我主动提出需要在扫描设备二维码之后也要展示设备的维保记录，方便维修人员进行查看。

通过上文的分析和说明，相信大家对于技术同学为什么需要要有产品思维有了一定的理解。实际上无论技术同学还是产品同学如果在实际工作中能够多站在对方的角度上思考问题，也许就能更加理解对方所关注的重点以及担忧是什么。只有这样在进行需求讨论的时候才能共同面对问题、求同存异，而不是单纯只从自身视角出发思考问题甚至有时带有情绪的进行讨论。

本文针对产品思维需要具备的四种“看”地能力，分析了产品思维具备的优势以及技术思维存在的局限性。通过两种思维的思考方式的分析对比，解释了技术同学需要具备产品思维的原因，技术人员在日常工作中如果再结合适当的产品思维，那么就可以更好地推动工作以及进行需求理解。