1.2.1 真正的需求

幼儿园老师给小朋友布置了一个任务：带一条鱼来班里观察。小朋友告知了家长后，第二天上课，让人啼笑皆非的场景出现了（如图1-3所示）。面对老师的一个看似直白但其实需求非常模糊的任务需求，每个家长给出的反馈有时差别就是这么大。

产品经理收到的需求很多，既然人们对于“带一条鱼来班里观察”的理解都能千差万别，更不用说产品经理在产品设计过程中要面对的各种纷繁复杂的需求了。在面对各种需求时，产品经理需要先解决一个问题：辨别需求的真伪。

先来看看伪需求是什么样子的？

这不是歌词，而是提需求的人常说的话。

另外，用户提出的需求常常是这样的：

以上3个需求都是伪需求，也就是说，不是真正的需求，但它们又常在产品经理的需求登记表里出现。这些伪需求实际上是需求提出者想得到的解决方案，或者是用户遇到的操作问题，如表1-1所示。

常见的伪需求有两种：

解决方案和用户操作问题。

关于解决方案，就是需求提出人希望产品应该怎么做。

这个需求提出者不但提出了产品的解决方案——衣裳，还提出了对产品的体验需求：美丽。

类似的例子还有很多。

用户直接表达产品要怎么做难道不好吗？用户参与设计不正是产品经理想要的吗？问题是，用户既然都开始设计产品了，还要产品经理做什么？

当然关键并不在这里。提出需求的人提供的产品解决方案本身并没有问题，这是大部分需求提出者的表达方式，而且提出解决方案时的参与感会让他们更热衷于表达想法，应该鼓励。

但产品经理不能把用户提出的解决方案当需求来接受。如图1-4所示，实现需求的办法有很多，解决方案也不止一个，提出需求的人的解决方案只是其中一种。接受了这个解决方案就是接受了某个选择，同时舍弃了其他更多的可能性。

产品经理把解决方案作为需求，就会停止挖掘需求，失去获得更准确需求的机会，对产品设计的影响更大。

用户操作问题是用户使用产品时出现的问题，这些问题和解决方案有关，是解决方案的漏洞导致的。

如果产品经理要跟踪产品bug，协助开发或者修复产品功能，那么用户提出的操作问题是极好的用户使用反馈和功能修改依据，但不是用户需求。

也就是说，如果产品经理要对用户提出的功能进行升级优化，设计新的、更优秀的产品，用户提出的操作问题无法作为需求帮助产品经理设计更优化的方案。

用户说修照片时没有美妆功能，在产品优化方案中增加这项功能，这难道不是优化方案吗？

用户提出的操作问题，从另一面看就是用户提出产品解决方案。

所以，用户提出操作问题与提出解决方案是相同的情况，不论是操作问题还是解决方案，如果把它们作为需求来对待将会限制产品设计。

所谓真正的需求，是指：

需求的需求，即：需求产生的理由。

真正的需求才是产品经理要花时间、精力洞察的用户期望。

参与过用户调研、用户访谈的产品经理通常会发现，用户说的经常并不是他们真正想的，用户再三强调重要的东西，在他们实际的行为中常常显得似乎并不重要。

作者曾经组织过一次用户活动——免费发放产品经理培训课程的学习资料。我们打包了一套产品经理培训课程的学习资料包，并通过各种渠道进行发放。申请资料包的同学只要回答几个简单的问题，如：申请学习资料是为了什么？打算多长时间看完资料包内容？回答完就可以免费领取学习资料包。其中申请资料为了“学习，提升自我”的回答占大多数。资料包发放一段时间后，我们对曾经申请了资料包的同学做了回访，回访内容也很简单：再次填写申请资料的目的和学习情况说明。

回访的反馈结果是，超过半数以上的同学没有看过学习资料。

所以即便是用户说出的需求，他们也未必会为之付诸行动，而是仅限于一个想法。根本无法激起用户行为的需求而形成的产品，最终很大可能会失败。

怎样洞察真正的需求？可以通过 “5why分析法” ——对用户的表面需求连问5个为什么，直到发现用户真正的需求。

当然5why分析法也不能生搬硬套，否则容易让需求提出者落入无限的死循环，与产品经理的交流过程恶化。

在询问用户的表面需求产生原因时，通常回答会形成因果链，如下所示。

注意

一旦没有新的回复内容产生，就不要再纠结需求理由的探究。

根据上述沟通内容可以形成如图1-5所示的因果链。

通过因果链不难发现，申请产品资料的同学真正的需求如下。