编辑导语：无论工作还是生活，一个成熟的产品人应该要拥有深度思考和正确决策的能力。只有像剥洋葱一样层层深入，全面评估，才能抓住问题核心，提高解决效率。本文分享了深度思考习惯在四个场景下的应用，一起来看看吧～

有一天，京东的同事聊到北京户口，他不假思索说：在乎户口的本质是为了孩子……

本质，指事物本身所固有的根本的属性。掩盖在太多的表面信息之下。

在产品经理工作中，同样推崇有深度的人，对事物的分层刺探！

深度，直接影响的是决策，思维+判断：产品经理拼的就是“决策力”！

如何做到深度思考、深度决策？

以知识宽度作为锚点，以方法理论做工具，以思维模型作为收敛归拢。

老赵向来喜欢案例，落地一点，请就看本文的几个案例！

一、由表及里层层分析

飞机的哪个部位容易被炮弹袭击？

如果派一个产品经理，到二战战场，把这个问题解决了。

产品经理查看了惨胜而归的飞机，将机身上弹孔多的位置画了个原型图，告诉工程师：去，将这些位置加固防护（截图交给开发做迭代）！

但是这个决策正确吗？

这就是幸存者偏差的误导。

场景+焦点=背后的动机。

在一次周会上，你的汇报工作写“该需求调研了XXX……”

领导说：这事情一定要调研xxx背后的用户。

你跟领导争论：我找不到人，并且xxx就是用户需求的收口人@#￥￥%…

结果导致会议耽误了好一会，你发现与会的人的气氛都怪怪的。

会后你问老同事，同事告诉你说，领导就是那么提醒一下，他又不是不知道xxx就是唯一对接人。

你恍然大悟，感觉自己严肃地在会场辩驳，不如来一句“我懂了，会努力揪出最终的诉求的”来的自然。

那么你会觉得，我明明很深入地思考了，为啥适得其反呢？

再来个场景：

下午茶休息时候，领导约你喝咖啡（紧张吧）。

谈笑间，领导问：”最近工作怎么样啊，上个季度优秀员工没看到你的名字啊？

“你的心里一胆颤，这是要优化我吗？然后，你故作镇定说道：

“是啊……那个……钢弹倒是又得了这次的优秀员工。”

领导说：“不要紧张，我们只是随便聊怎么改进工作。那你觉得为什么钢弹是优秀员工呢？”

你稍稍放松了情绪，想了想：“钢弹记忆力好啊，钢弹表达力强啊，主要是钢弹懂业务……”

敌情不明，你想快速解决话题。于是补充了一句：

“我会向标杆学习的。”

但是，领导还是摇摇头：“你说的都对，但是试着深入分析下呢？”

那么，我们想想：领导这个时间来谈话，只是为了得到这些粗浅的回答吗？应该不至于。

所以，我们发现：在回答问题的时候，首先思考，对方究竟想听到到什么弦外之音呢？这是个大方向。

其次，我们再看，这些看似正确的答案其实并没有触及问题的本质，而是用一个看似合理的外表掩盖了对问题的剖析。

所以，回答到这里不是结束，而是透过现象看本质的开始。比如：

• 钢弹为啥记忆力好，或许并不是记忆力好，而是他每天上下午都做笔记，回顾一天的工作经过、不足和提升；
• 钢弹为啥表达力强，或许知识他每次回答之前停顿2-3秒，语速较慢，提纲挈领三段式作答；
• 钢弹为啥懂业务，或许他和业务呆在一起的时间超过了做在电脑边写方案的时间。

那么到这里就结束了吗？

这只是第二层，其实你还可以往下拆解。

比如：

• 钢弹每天做笔记的话，有没有占用很多时间呢？
• 钢弹聊天时候有诀窍的同时，是否有提前准备知识储备呢？
• 钢弹在跟业务黏在一起的时候，业务是否烦他呢？

接下来，还可以继续剖析下去。

这个方法很简单，就是尽量让答案不再夹杂不可知因素，有点像做流程图穷尽原则。

这样才能解析出问题深层次的原因。我们叫他剥洋葱法，类似于WBS一样不断拆解。

它的另个叫法是“5个为什么”，也有叫“鱼骨图法”——是不是很熟悉。

读了那么多书，实际就在是每天的日常中。

这样做的好处就是：你最终能找到一份可以复制的经验，一份行动的图纸。这才是价值。

就像是一颗外光的驴屎蛋，砸开了才看出粗糙的本质。

产品经理在处理业务问题的时候，也应该用这种指导思想。

二、还原事件现场，验证解决方案

在后端系统的工作中，经常接收的需求是业务人员提供的。有时候业务是在发生事故之后提出需求的，这时候你得像柯南面对案发现场一样，分析完你的线索之后，尝试着还原一下现场，看看遗漏了什么。比如：业务要求刷数据——将订单的购买数量从5刷到1。

