Want VS Needs,产品经理基于场景的需求挖掘

阿尔伯塔大学的一门关于软件设计的课程中,用Want(需要)和Needs(需求)来区分这两者,前者是“希望在产品中看到的功能”而后者是“确定的具体问题,留待产品解决的问题”。
对于很多用户表面的要求,以及形式上我们“看似”要满足的需求,很多其实都值得商榷。对待这些需求,我们最需要做的是发掘更深处它们代表的是什么、真正的问题在哪里。

基于场景深挖需求

如果你谈需求时,想到的不是具体的画面、不是真实的某个用户、不是真正发生的什么事件,而是一道道公式、各种图形,甚至某个“前辈”的经典语录。那么只能说,你对这个需求的了解程度还是很浅的。
有些产品经理会认为并不需要考虑场景。他们认为一个功能就是单纯解决问题就可以了。例如电商产品可以买到商品就好,至于用户究竟是在地铁上买、在电脑桌前买、在旅途中买应该没有区别吧?如果这样想,就会错过用户真正的使用方法,也就错过了把功能做得更好的机会。
另外一个经常出现的问题就是,意识到了场景很重要,但自己总结出来的场景却跟真实的场景完全不一样。
当讨论需求的时候,我们讨论的究竟是什么?回想一下,我们讨论需求就是讨论如何解决问题,解决了问题也就满足了需求。我们会针对问题描述来设想如何解决。比如,我们要解决大家阅读新闻时信息太繁杂、找不到感兴趣内容的问题,那么做个性化推荐的阅读工具就是解决问题、满足需求。这是很直接的推断。
而我们讨论场景时讨论的本质是什么呢?我们讨论的会是很形象的一些描述。这里面包含了人物、时间、地点、环境及情节。我们要用场景来发现我们的用户是谁、他们会在什么情况下解决原有的问题、他们怎么解决这些问题的,等等。在这个时候设想方案,我们就会考虑更多因素,比如新闻的内容是不是跟用户的身份匹配?阅读的方式是不是在这样的时间地点足够恰当?图4-1中总结了二者的差别。

图4-1 考虑场景时讨论需求的不同

案例1

不同的需求都是在特定场景下才需要满足,做产品时我们就应该考虑到需要服务怎样的场景。
有一位朋友之前做了一个提供境外美食信息的产品,可以理解为境外版的大众点评,主要目标用户群体是境外游的旅客。这个产品的定位其实还是很清晰的,就是解决餐馆的信息不对称的问题,境外游的旅客需要找餐馆就餐,就跟在国内的我们中午想找地方吃饭经常用大众点评一样。所以他们起初做的,就是仿照大众点评,提供了很多包含距离、口味、类别、价位、评分等属性的餐馆信息,以结构化数据的搜索和筛选作为主要功能。
但运营了一段时间发现用户的增长并不是很乐观,后来分析发现问题就出在场景上。首先看大家使用大众点评的场景。最常见的场景包括找附近有什么餐馆、找有特定条件的餐馆、找评价非常好的餐馆三种。而这三种场景会是交叉出现的。例如以下的场景。
中午不想做饭了,想找个地方吃饭,不想走太远。看看天气有点凉爽,所以想吃火锅。于是在这样的场景下,需求是找附近的火锅店,需要筛选的是距离和品类两个属性。
晚上约了朋友见面,想找个安静的西餐馆,位置最好在我们两个人中间。于是在这个场景下,需要筛选的是环境、位置和品类三个属性。
周末想吃日料,要找特别正宗的、大家评价够高的餐厅,同时不会特别在乎位置和价格。于是在这个场景下的需求就是发现大家的评分,以及大家留言里对日料餐馆的评论。筛选的是评分和评论两个属性。
从这些例子我们可以看出,大众点评提供的餐馆信息是完全覆盖了这些情景的。打开大众点评看到的也就是距离、品类、位置、评分等筛选项。
再看朋友的这款产品,当你出国在外旅游途中,想吃点什么的时候,你考虑的是什么?你会考虑距离、品类、位置、评分吗?很多人不会特别考虑距离,毕竟这么远的路都走了,所以并不会太在意几公里的距离。很多人可能也不会特别关心品类,因为在国外估计也分不太清当地有几个菜系、分别都是什么。有的人也不在意价格,他们会觉得既然都来国外玩了,吃得好才最主要。
那么用户在意的是什么呢?当然就是“有特色”或者“好吃”,而前者应该是更重要的。旅游的人想吃到当地有特色的菜品,即便平时很少吃甚至不爱吃的。在这样的场景下,产品最需要的是什么呢?那就是——推荐。只要告诉大家:来东京最正宗的日料是什么?有哪几家?哪些最热门、最有特色?到印度最正宗的咖喱、飞饼、炒面都在哪里?要点什么口味的最好?在意大利要怎么找到最好吃的千层面、提拉米苏和海鲜饭……除了这些别的都不重要。图4-2就是基于这种思路设计的概念图。

