产品经理的需求和需要.docVIP

产品经理的需求和需要 / 产品经理如何识别用户的需求（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），“方法”就是我们最终提供的产品方案。 再然后，通过切实结合用户的真实身份（职业场景，教育背景），需求场景（用户在什么时间什么地点会使用产品），来明确需求实现后能够带来的用户价值（用户用起来更爽）和商业价值（公司通过提供需求解决方法获