00's Adventure

产品经理的用研手册03 - 成也需求,败也需求

如果你根本不知道自己在讨论什么,那么对其强求精确是毫无意义的。 —— 冯·诺依曼

我们用「产品」这个词来表示那些试图满足一系列复合期望的产物。复合意味着它们来自许多人。找到谁是这些「人」,是明确需求的一个主要部分。上一篇,00 分享了一些如何分类和描述用户的经验:

接下来,我们将要走进需求的沼泽,深入产品开发险恶的腹地,看看需求这个妖孽如何把众多产品经理拖入泥潭之中。

需求很关键,可现实往往是,人们不知道自己想要什么;而且,产品经理不知道人们想要什么;雪上加霜的是,产品经理不知道人们不知道他们想要什么……产品开发再高效也好,都是一种浪费。认真探索需求,我们才不会做出然并卵的产品。

关于万恶的需求,有两个最最关键的问题:

能清楚回答第一个问题,是合格的产品经理,能正确回答第二个问题,才是好的产品经理。

需求是什么

从前,有一只狡猾的妖孽,叫做「需求」。

它长着一张模糊的脸,而且是一张会千变万化的脸,最善于迷惑那些苦苦寻找它的人。不同的人看到这个妖孽,描述出来的样貌都不一样,似乎从来没有人能识别它的真面目 —— 还是说,它就没有真面目?(摊手)

区分需求和解决方案

人们之所以经常被需求妖孽所迷惑,还因为他/她/它经常跟另外一个妖孽「解决方案」互换躯壳,所以懵圈的人们经常追着「解决方案」喊「需求」。为了早日让需求妖孽现身,我们需要练就一双区分它俩的废眼,哦不,慧眼。

举个栗子

在编辑模块中,用户需要一个预览页面

在抓需求妖孽的时候,一不留神,我们会在急忙之中抓过来一只解决方案妖孽,睁眼瞎地指着它说:呔!这就是需求,快给我拿下~ 这个例子中,预览页面就是被误捉的解决方案妖孽,而需求妖孽还在附近不知道哪个角落悠闲地游荡着。

捉错妖孽,会给我们制造很多麻烦:

  • 误解实际的需求
  • 带着过多假设和预判去思考
  • 错过更佳的解决方案

在这里,00 介绍一个识别两只妖孽的简便方法。

需求妖孽往往这样长着这样的嘴脸:

我想【达到什么目的】

需求一般应该带有更多关于状态、行为、态度的描述。

解决方案则往往可以这样描述:

我要【有什么特点的东西】

它已经开始描述对象是什么样子。

来来来,下面进入栗子时间。我们活捉一只妖孽,听听它说了些什么。

我想要一个循环播放的按钮

嗯哼?

开始描述对象了。这厮是解决方案妖孽!

别着急把它推开,每当我们发现又捉错了妖孽时,不妨对它进行逼问,它会老实告诉你需求妖孽的藏身之处。逼问的方法很简单,只有三个字 ——「为什么」:

S 妖:我想要一个循环播放的按钮

你:为什么?

S 妖:我想循环播放歌曲

你:为什么?

S 妖:我想连续播放喜欢的歌曲

你:为什么?

S 妖:你是复读机么?…… 我想在睡前连续播放喜欢的歌曲

你:为什么?

W 妖:妈呀救命这是复读机妖……我希望在不能/不想人为操作重复播放时,我喜欢的歌曲能够连续播放

逼问过程中,需求妖孽自动现形了!这就是歪歪歪复读机大法。

在更具体的需求描述中,类似场景信息如「睡前」、体验预期如「不想人为操作」、隐含需求「播放喜欢的歌曲」等,都会浮现,这对具体的方案设计提供了更多决策信息。

更多关于用户需求的挖掘和分析,请留意本系列后续的文章。

区分用户需求和业务需求

好了,需求妖孽总算抓到了。

不过这厮可不是省油的灯,一不留神,它又使出分身术,变成两个妖孽:一个叫用户需求妖,一个叫业务需求妖。用人间的话来说,用户需求是「用户想要什么」,业务需求是「我们应该怎么做」。

难道用户想要的不就是我们应该做的吗?是,也不是。

用户想要的是结果,我们应该做的是保证得到这个结果的所有环节,包括用户看到的每一个界面、从他们那里得到的输入数据、帐户生成和标识、数据存储和传输、计算、请求、加密等等等等,全部都是业务需求。

业务需要达到一定的使用量、访问量、购买量、转化率,这些需求都跟用户需求有关,但实际要做的远不止用户所表述的需求。用户并不需要注册,但是业务需要获取和保存用户信息;用户不需要统计上报自己的数据,但是业务需要数据辅助分析和决策,等等。

你的团队,如何处理业务需求和用户需求的关系?

需求值不值得做

需求捉妖过程对产品经理来说,已经足够有挑战了,但真正的好(da)戏(keng)还在后面。

