几类常见的伪需求，看看你认识几个？

这篇文章是根据我的经验和前人的知识，总结了6类常见的伪需求。好了，话不多说，进入正文吧。

“需求”可能是所有产品经理、甚至是所有IT行业从业人员谈及最多的词之一，当提到用户需求时，所有人都能说上几句。

许多需求工作者会把客户的话一模一样的带回来，客户怎么说，我就怎么做，其发挥的作用约等于一支录音笔。需求分析人员如果不能够做到通过客户的阐述，把客户的需求拆解、翻译，那么需求分析工作的意义也就不存在了。

需求工作，做的是一个编译器，而不是录音笔。

在展开说需求之前，我们先来看一张图：

图中包括这么几个要素：用户、场景、任务、需要解决问题（也有人叫诉求、痛点）、用户对诉求的描述。

当然，这几个要素也不都是需求的组成，用户对诉求的描述是对前面四个要素的文字解释，所以不属于需求的范畴。一个完整的需求应该包括：用户、场景、任务、需要解决问题。

基于这四个要素，加上用户的错误描述、相互冲突的需求，共同组成了这么6类常见的伪需求：

• 错误的场景
• 错误的用户群体
• 没有建立在核心任务的基础上
• 没有需要解决的问题
• 用户词不达意
• 相互冲突的需求

本文将从这几个角度出发，介绍几类常见的伪需求。

01 脱离了真实场景

大家一定见过很多拍脑袋、头脑风暴想出来的需求吧，通常就是属于这一类，大家在办公室的场景下和实际用户在第一线使用时候的场景是不同的，脑海里的想法更不可能一样。

这是需求里面最重要的一个要素，如果连用户在什么情况下会有这样的诉求都不清楚，那么后续的所有结果都充满不确定性。

脱离了场景的需求常见有这么两种：

脱离了业务场景，往往是对实际情况不明确，就可能会造成产品的实际效果和预期相差甚远。

就好比你在一个出行APP上前定了一张高铁票，定完之后在预定成功的提示页下面给你推荐了买菜的广告。场景不同，即使拥有巨大的流量，也很难为你所用。

如果说脱离了业务场景是资源浪费，那么脱离了大背景无疑会把产品送上绝路。

2017年，曾今接触过一个在做“云上香”产品的创业者，希望为那些想给祖先上香祭拜，却远在他乡无法实现到场祭拜的人，提供一个在线祭祀的网站。

后来这个网站在运营几个月后关停，草草收场。该网站是在5线城市的小县城里运营和推广，没有人知道，什么样的情况下，能够让祭祀者放弃几千年的习俗，在网上对着一个电脑上香。

而到了2020年疫情期间，祭祀者无法出门祭祀，“云上香”反而火了一把。

产品在新的品类中最容易出现这种怪像：我帮你填满了所有的坑，却只是在为大环境下的后来者培养用户习惯。

02 并非目标用户

脱离了用户群体的需求，常见有这么三类：

• 把自己的需求当成用户的需求；
• 不是我们的用户；
• 过于小众的用户群体；

经常看到有人说产品经理的同理心，要发现用户的需求。我觉得这是个伪命题，产品经理很难深入一线在每一个真实场景的下完成所有任务，即使是产品深度使用者，也很难代表整个用户群体。

但是，常常有老板会乐此不疲的强调所谓的“同理心”，似乎这样能够让自己看起来更专业。

与其说产品经理的同理心是要发现用户的需求，不如说是要了解和验证用户遇到的问题。

除去这种的常见的投射效应，非目标用户提出来的需求也是屡见不鲜。

先不妨来看个故事：

（背景：产品是一个资源管理系统，主要提供图片、视频的录入和共享）

客户领导：我觉得你们这个系统有点不好用啊！

PM ：是吗？哪里不好用了？

客户领导：你看，你们这个上传，上传的时候，都没有要求要打标签。

PM：这个是考虑到便捷性，不然每一张图片都要手动打标签，大家都不愿意传了。

客户领导：你不要这样想，只有每张图片都必须填写这么多信息，大家才会觉得这个事情不容易，才会重视这个事情。

PM：……（心里一万句MMP）

很多提需求的人其实并不是我们的目标用户群体（或许提需求的人自己认为是），所以提出来的需求并没有太大的实际价值。

有趣的是，在B端的产品中，有时候非目标用户提出来的需求会更受重视，可能他们才是直接付费者。

还有部分用户，可能确实有需求，需求也合理，但是这部分人极少，所以不考虑。

大家都知道B站最初是一个ACG视频创作、分享网站，某天一个ACG爱好者想给一个女生买一个包，想看看B站有没有相关的视频，结果没找到。于是他觉得B站这点没做好，应该开设“奢侈品包”这样一个栏目。很显然， 没有哪个产品经理会理会这个需求，因为B站的主流用户的画像和奢侈品包包的购买群体重合度极低。

03 脱离了核心任务

脱离了核心任务的需求常见这么几类：

• 用户并不想完成任何任务；
• 需求偏离了核心任务；
• 和核心任务流程相悖；

有些用户并不会在产品上完成任何一个任务，但是如果你让他提需求或改进意见，他却可以头头是道的跟你说出个子丑寅卯。

常见的莫过于ToB产品的客户领导，他并不需要完成任何任务，却可以从你的幻灯片中看到产品的不足和需要改进的地方。

许多人想把产品做的大而全，这恐怕是最常见的和核心任务偏离了。

来看个关于大而全的故事：

（背景：产品是一个媒体采编系统，核心任务为用户提供写稿、编辑、发布的功能）。