因为实际购买和发出去的确实是1个，但是系统显示是5。

刷完之后，还要还回去4个商品的库存到仓库系统。

看起来是很合理的一件事情，实际就是买1个，写了5个，就会导致库存记录减少，甚至造成缺货，误导销售。因此聪明的你已经明确：两步走：第一步刷数据，第二部重新同步库存。你开心地将方案丢给了开发，但是实际上只得了50分。

首先，我们思考下，商品已经发货，就算数据刷了1个，系统也不一定会重新同步到仓库库存的。

因为这是个逆向的流程，在于系统是否支持。万一库存更新规则就是规定订单出库之后，库存就不能逆向更新了呢？

因此，是需要查下到底是否可行，如果不行，就要找仓库系统看是否能自己刷回4个。

其次，到这里其实还不够，为什么仓库实际发货了1个，到订单系统就变成了5个了？究竟是付了几个的钱？是不是这个数据流就不合理啊？

所以，需要仔细问过业务，才知道这是虚拟发货的，也就是货物不是我们仓库发出去的，而是第三方平台帮我们发的。

在这里，订单信息只是在做后置的数据流完善而已：在数据流上我们要做到同步，因此就要手动创建订单，系统会扣除库存，并同步给仓库。

这样更新后的数据在系统中才是准确的，才能为前端（第三方网站）提供准确的数据展示。

于是，我们就明白了：因为是虚拟订单，所以发货出库的数据要手动录入。

业务手动创建订单的时候，把1录成5导致错误，系统自动按照“单价*数量”得到了总金额，因此不仅刷数量还要更改总金额。

是不是有种连着萝卜带出泥的感觉。

其实你遇到这类问题时候，常常发现业务知道的很少，完全靠产品引导才能找到问题的核心，而业务一开始说的核心，往往并不是靶点。

三、结合处理机制来描述需求

订单拆包，在电商行业是关键的业务场景之一。

拆包规则是业务在系统配置的后，订单命中拆包规则，则将订单中的商品分开打包发货。

某一天业务反馈：现在会出现将主产品和赠品拆开，赠品单独发货的情况，这样就造成免费送产品，还搭路费的亏本买卖。

因此，业务期望，遇到拆出来的包裹里面全是赠品，则不允许拆。

接到的需求是很明确也很合理的对吧，于是初步方案就是：在命中拆包规则后，增加判断，若拆包后的包裹中全是赠品，则不允许拆包。

作为产品，似乎是说清了需求，怎么实现是开发的事情，挥一挥衣袖准备深藏功和名了。

但是，这个需求这样提给开发是不及格的，为什么？

因为只说了现状和期望，没有具体到实现方案和路线的深入分析。后端系统的功能常常不是所见即全部的，而是所见只是冰山一角，背后支撑一个功能的逻辑是很复杂的80%。

正确的姿势是：在明确业务需求之后，调研现在的实现逻辑，试图探索未来的实现机制。

首先：拆包的现实业务场景是什么？

场景一：顾客下单的商品，有一部分是缺货的，顾客愿意部分收货，于是先部分发货，余下的下次再发。这样表现出来的就是一个订单拆成多个包裹，不能同时发出。

场景二：顾客购买的是A商品+B商品，但是本地仓库只有A，而B商品需要从其他仓库发出。从其他仓库调货过来一起发需要时间和运输成本，整体算下来还不如各自从自己的仓库发出，因此就出现了拆包的现象。

所以，我们看出来：是因为部分缺货，才是导致拆包的根源。

其次，看系统当前的实现逻辑：判断商品是否为部分缺货——是，则匹配拆包规则——匹配成功，则按照该规则进行拆包。

也就是说：先判断拆不拆，再处理怎么拆。

如果运算了拆包规则（怎么拆），那么结果就一定拆包的。如果在运算规则的时候加入分析赠品问题，就会增加无效运算，并且逻辑纠缠度增大。

因此，方案应该放在拆包流程前面，也就是判断拆不拆的时候，将本需求的场景加入进去（即：若怎么怎么，则不进入拆包规则环节。）。这样，流程归属就清晰。

于是方案应该是：

先判断为部分缺货，（在运行拆包规则前）再增加判断，满足下列任一条件的则不进入拆包规则：

1. 主产品库存完全满足，但赠品库存非完全满足(部分有或全无)；
2. 主产品库存完全缺货。

总结：从流程切入，将处于混沌状态的原流程剖析出来，将新增内容加入到合适的位点，描述新增内容的判断逻辑。因此，需求分析不只是分析出要实现的目标，而是要分析出需要实现目标的深层机制和逻辑。