产品经理的需求和需要

产品经理如何识别用户的需求（need）与需要（want）？

我在前司的时候，要负责带几个产品同学，有一段时间一直很头痛于他们不知道明确用户提出的需求，反而沉迷于某些具体功能的实现，于是我们花了蛮长时间来讨论“需求”和“需要”。今天也刚好借机聊聊我对“需求”与“需要”的理解。

一、谁不想要一匹更快的马呢？

产品经理很喜欢用福特那句“我想要更快的马”来描述，理解用户提出的“需求”而非“需要”的重要性，由于大多数潜在的消费者，无法表达出自己内在真实所需求（need）的事物，只能用已知信息描述出那些外在需要（want）的事物。所以，通过各种方法与手段找到“藏在表面信息之下”的真实信息，是产品经理最重要的能力之一。

但是在某种意义上，“需求”与“需要”又很容易进行理解，比如有的人是为了生存所以需要工作，有的人是为了果腹所以需要吃饭，有的人是为了财富自由所以需要买彩票，在这三个语境之中，前者都是人们内在的真实需求（need），而后者则是他们所表达出来的外在需要（want）。

对于产品经理而言，弄清楚“需求”与“需要”的边界关系就十分重要了，需要（want）是那些具体的，外在的，有指向性的解决方法，需求（need）则是那些内在的，指引行为的真实原因。

之所以产品经理有着不同能力区分的很重要原因之一，就是因为我们所说的“产品需求分析”并不是单一的因果关系，并不是用户说 A 就解决 A，说 B 就搞定 B，而是需要结合用户身处的真实场景，在真实的行为动机基础之上，结合提供解决方案所需要耗费的成本进行综合考量。

如果产品经理不仔细分析用户需求，就很容易走入“听风就是雨”的循环中，陷入一边抱怨“为什么我已经满足了用户想吃面，想吃饺子，想吃花卷，想吃米饭等各种定制化需求，但是用户还是要吃各种新的”，又要一边着手满足用户提出“下一道定制菜品的需求”的死亡循环里面。

这样的结果，要么做出的功能只能在单一层面解决用户所遇到的问题，要么解决了一个压根不存在的场景中问题的解决方法。

二、正确认识需求收集的过程

有一些同行也会用一些奇怪的比喻来描述自己挖掘需求的场景。比如在表述挖掘需求的时候，喜欢用“引出”和“捕捉”这样的形容词来描述自己是怎么挖掘用户需求的，但这样的形容词会给我们一种错觉，“需求已经真实地存在于某个地方，我们只需要让用户帮助我们把需求解释清楚，然后把需求整理输出就完事了”。

实际上，很多需求并不那么容易想到，这也就是为什么产品经理不应该指望用户自己能够清晰地描述出自己的需求的原因。

在 Suzanne Robertson 这篇论文Requirements Trawling: techniques for discovering requirements中，使用了 Trawling（拖网捕捞）这个词来描述收集需求的过程（用“捕捞”这个词蛮有意思的），那就让我简单聊聊“拖网捕捞”吧。

为什么要使用 Trawling 这个词呢？

首先，不同网眼大小的网可以捕捉到不同大小的需求，我们首先通过大网眼的渔网捕捉那些 epic 级别的需求，建立起自己对于产品的整体感觉与核心认知。

在此之后，我们使用网眼稍小的渔网来找到那些中等大小的需求，建立起产品如何通过不同的或大或小的功能实现某些商业价值的认知。

其次，Trawling 这个词也可以表达另一种含义，产品需求像鱼一样，会随着时间和各种外界因素从小长大，也可能走向死亡。

刚启航时，渔网可能会漏掉某些不重要的小需求，但可能随着船走向大洋深处，有些曾经的需求则可能会变得越来越重要，而某些曾经被认为十分重要的需求又可能开始变成无效的，过时的需求。

此外，世界上应该没有哪个渔网能够捕获所有的鱼，产品经理也不可能捕捉到所有的需求。

在拖网捕捞的时候也可能捞到一些海洋垃圾，会影响渔网的体积，拖慢船只航行的速度，而某些无意义的镀金和膨胀，也有可能影响产品迭代的整体节奏。

最后，不同专业度的捕捞人员很大程度上可以影响最终捕捞的结果，产品经理也是一样，专业的产品经理知道在哪里怎么找到需求，而经验稍浅的产品经理咋可能使用低效的方法，或者在错误的地方浪费时间。

三、分析需求的框架和能力

