对于产品经理来说，想出解决方案并不是最重要的，更关键的是，寻找到正确的问题。那么，该如何找到正确的问题呢？本文作者分享了他的看法，希望能给你带来一些启发。

如果你一接到需求，就直接点开软件，设计原型，那你很可能是在朝着错误的方向狂奔。

01 设计需求，为什么费了老劲还没用

最开始做产品设计时，我接到一个需求，就会不假思索地“快速响应”，因为我感觉解决了多少运营同事的需求，就好像是我自己给自己打分的一个指标，出的需求快又多，同事也会觉得你靠谱，最终结果肯定也会好。

我会打开各种原型软件，花力气画啊画，然后评审，进入开发流程，上线，等待好的结果。

我以为这样子，快速设计好了功能，就能像勇者拔出了石中剑一样，后续故事就是凯歌频传、一路平推了。

但可惜，现实世界不是这么运作的。

当我们被自己的想法振奋时，我们会很快列出一系列的实现想法的路径——也就是解决方案，这会花费我们很多的精力。但大多数的产品都没有成功，这不是因为我们文档没有写好，需求没有对齐，而是因为我们没有锚定正确的问题。

在经历或看到了一次次费老力的研发，毫无成果后，我理解到：画出原型、制作好功能、沟通协调等等远远谈不上是“宝剑”，它更像一个个加buff的小道具，而锁定攻击目标，才是“宝剑”。也就是说，我们得先找到正确的攻击目标，而不是对着空气输出。

02 因为对着空气输出，就谈不上“伤害/经济转化率”

那么，正确的攻击目标在哪里？我们该怎么找到它？

下面会慢慢说下推导逻辑，想直接看结论可翻到下一个标题处。

那我们接着说。随便打开一个产品经理的岗位需求，都能看到说“要具备优秀的逻辑思维能力、数据分析能力、沟通协作能力”，刚打算做产品经理时，我看到这条岗位需求就觉得奇怪，这需求是想干什么呢？为什么产品经理这么需要它们呢？以及，你们到底想要应聘者干啥，能不能说得具体一些？

成长后，我有了个答案：产品经理是公司中，“去寻找正确的问题，而不是寻找正确的解决方案”的人。

正确的问题是压倒所有一切的关键。

进一步说，产品经理是一个解决why和what的人。why是1，what是跟在后面一个个的0，如果why出了问题，一切what都没有用。

而要找到why，就会用到一个人的逻辑思维能力、数据分析能力。这有点倒过来的意思，企业实际上想我们能帮它解决形形色色的问题，但逻辑思维、数据分析能力只是能找到why的充分条件。

拓展一下：

逻辑思维能力有个经典问题叫“费米预估”，就是说一位叫费米的教授，在课堂上问学生：“芝加哥市有多少调琴师”，学生懵了。然后费米就引导大家：我们先看芝加哥有多少人口，再看人口里有多少人有钢琴，再看钢琴多久需要调音一次，再看一个调音师一天能调多少架钢琴，最后综合这些条件，给出结果。

面试中，出现费米预估的用意就是在考你，能不能在条件模糊的情况下逐步给出大致正确的解法。

为什么产品经理面试时会考到这种问题呢？因为我们在真实工作时，就是要通过一系列步骤，去定义问题、拆解问题。

那怎么能定义好why呢？

经典的死亡循环是：

1. 用户反馈产品哪个方面不好，他们想要A功能
2. 我们听取用户的意见，开发了A功能
3. 用户说“这不是我想要的”或者对这个功能无动于衷

为什么会出现这个问题？

首先，我们要认识到用户往往提供的是一个解决方案，而不会告诉你他真正遇到了什么问题。事实上，用户不是专业的设计人员（他们希望你是），即使面对他们自己的问题，他们也难以设计良好的解决方案。

还有，用户的反馈并不能真的代表他们的行为。有一个经典的案例，调查人员询问用户更喜欢哪种颜色的索尼随身听，大家都选了黄色。但最后，他们让用户选一个颜色的随身听带走时，大家拿走了黑色！

所以，在用户给出的解决方案上，直接设计产品功能，并把它们开发出来，是非常危险的。

03 那我们要怎么做？

我们不问用户，不听取用户的建议，我们测试用户，我们从测试的结果中学习。

简单来说，我们就是要做实验。想象自己是个白大褂，我们要控制变量，才能得到可信有效有说服力的结果。

而实现上述目标的方式，就是MVP。MVP是“最小可行性产品”的意思，说人话就是指，MVP是一个小实验，是一个我们未来巨大理想的一个最小的切片。

你可以把产品设计过程看成制作一个蛋糕，我们首先想保证，费大力气做出来的蛋糕有人要吃。MVP是说，ok，我作为产品经理，不知道这么设计蛋糕，大家喜不喜欢吃，那么，我想先仅仅从未来的大蛋糕上，切一小块蛋糕出来，这一小块蛋糕有着和大蛋糕差不多的设计，但是它很简单，它只保留了大蛋糕最核心的要点。

那么，有了这块小蛋糕，我们就可以找一堆我们的目标用户来品尝，看看他们有什么反应。他们可能会不感兴趣、或者提出自己的想法，最好的情况是，他们想预订大蛋糕。而这一切用户的反应，会对我们真实的产品设计，起到很大的帮助。

因为这一次次的MVP实验，不仅节省了大量研发费用，还为你开发或者不开发这个功能，提供了定性或者定量的支持。这样我们就能更好地向上汇报或者向其他部门沟通（拉更多人下水，不是）。

我们快速的“失败”，就像一次次派出侦察兵前进，这为我们增加了最后成功的概率。

04 因为世界复杂，所以我们采用自下而上的设计

在最后，我想说，世界上很多很多发明都是自下而上、一步步试出来的。比如，微波炉是二战中美国一位雷达工程师，偶尔发现微波加热了他裤兜里的巧克力，才去研究发明出来的，并不是特意要研究的结果。

我们做产品时，其实一次次的MVP就给了我们很多这种打开未知大门的机会。当然，如何设计MVP，怎么验证MVP效果，领导不想搞MVP就逼着你给个确定的时间该怎么弄……等等问题，没法一次聊完，之后梳理出来再聊。