阿尔伯塔大学的一门关于软件设计的课程中，用Want（需要）和Needs（需求）来区分这两者，前者是“希望在产品中看到的功能”而后者是“确定的具体问题，留待产品解决的问题”。
对于很多用户表面的要求，以及形式上我们“看似”要满足的需求，很多其实都值得商榷。对待这些需求，我们最需要做的是发掘更深处它们代表的是什么、真正的问题在哪里。
基于场景深挖需求
如果你谈需求时，想到的不是具体的画面、不是真实的某个用户、不是真正发生的什么事件，而是一道道公式、各种图形，甚至某个“前辈”的经典语录。那么只能说，你对这个需求的了解程度还是很浅的。
有些产品经理会认为并不需要考虑场景。他们认为一个功能就是单纯解决问题就可以了。例如电商产品可以买到商品就好，至于用户究竟是在地铁上买、在电脑桌前买、在旅途中买应该没有区别吧？如果这样想，就会错过用户真正的使用方法，也就错过了把功能做得更好的机会。
另外一个经常出现的问题就是，意识到了场景很重要，但自己总结出来的场景却跟真实的场景完全不一样。
当讨论需求的时候，我们讨论的究竟是什么？回想一下，我们讨论需求就是讨论如何解决问题，解决了问题也就满足了需求。我们会针对问题描述来设想如何解决。比如，我们要解决大家阅读新闻时信息太繁杂、找不到感兴趣内容的问题，那么做个性化推荐的阅读工具就是解决问题、满足需求。这是很直接的推断。
而我们讨论场景时讨论的本质是什么呢？我们讨论的会是很形象的一些描述。这里面包含了人物、时间、地点、环境及情节。我们要用场景来发现我们的用户是谁、他们会在什么情况下解决原有的问题、他们怎么解决这些问题的，等等。在这个时候设想方案，我们就会考虑更多因素，比如新闻的内容是不是跟用户的身份匹配？阅读的方式是不是在这样的时间地点足够恰当？图4-1中总结了二者的差别。
图4-1 考虑场景时讨论需求的不同
案例1
不同的需求都是在特定场景下才需要满足，做产品时我们就应该考虑到需要服务怎样的场景。
有一位朋友之前做了一个提供境外美食信息的产品，可以理解为境外版的大众点评，主要目标用户群体是境外游的旅客。这个产品的定位其实还是很清晰的，就是解决餐馆的信息不对称的问题，境外游的旅客需要找餐馆就餐，就跟在国内的我们中午想找地方吃饭经常用大众点评一样。所以他们起初做的，就是仿照大众点评，提供了很多包含距离、口味、类别、价位、评分等属性的餐馆信息，以结构化数据的搜索和筛选作为主要功能。
但运营了一段时间发现用户的增长并不是很乐观，后来分析发现问题就出在场景上。首先看大家使用大众点评的场景。最常见的场景包括找附近有什么餐馆、找有特定条件的餐馆、找评价非常好的餐馆三种。而这三种场景会是交叉出现的。例如以下的场景。
中午不想做饭了，想找个地方吃饭，不想走太远。看看天气有点凉爽，所以想吃火锅。于是在这样的场景下，需求是找附近的火锅店，需要筛选的是距离和品类两个属性。
晚上约了朋友见面，想找个安静的西餐馆，位置最好在我们两个人中间。于是在这个场景下，需要筛选的是环境、位置和品类三个属性。
周末想吃日料，要找特别正宗的、大家评价够高的餐厅，同时不会特别在乎位置和价格。于是在这个场景下的需求就是发现大家的评分，以及大家留言里对日料餐馆的评论。筛选的是评分和评论两个属性。
从这些例子我们可以看出，大众点评提供的餐馆信息是完全覆盖了这些情景的。打开大众点评看到的也就是距离、品类、位置、评分等筛选项。
再看朋友的这款产品，当你出国在外旅游途中，想吃点什么的时候，你考虑的是什么？你会考虑距离、品类、位置、评分吗？很多人不会特别考虑距离，毕竟这么远的路都走了，所以并不会太在意几公里的距离。很多人可能也不会特别关心品类，因为在国外估计也分不太清当地有几个菜系、分别都是什么。有的人也不在意价格，他们会觉得既然都来国外玩了，吃得好才最主要。
那么用户在意的是什么呢？当然就是“有特色”或者“好吃”，而前者应该是更重要的。旅游的人想吃到当地有特色的菜品，即便平时很少吃甚至不爱吃的。在这样的场景下，产品最需要的是什么呢？那就是——推荐。只要告诉大家：来东京最正宗的日料是什么？有哪几家？哪些最热门、最有特色？到印度最正宗的咖喱、飞饼、炒面都在哪里？要点什么口味的最好？在意大利要怎么找到最好吃的千层面、提拉米苏和海鲜饭……除了这些别的都不重要。图4-2就是基于这种思路设计的概念图。
图4-2 笔者为产品设计的概念图
当我们把场景描述清楚就会发现，需求的细节一目了然，虽然同是提供美食信息，但本质需求却完全不同。
案例2
我们在生活中经常能发现这样的需求，比如有人想理发却懒得出门，于是想到要是有上门理发就好了。有人觉得这就是需求，可以用产品和服务来满足。可是仔细想一下，这个需求足以支撑一个好的产品吗？
将需求放到场景里讨论，你就会发现“上门理发”存在着各种各样的问题。对用户来说，上门理发的工具和设备要在家里摆放和使用会很麻烦，事后的各种清理工作要自己来完成，总的来说体验可能远不如到门店理发；对理发师来说，交通会存在成本，在上门过程中要携带各种设备器具也会特别头疼，等等。
这些问题如果放到场景里去想，用生活经验和逻辑推断就能得出这是伪需求的结论。很多天气类应用也会存在同样的问题。
天气类应用都有一个头疼的问题，那就是难以变现。原因是天气类的产品虽然流量高、需求大，但用户黏性极差，无法沉淀用户。可以说只有“流量”，没有“用户”。
比如有的产品为了尝试沉淀用户，想出了做社交的主意。社交似乎已经成了很多产品的救命稻草了，不管是什么产品都企图靠做社区绝处逢生，但结果往往都不尽如人意。这其实就是典型的浮于表面的需求，未必能解决实际问题。他们的方法就是在产品中加入“分享你当下的天气”功能，大致就是拍一张你现在所在地的天气照片分享给大家。如果整个产品功能运营起来，用户就可以随时看到任何地方的天气实况了，其中可能还有些风景。
乍一看似乎没什么问题——用户可以看到实况，的确比单纯的天气指数更具象。天气预报的颗粒度也未必会细到城市中的某些区域，而通过用户分享实况，就能知道城市里不同区域的真实天气，方便自己安排出行了。但是在用户真实的使用场景下，会发现这个功能跟核心功能很难产生关联。对于分享者来说，到底什么时候、为什么要拍张照片分享给大家，动机并不清晰。找不到比较强烈的动机，这个产品也就不能流转起来了。
这样的情况，我们可以称之为“弱需求”。在考虑和分析需求时，代入实际的场景，便能更准确地判断哪些需求是伪需求、是弱需求。
案例3
早先的手机只能有一种模式，因为主要功能载体在硬件上，所以能做的也就是打电话发短信。而如今的手机已经能够通过软件承载更多复杂的功能，包括提供特定人群使用的功能。
老人在使用手机时会需要什么？可能需要大号的字体、更简单的交互方式，以及更简单的文案提醒。而智能手机提供的很多其他功能，对他们来说并没有意义。同样的，其他特定人群也各有需求。盲人使用手机时会需要什么？可能需要语音辅助提醒来完成各种交互操作。小孩子使用手机时会需要什么？可能需要的是一些内容上安全和保护的措施。如果是朋友或者陌生人要暂时用一下我的手机时会需要什么？可能需要提供访客模式，让敏感的信息和内容不被看到。
考虑不同人的使用场景，就可以分别做出老人机模式、盲人辅助模式、儿童模式、访客模式。另外，对同一个人的不同使用场景，也可以发现很多新的衍生需求。比如同样是使用手机，在黑暗环境下可能需要有特殊显示设置的护眼模式，在开会时可能需要快捷的静音模式，在睡觉和休息时可能需要拒接电话的勿扰模式，等等。
腾讯阅读的一位产品经理曾经写过他们做离线阅读时的思路。他们对需求的定义是：在某些情况下，用户是需要离线阅读的。他们发现在大多数情况下，上班族在临近上下班要出门时才想到要在坐地铁或者公交车时看点新闻，再打开离线下载。
在这种情况下，用户希望的是尽快下载好。说明这时就不要考虑阅读体验了，很多图片、视频信息都可以略过。所以他们最终的产品形态就是：离线下载只缓存纯文字，能保证下载一般在3~5分钟就可以完成。
从以上这些例子中我们能体会到，凭借真实场景，我们能够对需求有更精准的判断，也就能做出更完善的功能。
本文作者刘飞，内容选自《从点子到产品：产品经理的价值观与方法论》。
想及时获得更多精彩文章，可在微信中搜索“博文视点”或者扫描下方二维码并关注。