回到正题，我们知道用户故事一般会这样进行表述，即 “作为一个<角色>, 我想要<功能>, 以便于<商业价值>”，而产品需求分析也可以借用这个框架进行表述，即“我们为谁，用什么方法，解决了一个什么问题”。

在这句话中，“谁”是指我们通过用户调研方法明确的目标用户，“问题”则对应上文中所提到的需求（need），“方法”就是我们最终提供的产品方案。

再然后，通过切实结合用户的真实身份（职业场景，教育背景），需求场景（用户在什么时间什么地点会使用产品），来明确需求实现后能够带来的用户价值（用户用起来更爽）和商业价值（公司通过提供需求解决方法获得正向收益），就能够很大程度上完成需求的拆分了。

不同行业中的不同产品经理，在分析需求时都有自己习惯使用的工具和方法论，但对于大多数产品经理而言，能够做到以下三条原则，分析需求的能力都不会太差。

1. 耐心的倾听

不管你做的是什么行业的产品经理，不论你的需求来源是老板，是销售，是客服还是研发工程师，首先都需要把自己的 ego 放小，在他们和你讲需求的时候先开始倾听，才是好好做产品的前提。

有的产品经理会搬出“他们的需求很奇怪/他们的需求是错的/他们的需求压根就站不住脚”之类的话语，解释自己不愿意倾听需求的正当性，但这种思路其实是错误的。

因为需求压根就没有对与错之分，只有需求方和实现方的立场不同。产品经理应该干的事情，就是通过自己的倾听能力对需求的信息进行甄别，从对方的反馈里找到事实，而不是找到观点。

怎么分别事实和观点呢？我来举个简单的栗子：

事实是当前运营同学使用 cms 管理网站文章时，每天最多能够发表 2 篇文章。

观点是经过主观的判断得出的结论，例如产品经理听到运营同学的反馈之后，觉得原因是运营同学太懒，效率太低，不想学习如何使用，所以甩锅给 cms 说不好用。这里的“觉得”就是观点。

而实际情况有可能是因为产品经理在设计 cms 的时候，压根就没有考虑支持富媒体格式，运营同学排版时特别困难，会花费大量的精力和时间在上面，而且因为超时登录的逻辑有bug，运营同学编辑文章时如果时间过长，会直接被踢出系统，编辑的文章也一并丢失了。

再简单一点，事实是今天的最高温度有 36 摄氏度，观点是今天真热啊。

所以，不要轻易下结论，而是要基于现象分析背后的原因，基于真实的原因再形成观点。

2. 细致的观察

可能你知道很多种调研需求的方法，用户问卷，访谈，工作坊等等，但我觉得在某种程度上来说，去需求场景中观察用户的行为，在用户的身边看他们做了什么，才是最直接的。

举一个实际的例子，我之前做过一款派车系统，有一天用户打电话反馈，希望能够基于车辆已有的各种属性，对车辆进行筛选排序，上线一个自定义筛选推荐功能。

但实际上如果真的要实现这个功能，可能专门需要花一段时间设计算法，然后再考虑如何完成简单好用的功能与交互设计，这一个功能花费的成本其实还是蛮大的。

而且我很担忧，当产品真的提供了这个功能之后，用户压根不用，还是会使用默认的综合排序，所以我就专门跑到用户现场，看他们在真实派车时会参考什么数据，结果就是用户只是单纯觉得“这个不同自定义筛选排序的功能，可能会很有用而已”。

观察用户需求时，也需要把用户当成一个“真实的，有思考和动手能力的人”进行观察，观察他们在遇到问题或者暂时不具备的功能时，会如何处理，而不是理所当然的假设“用户会先 A，再 B……”

3. 坦诚地感受

坦诚的感受，换句话说就是丢掉自己的“上帝视角”，少假设，多感受。

就像你和好朋友在发生争执的时候，到底是会“像一个理性的人一样先暂时停止残酷的交流，让双方都有机会静下来后再去交流”，还是会“一边努力的抑制自己情绪上的爆发，但又还是会忍不住的说几句火上浇油的话”呢？每一个产品经理都觉得只有自己才能真的理解用户，但实际上，我们理解的只有自己。

设计者视角永远是俯视，在遇到用户反馈的问题后第一反应都是“这个功能这简单用户为啥就是学不会？”，而只有到真实用户的环境中去，直面用户遇到的问题时，才能理解用户，也才会发现“原来是因为这两个按钮之间的距离太远了，这个按钮太小了，操作起来太不方便了，怪不得用户觉得不好用”，也正因为这样，才能产生真正的同理心。

本文作者 @Wannz

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！