需求评审总被怼，如何让你的需求更靠谱？

我们要如何才能让想出来的需求更靠谱，减少差错。文章对此作出了一些分享。

今天又有个产品经理评审的时候被群喷了！

事情是这样的，这段时间做了几个运营活动，也拉了不少新用户进来，虽然用户注册量见涨，但付费用户数量提升却不大，于是就有了个任务：提高用户的付费转化。这产品经理接到任务后花了几天时间做了一些产品调整，然后就是，评审的时候就被群体吐槽了。

一个重要的原因是有些产品需求是产品经理自己冥想（也没有想到不到好的词，姑且就用苏杰的说法吧）出来的，大家吐槽是的，这只是你想象的，但是就因为自己冥想的需求，就应该被吐槽？

最有名的的例子可能是乔布斯了。乔布斯曾说“我们不做市场调查，我们也不招收顾问，我们只想做出伟大的产品。”乔布斯非常赞同老亨利·福特的话：

如果你问消费者他们需要什么，他们会告诉你需要一匹更快的马。

还有张小龙，很少看统计数据。张小龙曾说过：

近期有个同事找我聊，问我是如何通过统计数据来看用户的喜好，通过数据来做一些东西。结果我的回答是，其实我们很少看统计数据，也几乎没从统计数据里看到用户的喜好。根据统计数据来找需求和方向是挺难的。我们也不会去了解手机QQ 的统计数据来指导微信的工作。

乔布斯、张小龙也通过冥想做产品，而且引领了时代，其他产品经理就可以凭自己的主观想象做产品？

在没有其他渠道（用户、市场、数据）提供需求依据的情况下，可以！

产品经理本身的思考也是需求来源渠道之一，很多老板在没有数据支撑的情况下直接拍板产品需求，不少也公司做的也不错。

那么我们要做其实是怎么让想出来的需求更靠谱，减少差错。

说解决方案之前，先看看冥想存在的问题：

智商的竞争力

假设所有产品经理，挖掘需求都是通过冥想，你觉得你比他们都聪明，你能做到智商碾压？

关健是很多企业的产品经理并不只是靠自己想，还会依靠用户、市场、数据。那么你觉得你冥想出来的方案能在同行中突围？

很明显，并不能。

很多产品经理做竞品分析，觉得别人产品这里烂那里烂，可能只是你没有深入了解一个行业，你深入了解之后，你会惊叹于你吐槽的东西，可能别人都想过，只是因为各种商业原因，最后不做而已。

看到没，你的思考并没有壁垒。

思维零散

我们大脑的思维很多时候是一个个思考点组成（如下图。当然，不同思考点的深度有差异），很零散，这会想到一个东西，等会再想到一个东西，思考很容易不成体系，这就导致了很多时候的落地方案并不完整，思考会不够全面，容易遗漏。

容易陷入自我经历/认知误区。

产品思考很多时候是自己经历认知的反映，设计出身的产品会比较在意界面呈现；交互出身的产品会比较在意体验的感知；开发出身的产品比较在意逻辑的严密；运营出身的产品会比较在意数据的的反馈；或者因为之前做产品的经历，也会让你特别注重某些方面。经历往往会促使你对某方面比较执着，造成在思考的过程中不自觉的思维倾向，这种情况下，很容易思维走偏。

智商的竞争力；思维零散、容易遗漏；容易陷入自我经历/认知误区。

先了解冥想的存在问题，我针对性的给出了一些解决方案，也许能帮到您。

1.优化思维方式

虽然有前面说的智商和思维的弱势，但很少人会意识到这个问题，很少人会真正的去优化自己的思维，为什么有些人无论在哪个行业哪个岗位都能做的很好，为什么有的人能把工作家庭都两方都处理的很好，为什么有的人什么都做不好，无论尝试多少岗位、多少公司，甚至都没有体验过一次领导对你任务完成的交口称赞，除却做事执行的问题，很可能是你思考的方式有问题。

举个李叫兽的例子，李叫兽在学完《金字塔原理》之后，觉得这应该实践，将金字塔原理加以运用，一个五分钟能写完的会议通知，在运用了金字塔思考和表达逻辑之后，他用了一两个小时。

虽然很繁复，甚至在外人看来有点自讨苦吃，但这这极大的锻炼到了李叫兽的思维方式，这种深度的思考练习，在脑袋中留下深深的印记，在面对以后发生的问题，有非常结构化的思考方式，他的事后总结的自己的思考方式，还有他的文章，篇篇十万加的文章，有很强烈的金字塔原理的思维印记。

李叫兽是通过书本去训练自己的思维方式，当然，工作中我们不仅仅也只是通过书本，我们可以通过网络、通过同事、通过朋友，同事之间，觉得别人思维方式不错，了解下他们面对问题的思维方式，他们在遇到问题该怎么分析问题，怎么抓重点，怎么着手落地。取长补短，了解这些，很可能有对你收获，助于你优化思维方式。

2.分析解决问题的方法论。

前面说的是思维，思维的优化是顶层去解决思考的缺陷。这个小节要说的是具体问题具体分析，我们要分析总结具体问题的方法论。

除却思考方式，我们在面对不同的问题的时，每类问题都应该有每类问题的解决思路。产品并不是一接到需求，埋头就干，磨刀不误砍柴工。