图4-2 笔者为产品设计的概念图
当我们把场景描述清楚就会发现,需求的细节一目了然,虽然同是提供美食信息,但本质需求却完全不同。

案例2

我们在生活中经常能发现这样的需求,比如有人想理发却懒得出门,于是想到要是有上门理发就好了。有人觉得这就是需求,可以用产品和服务来满足。可是仔细想一下,这个需求足以支撑一个好的产品吗?
将需求放到场景里讨论,你就会发现“上门理发”存在着各种各样的问题。对用户来说,上门理发的工具和设备要在家里摆放和使用会很麻烦,事后的各种清理工作要自己来完成,总的来说体验可能远不如到门店理发;对理发师来说,交通会存在成本,在上门过程中要携带各种设备器具也会特别头疼,等等。
这些问题如果放到场景里去想,用生活经验和逻辑推断就能得出这是伪需求的结论。很多天气类应用也会存在同样的问题。
天气类应用都有一个头疼的问题,那就是难以变现。原因是天气类的产品虽然流量高、需求大,但用户黏性极差,无法沉淀用户。可以说只有“流量”,没有“用户”。
比如有的产品为了尝试沉淀用户,想出了做社交的主意。社交似乎已经成了很多产品的救命稻草了,不管是什么产品都企图靠做社区绝处逢生,但结果往往都不尽如人意。这其实就是典型的浮于表面的需求,未必能解决实际问题。他们的方法就是在产品中加入“分享你当下的天气”功能,大致就是拍一张你现在所在地的天气照片分享给大家。如果整个产品功能运营起来,用户就可以随时看到任何地方的天气实况了,其中可能还有些风景。
乍一看似乎没什么问题——用户可以看到实况,的确比单纯的天气指数更具象。天气预报的颗粒度也未必会细到城市中的某些区域,而通过用户分享实况,就能知道城市里不同区域的真实天气,方便自己安排出行了。但是在用户真实的使用场景下,会发现这个功能跟核心功能很难产生关联。对于分享者来说,到底什么时候、为什么要拍张照片分享给大家,动机并不清晰。找不到比较强烈的动机,这个产品也就不能流转起来了。
这样的情况,我们可以称之为“弱需求”。在考虑和分析需求时,代入实际的场景,便能更准确地判断哪些需求是伪需求、是弱需求。

案例3