产品开发的资源永远有限,哪些该做?哪些该先做?

关于值得不值得的问题,实质是 ROI (投入产出比)的问题。如果能算清「用多大成本实现了多大价值」这笔账,做出合理的判断应该不难。

困难的是,这笔账似乎永远都是一笔糊涂账。

我们来尝试理理思路。

帮助用户实现价值,业务和产品就有价值,从而获得收益。假设这个推论成立,那么问题可以描述成:哪些需求可以放大用户价值?想一想平时我们离不开的产品,它们带来了哪些价值,为什么离不开?00 总结了一个判断用户价值的简易公式:

需求强度

人们有多需要一个东西,由两个问题决定:

  • 有多痛/痒?
  • 有多稀缺?

痛痒的问题,其实就是我们常说的是否「刚需」。但是刚需也因人而异,比如说,VPN 对我来说是刚需,对我妈则不是。那么怎么可以更好判断出痛点/痒点呢?

一个角度,是从使用者自身出发,分析这个需求的四个特性:

  • 价值:比如,多大程度上帮我省钱省时间,实现人生目标
  • 预期:比如,买个旅行机票,帮我把签证都办了
  • 可陈述程度:比如,美颜只是显性的,万人迷是隐性的
  • 已满足程度:这个就不用距离了

另外一个角度,则是从外部同类产品的比较来看,著名的 Kano 模型:

根据满意程度和重要程度划分功能需求:

  • 及格线:大家都有的你没有,就会被骂辣鸡
  • 备胎线:恰好达到行业平均水平,也只是个可以当备胎的良民
  • 粉丝线:人无我优,远超期望,用户一接触就会内心惊呼「卧槽」,然后路转粉,粉转脑残粉

以上是痛/痒问题。稀缺问题则比较好理解。市场上有哪些同类或类似的解决方案?你的产品有多独特?用户通过什么渠道接触到?这些渠道你有多大的份额、影响力、把控能力?物以稀为贵,稀少的东西,总是能加强痛点和痒点。

使用频率

判断出需求强度以后,还需要考虑使用频率。典型的例子是旅行市场,需求巨大,但就是频率太低,活跃度和留存率都不好做。考虑使用频率,可以从用户比例和场景频率两个维度出发。

  • 多大比例用户想要?
  • 需求场景的频率如何?

这两个问题虽然很难得到准确的数据,但是仍然要想办法估算。上一篇文章介绍的用户快照这个时候就能够派上用场。

  • 如果与实现用户的行为目标强相关,使用频率应该较高。比如,电商平台的购物车功能
  • 如果最重要的用户类型需要它,使用频率相对较高。比如,某直播平台最重要的用户类型是游戏玩家,那么主播的游戏等级可能就变得重要
  • 典型场景的客观发生频率较高,使用频率应该较高。比如,用来 p 朋友圈图片的工具
  • 典型场景在用户生活中地位重要,使用频率相对较高。比如,每天上下班要在地铁里呆上两小时,看书听歌看视频的频率就会更高。

花了这么长的篇幅分析了如何判断用户价值,这只是 ROI 的 R (Return)部分,至于 I (Investment)的分析又是另一门学问。毕竟这个系列写的是用研手册,产品经理专职范畴内的难题,就不继续展开了。

警惕伪需求

需求妖孽之所以是妖孽,不但因为行踪诡秘,而且容易被冒名顶替。伪需求们是资源的黑洞,怎么填都填不满。如何识别伪需求呢?它们一般会以这些面目出现:

伪装成解决方案。这个上文已经仔细分析过。

伪装成常见场景。作为果粉 + watch 黑,00 一直觉得 Apple Watch 把边缘场景成功伪装成常见场景。在一个手机不离身的时代,手表真正能替代手机的场景有多少呢?

伪装成大部分人的需求,实际上只是枝节需求。如果不清楚自己产品的用户类型,不清楚哪类用户是最重要的,这种伪装就容易蒙混过关。比如当年已经做出来但没有最终上线的微信朋友圈滤镜功能。滤镜多好啊,大家都需要,Instagram 是成功案例,新浪微博有,QQ 空间也有,为什么不做呢?微信一定能做出强大好用的滤镜,但是,微信为什么要提供一款滤镜功能呢?大家发朋友圈的动机到底是什么呢?如果没有好友关系的沉淀,丰富有趣的互动方式和氛围,就算在微信里面再造一个 Instagram 又有什么意义呢?

伪装成可以脱离商业模式而存在。这是最可怕的伪装。没人不喜欢 Kano 模型中远超预期的功能,但是这些功能为什么往往大家都没有提供?原因多半是:不经济,不可持续。

关于折磨人的需求,就讨论到这里。

下一篇我们介绍用户研究主要能解答什么类型的问题。


如需转载本文,请联系 uegeek@gmail.com

kidult00 wechat
扫码关注 00 的公众号
支持原创,五毛钱不嫌少~