领导：我们到后面要做统计，把数据统计出来并生成报表给用户。

PM：这个是要做的，已经在考虑了。

领导：我们要做个网盘，用户可以自己上传东西上来，采写稿件的时候可以用到。

PM：额，这个应该不是那么重要吧。

领导：我们还要做个杂志阅览的功能，我上次看有些客户有自己的出版物，可以放上来，到时候就不需要找书翻资料了；

PM：……

故事中的领导可能是很多领导的缩影，就是我什么都想要，这就容易陷入一个泥潭，越是想做大而全，越是容易做成大而“烂”。

避免大而“烂”，确认产品定位是关键，否则，所有的需求不算超出产品的边界，因为我的产品边界就是整个互联网的边界。

和用户的核心任务流程背道而驰，其实就是我们常说的“不符合用户习惯”的一种。其实这里面又可以分为三种：

• 简化用户核心任务流程；
• 复杂化用户核心任务流程；
• 脱离了原有的任务流程；

严格意义上讲，三种都可以是伪需求。可是实际上，简化了用户的任务流程的需求，一般不会被定义成伪需求，因为这一类需求往往被认为是解决了所谓的“操作流程复杂”的问题（实际上，即使简化任务流程，也需要经过无数次验证）。

04 没有需要解决的问题

用户没有这样的诉求或者是说用户并没有遇到任何的问题，也不需要你提供任何的解决方案，但是依旧有许多的产品人像是叠积木一样，不断在产品上累加新功能，这往往来自产品经理或者老板的不自信，可能来自两个原因：

一是因为别人有这个功能，所以我也要有，似乎这样能够在介绍产品的时候显示产品的“强大”。用户其实并不关注你有多少功能，更不可能所有的任务都在一个产品上处理，他们只在乎自己的问题是否得到了很好的解决。

二是不开发点新功能模块，就感觉我没做什么工作，或展现不出我的水平。

于是就有了接下来的这一幕，产品经理把成熟市场中验证过的产品功能，跨界移植到自己的产品中。最终产品演化成了一个四不像。

05 用户的描述≠真实需求

其实这一类可能并不是一个完整的需求，但是许多初级的产品经理却对这一类“需求”格外执着，有一些会乐此不疲的做着这些没有意义的工作，还有一些产品会认为这些提需求的用户都是奇葩。

用户说出来的话其实往往是和这四个要素脱离开的，单纯的把客户的话带回来，往往是最简单省事的办法。不合格的需求分析看什么都是奇葩需求，高级的需求往往能透过表面，了解其中原委。

用户的描述经常会出现这么几个现象：

如果跑到用户面前去问用户想要什么，用户会告诉你“我想要这个地方加个按钮，实现……”、“我想让系统进入的时候默认展示个人信息”、“我想让点击提交按钮的时候，出来一个选择框，用来选择……”。

大部分用户告诉你的并不是需求，而是说出了一个他以为的解决方案。

（难道这就是所谓的人人都是产品经理？——关于问题的解决方案似乎每个人都可以说几句）

来看一个案例：

让我们来看看需求的黄金圈法则：

用户说出来的解决方案，往往是和他内在的需求有一定的联系，或许也能解决，但是对于我们的产品来说，不一定是最好的解决方案。

如果用户给你提了个解决方案，不妨问这几个问题：用户是想做一件什么事？一般做这件事的频率？为什么要做这件事？除了提需求的人，还有哪些人、群体需要做这件事？人数大概是多少？目前是怎么做这件事？目前做这件事遇到什么问题？除了用户提出来的这个方案，还有没有其他方案？

除了提解决方案的用户，还有许多只是单纯抱怨的用户，这一类用户或者是抱怨价格太高，或者是抱怨服务不好，或是抱怨其他。总的来说这一类评价可能会对产品的演化、运营方向有参考意义，但是绝不是一个需求，也千万别太过认真。

某外卖平台APP评论

06 冲突的需求

这一类的需求严格意义上不算是伪需求，他有明确的场景，建立在任务之中，也有自己的诉求，但是由于他和我们的主体方向偏移了，也就注定和我们的产品无缘。

冲突的需求常见这么几类：

用户有时候会提出两个完全冲突的需求，不过用户有可能自己并不会发现，当然也有更多冲突的需求是不同用户提出来的。

不管怎么样，当两个冲突的需求出来的时候，我们选择了一个，也就注定把另外一个需求视为“伪需求”了。

也有些冲突的需求，产品经理为了把他们全部解决，最终把产品做成了大而全。

比如一个网盘应用，A希望能过把文件夹简便上传上去，B希望每次上传一个文件并填写相应的说明。…… 于是产品经理就设计出来了可以配置的上传功能。

比起相互冲突的需求，和产品冲突的需求似乎就好分辨很多了，简单点的一句话，“我们的产品本来就不是给你去解决这个问题的！”，不过也有些需求会随着产品定位的变化，最后变成需要解决的了。

07 发现伪需求需要对问题的深入了解

需求是一个宽泛又严谨的词，把用户的任意的一个想法当成需求，那是外行人干的事。对于产品人来说，每一个需求一定是能解析、有来龙去脉的。否则我们看需求就会产生四个不知道：看到需求不知道用户为什么提出来，设计出来的功能不知道为什么要这么设计，看到方案不知道有没有更好的方案，最关键是自己还不知道自己啥也不知道。

其实识别伪需求的最直接方式——问几个问题：

• 场景、用户、要执行的任务、要解决的问题是否真实？
• 是否有足够的数量基数？
• 是否要用产品帮用户解决这个问题？
• 是否会影响其他需求？

本文由 @产品李 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议