早先的手机只能有一种模式,因为主要功能载体在硬件上,所以能做的也就是打电话发短信。而如今的手机已经能够通过软件承载更多复杂的功能,包括提供特定人群使用的功能。
老人在使用手机时会需要什么?可能需要大号的字体、更简单的交互方式,以及更简单的文案提醒。而智能手机提供的很多其他功能,对他们来说并没有意义。同样的,其他特定人群也各有需求。盲人使用手机时会需要什么?可能需要语音辅助提醒来完成各种交互操作。小孩子使用手机时会需要什么?可能需要的是一些内容上安全和保护的措施。如果是朋友或者陌生人要暂时用一下我的手机时会需要什么?可能需要提供访客模式,让敏感的信息和内容不被看到。
考虑不同人的使用场景,就可以分别做出老人机模式、盲人辅助模式、儿童模式、访客模式。另外,对同一个人的不同使用场景,也可以发现很多新的衍生需求。比如同样是使用手机,在黑暗环境下可能需要有特殊显示设置的护眼模式,在开会时可能需要快捷的静音模式,在睡觉和休息时可能需要拒接电话的勿扰模式,等等。
腾讯阅读的一位产品经理曾经写过他们做离线阅读时的思路。他们对需求的定义是:在某些情况下,用户是需要离线阅读的。他们发现在大多数情况下,上班族在临近上下班要出门时才想到要在坐地铁或者公交车时看点新闻,再打开离线下载。
在这种情况下,用户希望的是尽快下载好。说明这时就不要考虑阅读体验了,很多图片、视频信息都可以略过。所以他们最终的产品形态就是:离线下载只缓存纯文字,能保证下载一般在3~5分钟就可以完成。

从以上这些例子中我们能体会到,凭借真实场景,我们能够对需求有更精准的判断,也就能做出更完善的功能。

本文作者刘飞,内容选自《从点子到产品:产品经理的价值观与方法论》。

想及时获得更多精彩文章,可在微信中搜索“博文视点”或者扫描下方二维码并关注。

时间: 2024-10-28 19:23:35

Want VS Needs,产品经理基于场景的需求挖掘的相关文章

考考产品经理们:假如你是QQ经理赚大钱的产品功能先做

文章描述:假如你是QQ的产品经理. 基于需求金字塔模型的解答用户需求千奇百怪,先做哪些需求,后做哪些需求,不是由产品经理和公司老板拍脑门决定的. 网名Krrishyan,毕业于北邮英语系,前乐途旅游网产品经理,千橡互动产品主管,每讯产品总监,7年互联网产品经理经验,3年产品团队管理经验,拥有个性化推荐.门户.SNS.电商.阅读类产品,也有Web.WAP.手机客户端.iPad产品.开放平台(微博开放平台和Q+平台)APP产品经验,著有<神一样的产品经理:基于移动与互联网产品实践>一书,共30多万

产品经理怎么做市场调研和数据分析

产品经理对用户的需求了解有多少呢?你知道用户需要的是什么样的产品吗?你想知道用户将会如何看待你的产品吗?你想知道你设计的产品在用户中的看来是好还是差吗? 毫无疑问的是,每一个产品经理都希望在产品开始立项设计之前,可以得到用户最真实的需求,可以为自己的产品设计提供良好的支撑;每一个产品经理都希望自己的设计的产品得到用户的认可和喜欢;每一个产品经理都希望用户能在使用产品的过程中,对于产品改进的意见和建议可以不断地提出建议--那么,怎么样我们才能得到用户的前期意见和后期反馈呢? 这个时候我们最需要的是

产品经理的新三观:数据观、格局观、细节观

数据观:产品经理要重视数据,根据数据做决策,用数据说话.格局观:学会换个角度,从战略层面去考虑问题,格局有多大,世界就有多大.细节观:细节决定成败,无数个经过产品经理优化后的细节,堆砌出令人尖叫的用户体验. 数据观 产品经理要重视数据,根据数据做决策,用数据说话. 靠谱的产品经理,不能拍随便脑袋想做什么就做什么,而是要以用户价值为中心,学会利用数据来侧面验证产品需求的是否靠谱.数据应该贯穿产品需求从无到有的完整的一个生命周期. 网上有很多产品生命周期的讨论,比较形象的一种划分是:幼年-童年-青年

一道难倒许多产品经理的难题

