如何识别需求？
在什么是产品需求中，我们讨论了需求的定义和特点。在了解需求的属性之后，我更感兴趣的一点是，需求是如何被发现的？
为什么移动设备的大量出现，美团会发现外卖配送的机会？为什么 4G 网络的推出，会推动抖音、快手这些视频平台出现？AI 为什么在 22 年末突然火了而不是在 10 年前？识别需求相当重要，它能够帮我们厘清需求的发展脉络。
需求的迭代演进
许多需求在互联网没出现之前就已经存在，人类天生就有吃饭、娱乐、社交的需求。围绕吃饭，我们会想如何吃得更好、更健康。在娱乐方面，我们 会去思考如何让快乐和幸福变得更加易得。在社交方面，我们会想以不同的方式去彰显个人，宣扬观点，以实现自我价值。
不同的逻辑会衍生出来不同的需求。就拿 "吃饭" 这件事来说，为了吃得高级或者款待朋友，我们会花重金去高级餐厅吃饭。或者将食品食材作为财富的象征，比方说鹿茸、花胶、燕窝等等。又比如为了吃得更健康，市面上会出现相应的轻食、补剂，以及针对你的目标而量身打造的减脂或增肌饮食。
在互联网没有普及之前，多数人了解的方式都是口耳相传，哪家调味好，哪家食材新鲜。至于开在山里的农家乐，遇到也只能 "以身试毒" 得到反馈。信息以记忆的方式储存，而信息的交流则是通过人与人之间的信息传递，这是一种最原始满足需求的方式。
在互联网普及之后，市面上有了地图软件、点评软件，信息扩散性的速度非常快。抛去带有营销性质的内容，餐馆能够以榜单、帖子的形式让每个人看到，心里有底。同时包括探店、试吃等类型的短视频流行，也进一步加快了我们了解一个地方美食、优质餐厅的效率。
举一个社交领域的一个例子，目前我们熟知的社交产品，比方说国内的微信、QQ，国外的 Facebook，X（Twitter），这些社交产品并非一开始就是以 App 的形态出现。最早的互联网社交产品是个人网站，大家通过建站，在网站上放置个人的照片和信息，以此和其他人产生联系。
但这种形式存在一定的技术壁垒，首先要购买域名、配备服务器，还有懂一点前端代码。于是在这个基础上出现了第二代社交产品，比方说 Chinaren 和 GeoCities，这类产品允许用户自行搭建组件建站，大大降低了用户的操作难度。
再往后，博客（blog）出现了，不同的作者每隔一段时间会在网址更新一篇新的内容。博客的好处在于它不像个人主页，用户访问过一次就知道你是谁了，博客的形式增加了更多访问量和互动。结合后续出现的 RSS 服务，只要有博主更新了博客，订阅用户就能够第一时间收到消息。
后来，事情发生了变化，社交媒体衍生出了两条分支。一条是创作方向，基于较低的流量成本、移动设备的升级以及机器学习算法，演变出了推荐能力。另一条路径是基于博客和熟人关系的演进，比方说 Facebook，Twitter（X）、LinkedIn。这些产品最终也不会止步于客户端的形态。
从个人网站到博客、Facebook、Twitter，再到 Instagram、TikTok、Clubhouse 以及如今正处于概念阶段的元宇宙、虚拟现实社交产品等等。需求一直存在，需求曾以不同的方式被满足过。但不同阶段的需求，使用产品的人群、影响的范围不尽相同。在一款产品走向大众、爆红的节点之前，已经有许多人尝试并体验过产品 的早期和发展状态。
认知决定论
所以回过头来解答如何识别需求这个问题，产品经理识别需求最重要的一点是认知。你如何看待技术、环境的变化以及不同人群的喜好？
在博客的出现（2000年）的 5 年前，技术方案就已经成熟，但因为互联网整体认知的不足，博客的需求并未被立马发掘。Google Wave 在推出几年后就因为功能过于复杂最终关停，但后来许多热门的在线协作工具（比如 Slack）都采用了 Wave 的大部分功能。许多超前的需求都有人尝试做过，失败了，但这并不影响未来能够满足需求的产品诞生。
借由网络效应，现在互联网大部分对技术和环境的讨论都是超前的。或许说，我们不仅会讨论当下技术的难点，还会讨论未来需求和产品的形态。比方说当我们讨论所谓的 Web3 和区块链的时候，认知相当重要。Web3 是否是 Web2 的下一代版本还是说一个伪需求？区块链所宣传的去中心化理念是否是未来的发展方向？还是说仅是对日渐集中化的世界的一种叛逆？认知决定了产品经理如何处理当下的需求，也决定着他们对未来的看法。
了解产品为什么失败：还有一个提高认知的方式可能很少有人提及，就是去看产品是如何失败的。产品大佬们在关键节点是怎么做决策的？什么导致了失败，原因是什么？推荐大家去听潘乱的播客节目：乱翻书
微观层面的需求
在需求章节中，我花了较多篇幅去讨论宏观层面上的需求。之所以这样设置，原因在于许多产品经理很难站在一个开创者或者 Leader 的视角去看待市场和业务，缺乏这个机会。通过微观层面的探讨，可能会让产品经理对需求有更深的理解。
用研反映了什么
当你的女（男）朋友生气的时候，他们会说出自己生气的原因吗？大部分情况下他们只会生闷气或者让你猜。工作中的客户也很少会说出自己的需求，比方说某个客户想要在 CRM 系统中增加某个功能，如果这个功能相当复杂，总不能耗费 1~2 个月的人力去做出这个功能。
用户会直接说出自己的需求（Needs）吗？实际上，大部分用户提的不是 Demand 就是 Requirement，极少有人提的是 Needs。就像没有汽车的时候，人们会想要更快的马。没有灯的时候，人们会想要更大的蜡烛。
在用户研究领域，做调研同样会遇到这个问题。在 20 世纪 20~30 年代，霍桑去研究如何提高流水线工人的效率，结果发现了霍桑效应。我们今天在做用户调研的时候同样也会遇到这个问题：关于人的心理的变化。有可能在 1V1 面谈的时候，用户为了打破沉默，缓解尴尬局面，会特地说出调研者想听的话。或者为了不让自己看起来比较傻，忽略了自己操作时遇到的错误和问题。这导致产品经理会丢失一些关键信息。
霍桑效应：当人们在意识到自己正在被关注或者观察的时候，会刻意去改变一些行为或者是言语表达的效应。
于是，洞察用户需求就显得非常重要。很多文章都说过产品经理要有洞察的能力，洞察是个很高级的词汇，但在我看来，洞察没有那么玄乎，无非就是 "猜"，去猜用户想要什么。
举几个例子：
- 老板跑过来找你，要让你做一个系统，能够快速处理复杂的报表数据。你一听就感觉这是工程量非常大的需求，那么你可以先做多轮提问，问清楚老板究竟想要什么，最终发现只需要做一个简单的命令处理就可以满足需求了，皆大欢喜。
- 但很多时候，需求都是上传下达的，到了你这就只剩下一句话了：做 XX 功能。一般这个时候进行多轮提问会很困难，总不能逐级上提或者跑去找大大大老板吧。所以你只剩下一个选择，洞察（猜）。做多几个类型的原型图给老板，最终会得到一个确定的方向或结果。
用户研究是一件很 "玄学" 的事情，玄的地方在于产品经理很难猜到用户究竟想要什么？有时候用户说过我想要某个东西，但是这个东西的自 定义程度很高，不太可能为用户专门定制化这个功能。那么在做过调研之后，我们可能会发现用户其实想要的是自定义的能力。后来许多行情软件就支持了指标参数的自定义能力。这是从零散的需求中寻找共性。
相反，当产品研发团队或者营销部门提出要做某个大功能，比方做 CRM、SaaS 或者 OA，直接做一些行业通用（共性）的功能就不太适合了。一般不同的公司有独特的需求，这要求产品经理去寻找特性而非共性。那么做法还是相同的，多轮提问或者列个功能清单让其他部门选择。做出来的产品可能不是最好的，但是是最符合内部运作需求的。
识别误区
很多产品经理经理（包括我）早期做需求的时候会遇到一个误区，接到老板或客户的需求就直接开冲，上手做。结果做出来就是难用，老板沉默，客户尴尬。他们不会说什么，毕竟需求就是他们提出的。你觉得自己能力非常好，做的东西大家都很满意，虽然没收到好评。
这种误区经常发生在内部团队和外部客户，由于各种原因。团队说想要一个功能，你做了不好用，团队也不会明面吐槽你。一是觉得耗费了人力工时，二是又不好意思接着提修改，成本较高，没有办法硬着头皮先用着。做外部客户调研，客户说缺少了某某功能，你满心欢喜地给团队反馈做了出来，结果后续数据反馈使用率几乎没有。可能客户当时只是不得不回答，或者只是想搪塞你，尽快结束这场对话。
真正有效的办法是去问那些用了产品的人。产品不好用，客户会在反馈群里开喷，这类需求是很明显的。某些问题和需求不明显的，就需要去 找那些对产品认可的用户搜集意见。
在我们讨论需求 (Needs) 的时候，有很多的误区需要去识别，很多人会说我要一个解决方案，要一个结果。但是解决方案并不等于需求，产品或功能里的需求有很多，但是这些需求都隶属于一套解决方案。洞察解决方案中用户需求的真正目的，识别哪些需求是重要的，是贯穿产品经理洞察力修炼过程的核心问题。