产品经理的入门心法03 - 成也需求，败也需求

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

回顾：
产品经理的入门心法01 - 朦胧的用户，懵懂的你
产品经理的入门心法02 - 如何描述用户

我们用「产品」这个词来表示那些试图满足一系列复合期望的产物。复合意味着它来自许多人。找到谁是这些「人」，是明确需求的一个主要部分。上一篇，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 模型中远超预期的功能，但是这些功能为什么往往大家都没有提供？原因多半是：不经济，不可持续。

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

下一篇，我们介绍产品经理面对的问题类型。

（原文首发于 00 的公众二号「你丫全栈」，现已改名「ArtxCode」）