产品大佬的思维模式应该是怎样的
⇨⇦
对于＂思维模式＂这一充满重要性与玄学的概念来说，如何定义、如何将其转化为真实可感的事物呢？文中，笔者将结合自己的观察与思考，聊聊他眼中的大佬是如何理解这一概念的。
什么是思维模式？
1. 关于这个思考的起源
从事产品经理这个职业已经有了相当一段时间，带产品团队也有一段时间了。从刚开始做产品经理，到现在带团队，＂思维模式＂这个词一直被反复提及。刚开始是自己经常被老板说＂你的思路不正＂，现在也经常把类似问题扔给自己的团队。
先想清楚你的目标是什么？
你到底要解决什么问题？
能不能关注问题的本质？
想必也有很多同行和我一样经常遇到这个问题。
我曾经遇到的困扰是：讲了一大堆，老板说没听懂。或者是老板扔给我这个问题，然后我去整理了一下回来老板还是说听不懂。
就在上个月，我和团队一起做复盘总结，我们试图定义＂思维模式＂，希望能够有清晰的路径和方法论进行参考，以便快速的进步。但我们却发现我们仍然无法准确的说出——什么是思维模式？正确的思维模式到底是怎样的？该怎么做？
2. 我的理解
这的确是个艰难的问题。
我们也经常看到网络上各种以＂思维＂为标题的文章，用户思维、商业思维、竞争思维等等等等。总觉得还是没有那个＂味道＂，都很有道理，但似乎还没有解决我的问题。
我也跟我的老师做了交流，但我发现在他跟我的讨论中，他并没有反复的跟我说用户、商业、竞对这些产品经理经常要面临的具体问题，他表述的更多是关于如何发现、定义、验证、解决一个问题的本质逻辑。他推荐我去看的书不是《结网》、《人人都是产品经理》，是《思考的技术》。
所以，目前得出一个让我觉得有点不好意思写出来但又认为正确的结论：产品大佬的思维模式，是＂返璞归真＂的＂解决问题的思维模式＂，用研、竞调、商业模式都只是手段。
这也让我想起来近期比较火的＂演员请就位＂中的现象：
陈凯歌、李少红、赵薇这些＂大佬＂级别的导演，在点评或讨教的时候，不会大篇幅地去说表演的理论、模型，反而是＂你不在这个情绪中＂、＂经历了那些事情…你此刻应该是…你的肢体…＂这些非常具象的事情。
而郭敬明更多的是引用一些理论，作为观众的我反而听的云里雾里，演员们似乎也无法准确的知道问题在哪里。
那么问题又来了，所谓的＂返璞归真＂的＂解决问题的思维模式＂，又是什么？
3. 这篇文章的内容结构
（1）大佬思维模式第一步——从问题出发的思维
这个道理似乎在很多文章中也提过，但我发现很多人（包括我自己）对这个道理的理解常常停留于表面。
我认为核心的原因是很多人把现象、原因、结果、解决方案这四个不同的事物搞混了，想要从问题出发，但往往无法描述清楚到底是什么问题。
（2）大佬思维模式第二步——归纳思维，让思维聚焦
当我们理解了项目的现象、原因、结果、解决方案的区别之后，如何真正的做到？
一方面，我们接触的信息量太多了，从用户调研、逻辑推演、竞调我们会获取很多的认知，如何对这些认知进行高效的梳理？
另一方面，我们常常会犯一个错误——过于发散。一次想解决的问题过多，不够聚焦。
我将提供一些基本的方法论帮助你解决这两个问题。
（3）一个项目FRD的参考框架
大佬思维最直接的体现是一份高质量的FRD（或MRD）。
最早我们的团队是没有写FRD的习惯的，脑子里蹦出一个需求或者从用户那边抓到，稍微一商量就去干了。
现在开始搞FRD以后，感觉这个环节必不可少。
FRD是去叙述你的方案目标、价值、验证过程、方案核心点的过程，可以让你自己和相关团队清晰的知道这个项目到底解决什么问题？什么价值？多大价值？方案的难点在哪里？
强烈建议还没有这个习惯的产品团队，在客观条件允许的情况下启动FRD评审。
我们在启动后也一度遇到不会写、写的质量差的问题，所以这里结合本文的内容给到一个参考的框架。
到这里也罗里吧嗦一大堆了，也是我个人还没有解决的坏习惯，希望上面的文字都不算废话，接下来进入正文。
Part1：现象、原因、结果和解决方案
这个部分从产品经理最常遇到的灵魂拷问开始：
你到底想解决什么问题？
老板到底问的是什么？
在产品大佬的耳中，他又是如何解读这个问题的？
先提供一个模型：
然后我们来逐一解释：
1. 你希望对现在的＂结果＂带来什么改变？
这个问题是最关键的问题，你必须知道你的项目最终能为用户、公司带来的＂结果级＂的改变是什么。
请注意，这里的关键词是＂结果＂。
很多产品经理在回答这个问题的时候，会回答：
＂我想缩短一下这个操作的路径，用户对这个地方吐槽很大＂
＂我想新增一个模块解决用户的这个场景＂
这都不是结果，＂缩短操作路径＂是解决方案（手段），＂用户吐槽很大＂是＂现象＂，＂解决这个场景＂是过程。
缩短操作路径之后的结果是什么？是体验提升？是转化率提升？能提升多少？
用户吐槽少了的结果是什么？是客服咨询量减少？是口碑上升？减少多少？上升多少？
这个场景对用户意味着什么？是提升成就感？是带来收入？多大成就感？多少收入
一般来讲，如果你认为你的项目价值很大，那么这个结果一定是和用户的＂活跃＂＂付费意愿＂，公司的竞争、销售亮点直接相关的，那么你务必要拿出具有绝对说服力的逻辑和证据，来说明这一点。
如何说明呢？
基于你对现象的整理、对现象背后原因的剖析。
2. 拿出经过验证的＂现象＂和导致这个现象的＂原因＂论证你的结果
＂现象＂和＂原因＂是对＂结果＂的解释。
基于对已经客观存在的＂现象＂的分析，我们认为导致这个＂现象＂的＂原因＂是XXX、XXX，针对＂原因＂我们给出＂XXX＂、＂XXX＂两个解决方案，可以如何如何改善这个＂现象＂，从而得到＂XXX＂的＂结果＂。
我们常常说，＂要看到问题的本质＂。
什么是本质？
a. 你看到的＂现象＂意味着什么＂结果＂，＂结果＂是好还是坏，有多好，有多坏。
b. 这个＂现象＂背后的原因是什么？
我是做B端产品的，这里提供我近期遇到的一个案例，来深度说一下＂现象＂和＂结果＂的区别。
（1）＂现象＂
在我们的需求库中，收集到大量的需求，希望我们在我们为用户提供的宣传页制作工具中，能够让宣传页内嵌的表单填写信息更加灵活，支持自定义。
看到这里你会做什么？提供字段自定义的功能？
那么你并不知道做了这个功能可以带来什么好的结果，唯一的结果就是用户不再大量反馈了，但你根本不知道为什么。
我们是怎么做的？
（2）＂现象＂背后的＂结果＂
我们很好奇，先去探究了＂他们要自定义是要拿来干嘛＂。
于是我们发现在我们的用户日常经营的过程中，他们有很高频的活动用来拓客或者调查问卷来维护已有的客户。
在拓客中，他们非常迫切的希望能够收集到他们的客户更为丰富的信息，因为在他们后续长期的客户维护和客户续约中，对客户有充分的了解是至关重要的。
在日常维护中，他们会邀请用户参加一些客情维护的活动，也会有满意度的问卷调查，他们也希望对这些过程信息进行整理和归档，用于后期续费或其他客情维护场景时使用。
现在我们知道了，我们如果解决＂客户希望增加报名表单自定义＂这个＂现象＂，我们可以带来＂为用户的经营中续费、客情维护的关键事项提供有力的信息收集工具＂这个＂结果＂。
（当然，这个结果仅仅是从用户价值深度层面给出的，如果要完善还要考虑用户范围、对公司的竞争价值）。
分析这个有什么用呢？这决定了在你向老板介绍项目的时候，你是否能让老板＂动心＂，也决定了你自己的项目落地的时候，项目价值的天花板。
（3）＂现象＂背后的＂原因＂
如果从刚才说的案例出发，现象背后的原因似乎一目了然，因为他们要搞续费搞客情维护，所以要这个功能。
但实际上，我们还会想＂用户现在是怎么解决这个问题的？＂为什么偏偏提了这个需求而不是其他需求，没有采用其他解决方案？
我们发现用户有的用纸质的表单或excel。但这种方式搞来信息难以统一管理，查询调用不方便。用户收集到信息后还要给销售团队、售后团队做分配，用纸质和表单就很难清晰的进行处理了。
或在网络上找其他的表单工具。但是这些工具自定义程度很高，由于我们的B端用户处在一个较传统的行业，我们的用户反而不太会用。
这是原因。
（4）现在可以做最终总结了
结果：用户有＂对客户建立完善的信息档案以促进续费和客情维护＂的目标。
原因：用户当前的各种解决方式存在各种弊端。
现象：最终有了，用户希望我们能够对既有工具做优化提供＂表单字段自定义＂这个现象
我们最终的解决方案并不是在我们提供的宣传工具上增加表单字段自定义的功能，而是单独开发了表单插件，并做了诸多其他针对性的设计，这里就不透露了。
（5）小建议
最初级的产品经理，常常把＂解决方案＂当成＂你到底要解决什么问题＂的回答，我要做一个某某功能。
进阶的产品经理，常常会因为思考逻辑不清晰，区分不清楚结果、原因、现象之间的差别。也会因为思考深度不够、全面性不够只看到了部分的现象、部分的原因。
要做好这一点，我采用的解决方案是＂写下来＂+＂讨论＂。
当写下来以后，我可以更清晰的看到自己的逻辑，从而优化逻辑。
找同事、用户、相关人员做讨论以后，我会发散自己的思维，避免自己只是管中窥豹，或者只看到了表象。
这个还需要多多训练，多多挨骂。＂思路正＂，是可以通过学习快速建立框架然后加以练习的，＂思考深入、思考全面＂，可能就需要不断的磨砺摔打在实战中成长了。
Part2：归纳——让思维聚焦
我经历过这样的阶段——思路感觉已经清晰了，但是自己说不清，经常被吐槽＂废话太多，没有重点＂。
最常见的现象是：
项目的目标有多个
列举的现象、解决方案有一堆，且相互之间关联性很差。经常会说＂我们这样做，既可以，同时也可以，还可以…＂
我复盘了出现这个情况的原因：
我们通过各种渠道获取到的认知太多了，没能对问题进行归类、总结。
步子迈的太大，想要的太多，不够聚焦。
关于前第一个问题，推荐《金字塔原理》和＂麦肯锡的MECE和归纳演绎法＂相关理论。
核心步骤是：
是对所有可能性进行穷尽，确保＂没有遗漏＂
复盘所有可能性，对相同的进行合并，确保＂互不交叉＂
对所有可能性进行归类总结
对归好的类别进行演绎，从原因、现象、结果的逻辑建立金字塔结构，确保逻辑融洽
相关的文章有很多，这里就不深入讲了。
关于第三个问题，也非常简单，只要做到一个点。
一次解决一个问题，不同问题分不同项目解决。一个问题甚至也可以拆成不同项目解决。
（这一点＂知易行难＂，需要刻意练习）
Part3：一个项目FRD的参考框架
Step1：项目来源
尽管不少产品项目最初的起源可能都只是产品经理一时的灵感暴击甚至只是意淫，但是当你要进行FRD的时候，请务必进行相关的验证工作。
在一开始，说明项目需求是从哪来的，有哪些准备工作（数据分析、电话调研、访谈），不用详细讲过程，一句话带过，至少让参会的人知道你的结论都是有实际依据的，而不是自己意淫。
Step2：做什么，能带来什么结果
一句话说清楚，可以和Step1一起说，例如：
（开门见山）我们在需求库中发现很多用户希望我们做＂信息收集的表单工具＂。
（你的依据）我们对此做了XX家用户访谈，也对比了XX、XX等竞对。
（结果-用户拿来解决他的什么问题）发现用户为了更好的续签和客情维护，需要表单工具来对尽量全面的收集他们客户的信息。
（结果-这个问题有多重要，覆盖到多少用户）这在绝大部分用户的经营中都是必不可少的一环，但现在市面上的工具都很难解决他们的诉求。
第一分钟，就要让老板动心。（让老板动心是其次的，关键是这体现了你的思考够深）
Step3：描述现状和现状存在的问题
用户的实际场景是…..三大类场景
他们在这三类场景中目前是通过….等手段来解决的
这些手段存在的共性问题是…..等问题
未能满足用户的….等关键诉求
Step4：竞对情况
在行业中XXX已有相关解决方案….我们可以效仿的部分是，可以进一步解决的问题是….
XXX、XXX还没有相关方案
如果我们做了会为我们带来XXX的竞争优势
Step5：项目价值总结
用户价值：
和用户的续费、客情维护关键诉求直接相关（价值深度）
绝大部分用户都有诉求（价值广度）
对公司的价值：
满足一个新的用户高频场景，增加用户的使用粘性
建立竞争优势
Step6：项目方案核心点
最后一步其实很难，关键点在于能够结构清晰、重点清晰的说明方案的核心点。很多人常常做成粗浅的页面表述或者功能结构表述，未能提炼出关键点。
好的项目方案核心点总结，首先一定是和用户的核心诉求、竞品未满足的诉求能对应的，其次一定能给参会的技术同时一定的参考，让他们提前预知到方案的核心开发难度在哪里。（当然，部分方案的核心点可能在方案上线之后的运营策略、或是方案的视觉设计）。
Setp7：需求清单和优先级
结语
关键点总结
区分清楚现象、原因、结果、解决方案
确保目标明确、聚焦，一次解决一个问题
利用好归纳法，归纳之后理解才深刻
利用好演绎法，演绎之后逻辑才通畅，思维误区更少
反复练习，不管大小项目。可以充分利用日常的小事情。
比如，我今天写这篇文章之前去看了电影，电影院的区域划分是A01~A07，然后是B08~B13。为什么不干脆用1号-13号来命名，或A01~A07和B01~B06。
原因1：电影院13个厅分在两个不同区域，区分AB看电影的人能够清晰的知道自己的影厅在哪个区域。
原因2：电影院内部员工进行沟通或管理时，影厅数量不多，对A、B区域很熟悉，直接从1到13号的划分更便于日常沟通。如果按A01~A07和B01~B06的方式来命名，如果A01着火了，就得大喊＂A01着火啦＂，不如按A01~A07，然后是B08~B1的方式命名，大喊＂1号厅着火啦＂更爽。
当然，这些小事情如果你不是非常有兴趣，可能不需要真正花太多的时间和精力去弄清楚，自己逻辑自洽就可以了。
最后，写完之后并不是非常满意，感觉还没有非常清晰直接地将一些关键点总结出来。也是我希望继续去提升的点。
不管怎样，希望对各位能有一定的参考价值。
感谢。