用户需求向来都是千奇百怪,而一款产品先满足用户的哪些需求,后满足用户的哪些需求,这不是由产品经理和公司老板拍脑门决定的. 先让我出一道题来考考产品经理们吧. 在1998年的时候,QQ刚开始规划,而在1999年的2月推出Beta1版本,在1999年5月推出了Beta2,在1999年8月推出了Beta3. Beta1的版本只能实现QQ的3个特性,那么优先推哪三个呢?请各位从以下选项里勾选: 1.卡通头像 2.不可窃听安全通讯 3.聊天室 4.很小的.exe文件 5.皮肤skin 6.速度超快0.5秒

假如你是QQ的产品经理

基于需求金字塔模型的解答用户需求千奇百怪,先做哪些需求,后做哪些需求,不是由产品经理和公司老板拍脑门决定的.先出一道题考考产品经理们:1998年,QQ开始规划,1999年2月推出Beta1版本,1999年5月Beta2,1999年8月Beta3.Beta1版本只能实现3个特性,优先推哪三个呢?请从以下选项里勾选: 1.卡通头像 2.不可窃听安全通讯 3.聊天室 4.很小的.exe文件 5.皮肤skin 6.速度超快0.5秒反应 7.聊天记录管理器 8.语音 9.视频 10.看谁在线上 11.传文

产品经理职场必看的书——《YES!产品经理》

内 容 简 介 这本书中红融合了经管.工具和职场小说特点,而作者则是国内产品经理咨询界最有实力的团队. 本书是以职场小说的形式来全面介绍产品管理.产品经理相关的知识,而所有的问答均被放置在设计好的101个情节中,同时,每一个情节之间也都有着彼此相应的联系,从而让读者能够从具体的情节走向中不止可以了解到产品管理的完整知识,并且还能够深刻感受到一个产品经理的现实工作状态,而从知识点上来说,这本书涉及基础理论.工具方法和企业实施,从目标读者来说,涉及到了个人和企业.相信读者从具体的情节走向中不但能够了

产品经理,很容易走进的的几个误区

1.很容易记得概念,很容易限于形式. 产品经理思考问题的能力基本上都是很强的,只有拥有了思考http://www.aliyun.com/zixun/aggregation/11009.html">分析问题的能力作为前置条件,后面实际执行解决问题的能力才能123有所保障.不过仔细的分析了一下很多产品经理的问题,大家都会犯一个通病. 大家很容易从心底里把自己做的产品.设计的产品形态一开始就跟某个概念去靠近.很多朋友说:"我们老板要做个SNS","我们接下来要做个B

关系暧昧的“产品经理”与“交互设计师”

在互联网工作流程中,产品经理和交互设计师是关系最暧昧的两个环节.说其暧昧,是因为在很多互联网公司里面,这两个环节所做的事情是有重合的,他们往往是整个流程中合作最紧密的两个环节.有人说,产品的最佳状态是产品经理和交互设计师是同一个人.这话乍听有些道理,似乎减少了很多沟通成本.的确实际工作中,产品经理和交互设计师配合是否默契有时候直接影响产品的质量和流程的进度.可是,他们两个真"一条心"就好么? 我不这么认为.首先卖个关子,"矛盾论"里有句话:矛盾是普遍存在的.矛盾的同

把脉微信:操产品经理的心干运营商的活

4月23日腾讯第一次举办专门关于微信的官方沙龙.此前在3Q大战后腾讯开设了一系列主题为"诊断腾讯"的沙龙,而微信的系列沙龙被取名为"把脉"系列,颇见深意.但在沙龙鲜有人把脉微信本身.事实上,微信团队"操着产品经理的心干运营商的活"已经凸显矛盾.尚未完全解决的微信收费风波,不过是这种矛盾浮上水面的冰山一角.本文正是往冰山的水下部分探了一眼.张小龙在今年曾想干这么一件软硬件结合的事:定制一批微信专用无线路由器.这种路由器可以把带宽分为私用公用各一半,