思考深度:影响产品的战斗宽度和挺进

在产品经理工作中,同样推崇有深度的人。但这种深度不是体现在外表,而是对事物的分层刺探!

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

如何做到深度思考、深度决策?以知识宽度作为锚点,以方法理论做工具,以思维模型作为收敛归拢。落地一点的话,清就看本文的几个案例!

一、由表及里层层分析

飞机的哪个部位容易被炮弹袭击?如果派一个产品经理,到二战战场,把这个问题解决了。产品经理查看了惨胜而归的飞机,将机身上弹孔多的位置画了个原型图,告诉工程师:去,将这些位置加固防护(截图交给开发做迭代)!但是这个决策正确吗?

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

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

在一次周会上,你的汇报工作写“该需求调研了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. 主产品库存完全缺货。

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

四、如何培养深度思考境界

有的人天生就是习惯深度思考的人,有的人反应短直快。

前者好像一上来就要单挑的张飞,兵来将挡,触地反弹。后者好像摇着扇子的诸葛,审时度势,步步连环。

各有各的好处,要看问题的具体情况。而从产品经理长远来看,深度思考的能力是必须要具备的。

那么,怎么培养深度思考的习惯呢?

1. 多思考

一个好的产品人无时无刻不在思考,不仅思考工作,也思考生活中的点滴细节。

比如:当地有一道传统小吃叫胡辣汤——花椒胡椒+淀粉或面粉+花生+豆皮+海带烩在一起,小火熬着,越熬越香,变熬边吃。外人看着这黑乎乎的,为什么会有这种么多人围着摊贩吃的津津有味。

“为什么”三个字就是一个神经结一样,迅速扩展开:

  • 是因为美味,是不是麻辣胡椒对味蕾的刺激和纠缠导致的。
  • 为了保暖驱寒,可能主要是喝了暖和。
  • 因为上瘾吗?类似槟榔,里面会不会混有类似大烟壳那样的东西呢?
  • 可能是穷日子时候的‘珍珠翡翠白玉汤’,没吃过更好的……

然后,我们再看:首先这个食物的主要成分是淀粉或面粉,淀粉来自红薯或土豆,面粉来自小麦。

这三种都是本地产量高的粮食,是穷苦人活命的保障。冬天到了,饥寒交迫,人们就想到从各自家里搜出这些杂七杂八的食材,兑一起烩,能吃饱就可以度过荒年。这种带有本地特色和历史根源的小吃就成了广大民众的情结。

以上只是个小情景,或许没有确定答案,但是不重要,只是要保持这种思考的习惯。相信会积累出很多有用的知识。

2. 思考套路

思维是有路径的,纵横交错,为了尽量提高有效思考,就要有意识培养思维方法论。

比如:5W2H就是一种结构式思维的工具,像列清单一样列举各个维度下对问题的探寻——思考需求,思考用户,思考产品架构,思考业务逻辑,思考业务流程,思考界面设计,思考交互方式。追逐思考更深层次关于用户、商业和产品的内容。

还有决策树模型和MECE分析法——思考的过程中不要漏掉某项,要保证完整性,并且强调每项要素之间不要有交叉重叠。

一直觉得写作的思维是跳跃的,尤其是散文和诗歌的写作。但是,逻辑思维是连贯性的,线性和结构化的。不过,这条线的延伸需要新的灵感介入进行催化。

所谓产品思维深度,就是引导围绕核心思想扩展,向纵向延伸,向上延伸、向下延伸、上下延伸探测旁支的深度价值。

3. 重视思考在工作中的比重和专注力

在一些2B的系统中,后台的功能比前端的比重大的多,有人开玩笑“后台够硬,没有做不了的”。

就像是冰山原理,顾客看到完美的一小步,对后台系统就要默默支撑一公里。因此在遇到需求和问题的时候,不要着急想解决方法,不急于出方案,而是像挖树一样,从更远处开始,才能找到深根。

调研清楚了,出方案很快很流畅;调研深入了,对开发的疑问就少;调研透彻了就可以更长远规划。

保持思考和规划的占比的同时还要保证思考的专注性。注意力需要非常集中,体力充沛,你会有种骑兵冲入步兵方阵的感觉。相反地,萎靡只会把自己拖进疲惫中,根本产生不了有价值的结果。

因此,要确保有一段专注的思考,找一个外界安静的环境,甚至进入忘我状态的状态(类似打游戏的状态)。

4. 提高准确性

当遇到问题,分析原因的时候,大多是带有个人主观判断的,因此会有归因偏差——归因偏差是:大多数人具有的无意或非完全有意地将个人行为及其结果进行不准确归因的现象。

浅层归因:在总结原因时,流于表面。

比如:常常说是由于自己抵挡不了诱惑、控制不住自己,对自己的行为只从直接原因上分析,而不从根本原因入手。

片面归因:在事物进行归因时,不进行全面客观地把握整体上综合地归纳总结,而是只见树木,不见森林,只论一点,不及其余。

比如:共享篮球和共享板凳的例子:篮球是大家在同一时间一起玩的,板凳如何同时服务多个人?这就是类比不全面导致的错误的判断。

如果思考的不准确,那么越深入反倒越迷途。

深度思考体现在举止之间的不盲目,不跟风,在于有带着自己人格特色的思维基因。深度思考是发现潜在价值和微创新的起点。有深度的产品是很有魅力的。

本文借着小场景,对这个深刻话题的浅表讨论,关于产品经理的思维深度问题,欢迎发表意见。

#作者#

唧唧歪歪PM,公众号:唧唧歪歪PM(ID:jjyypm),2019年年度作者。《后端产品经理宝典》作者,药学硕士转行互联网产品多年;熟悉跨境电商业务,医药领域;擅长大型后台体系,社交APP。

本文

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部