以用户痛点的思考为例，很多产品经理在思考用户痛点的时候，联想下自己过往经历，联想下用户某个场景可能的情况，联想下朋友或者一些相关人员的说法。东一榔头西一棒子，这种思考随便一个产品深度用户人都能说出一些，这么缺乏深度广度的思考，你的竞争力在哪里？

正确的方式是怎么样的呢？在查阅了资料经过分析之后（对，要就事论事的分析和查阅，了解自己的认知盲区），简要的结论是这样的：用户的痛点，一定要结合场景、角色、情感、产品。是的，并不是这会想下场景、那会想下角色，不应该是零散的，而是要建立各种角色下用户的场景使用逻辑，建立结合场景、角色、情感以及产品下的用户使用流程逻辑，建立完整的使用路径有秩序的分析用户痛点。这样才能思考的够深入，痛点思考的够全面。

李叫兽打架是他一帮朋友中最强的，为什么？他发现，所有人打架都没有去查过资料、看过别人的分析，怎么打架才能赢，没有做过任何科学的分析，更多的是凭自己的感觉，而他，专门花时间去分析了这个。

前面说的痛点也好、打架也好，遇到问题，分析下是否能建立方法，或者了解下其他人的解决方式，形成解决问题的方法论，能更为高效的帮你分思考问题。

3.小范围验证。

哪怕是有了思维的优化，方法论的建立，并不代表你的思考一定正确。你需要做的是小范围验证，在需求落地前的验证。

• 有数据，去查阅数据；

• 旁边有其他的产品经理，你可以跟他们沟通下你的想法，看看他们的意见；

• 当然，也可以跟部分用户聊聊。

小范围验证是了解自己的想法的正确与否，那么你就需要建立一个指标，而不是问了那么多人，两三个人同意了，你就觉得可以行了，不要让主观意志影响了你应该客观的决策。

之前听一个炒股的牛人说，炒股最可怕的是自己意志，看到涨的时候不想放手，看到跌的时候不愿意不敢投入。后来他想了个办法，每次涨跌，随机问周围炒股一般般的8个人，当这八个人都说看涨的时候，那么就应该是自己脱手的时候了。

对于产品来讲也一样，通过小范围验证自己的想法，建立验证指标，确保客观。

除了印证想法的正确性之外，还有一个好处：也避免评审被集体喷。你能通过事实告诉这些人，这并不是我的个人非常主观思考和感受，我有依据。

4.找个合理的理由。

假设没有数据，假设你问了几个人，他们给你的答案模棱两可，但你依然觉得你的思考的正确，这个时候你要做的是，想办法找出合理的理由，你不能只是说，我觉得就是怎样怎样。

理由的来源可以有如下几种：

1.心理感知。

有些东西我们是没法说出现实的，比如你策划一个优惠活动，玩法是你自己自创的，你并不确定这个活动下去效果一定好，但是有个心理理由，那就是用户都喜欢占便宜，在优惠活动并不需要多大的成本消耗的情况下，大家认同的心理理由支撑，也是合理的。

2.用户使用习惯。

你所了解的用户的一些行为或者认知习惯。

3.过往类似问题处理经验。

什么是经验，经验是走过错误的道路的总结，是你的素材库，当遇到问题，在脑袋中搜索下过是否有过往面对此类事情的处理方式，这样处理之后会怎么样，不这样处理又会有什么样的后果。

4.自身经历

产品经理应该都有浏览其他产品或对生活中一些顺手不顺手的小细节观察的习惯，当你面对没有用户、市场、数据做支撑的时候，也许别人怎么做，别人那里做的不好，生活中哪些不顺手你想吐槽的，哪些你觉得很爽的，都可以成为你的决策依据。

不能只是自己觉得很对，但是就是说不出个想法来。你讲不清楚的东西，你一定没有想清楚，我很信奉这句话。又不是老板，说出来了就可以强力执行，那当然只能被喷了。

5.一套方案，而不是一些思考点

关于冥想的问题前面说了，当我们产品经理接到任务，脑袋中都会闪现一些产品中可以优化的东西，但是很多时候是一些散点。

不少产品把这些思考的散点汇总下，就形成了落地方案了，但这明显是不够。如果你是老板，你看到一个产品经理给你的解决方案是这里可以改下，那里可以改下，每个好像都有用但感知上又不怎么明确，修改点相互之间的关联不大，没有一个核心主旨或者多层次的考虑，你会是什么感觉。

你是不是会觉得，这个我也知道啊，我要你产品经理干嘛，我要的是思路完整的解决方案啊。

我们在面对问题的时候，我们是需要思考在当前任务下的一系列的解决方案，将原来思考的散点串联起来，形成一个解决问题的核心主题，再在这个主题下逐个检查产品中需要做的事情。将主题内产品的各个交互、流程、界面、功能、以及文案所有牵涉到东西都做一遍再分析，再根据分析结构来是否要改（做），怎么改（做）。

另外，如果怕遗漏，给您一个建议参考，飞机在起航前都有一个例行检查的过程，准备一个清单，检查各个操控面完好灵活，飞机机体结构正常，传动和液压系统可用，冬天的话就顺便看看有没有结冰什么的。我们在做方案的时候，也可以这样考虑，列出一系列容易遗漏的清单，在设计方案的时候逐个检查打钩，确保方案的完整性。

总结下

让冥想出来的需求靠谱，以下几点也许可以帮助您.

1. 优化思维方式

2. 分析解决问题的方法论。

3. 小范围验证。

4. 找个合理的理由。

5. 一套方案，而不是一些思考点。