多维度了解需求采集方法的利弊

1. 直接采集与间接采集

直接采集与间接采集，获取到的需求分别是一手需求与二手需求，直接采集需要直接和用户互动，你可以从以下两个角度来理解它们的差异。

第一个角度：需求的提出者是不是有需求的人。

如果这个需求是用户为自己提出的，那么采集到的这个需求就是一手需求；如果这个需求是由他人转述的，那么这个需求就是二手需求。

举个例子吧，比如说某一位销售见了一位客户，但最终没有成单，然后他把阻碍成交的问题转化成一个需求提给产品经理，这时候产品经理收到的就是一个二手需求。

第二个角度：需求是原始的还是加工过的。

比如你直接跟用户聊，采集到的就是一手需求，而去看第三方机构做的一些行业分析报告，采集到的需求，就是加工过的二手需求。

给你提个小的注意点：看报告时一定要关注它是出自哪个机构之手，甚至要查阅这个机构的股东结构，看看有没有可能存在影响其出具报告客观公正性的投资方或关联企业。

对于这两种采集方式的优劣，我们可以从准确与效率两方面加以对比。

直接采集的一手需求更准确，所以产品经理一定要确保手里有足够比例的需求是直接采集的，这样才能让产品本身和自己对产品的判断更接地气。

而间接采集的二手需求，就需要带着“问号”来看，思考原始需求方和转述者分别是谁，以及它有没有被曲解过。但二手需求（比如一份客户反馈周报）可以通过更多的人，收集到更多的用户声音，而且是经过梳理的，所以获取信息的效率更高。

扩展到实践层面，团队内“全员参与采集，产品人员处理”是比较可行的模式，是一种效率和准确度的兼顾方案。

2. 说和做

用户“怎么说”表达了他的观点，“怎么做”则反映了他的行为，这两种需求采集方式也是各有利弊。

“说”最大的劣势是“耳听为虚”。

Sony 发生过一个有趣的故事，曾经他们新推出一个新款游戏机，邀请用户来访谈，其中有一个问题是“两种外观设计，你更喜欢黄色还是黑色”，大多数用户说黄色，访谈结束的时候，Sony 跟用户说，感谢你的时间，可以拿走一台游戏机作为纪念，结果发现大多数用户都拿了黑色。

所以，用户怎么说和怎么做经常是不一致的。

那么怎么解决耳听为虚呢？就是看他“怎么做”，像 Sony 那样让“说”和“做”同时发生当然是个好办法，只是成本不低。

“做”的优势，就是“眼见为实”，但它也有劣势——那就是，我们不知道用户为什么这么做，背后的原因是什么。这也就意味着，我们只靠用户“怎么做”的结论是没法从根本上解决问题的。于是，还是需要回过头再去听他怎么说。

对于处理用户“怎么说”的信息方面，我还有个技巧，那就是注意区分用户说的“观点”和“事实”。用户一般不会故意扭曲事实，但他的个人观点就要带着“问号”听了，你要习惯性地追问支撑用户这个观点背后的事实。

所以，“说”和“做”是一对不可分拆的方法、可以互相补位。

3. 定性与定量

定性研究通常是对少量样本的深入研究，可以找出问题的原因，属于个体研究；

定量研究是对大量样本的研究，可以发现现象、验证事实，属于群体研究。

定性研究可能会存在的问题是“以偏概全”。所以我们要辅以定量的方法。

定量会“以表代本”（表面的表，本质的本），只能用来发现表面的现象，却无法从中知道背后的深层次原因。

比如，你通过定量的数据发现 11 月份用户活跃度比 10 月份降了 5 个百分点，那么，就可以抽取几个 10 月活跃但 11 月不活跃的用户，做一个定性的访谈，来搞清楚到底发生了什么。

需求采集理解用户的过程，并不违背人类认知新事物的一般规律——从观点到行为，再从行为到观点，一样会从定性到定量，再从定量到定性，以实现螺旋式上升，使了解和证实在不断迭代中得到进化。

4. 是否在真实场景里

采集是否发生在真实的需求场景里，也是一种分类方法。

发生在真实场景里的采集，优势显然是更真实可靠。

举个例子，平时用户在家里用产品，采集也发生在他家里，会更加可靠。当然，这种情况下，记录难度会增加。而出于性价比和效率的考虑，有一些采集是在模拟状态下完成的。

因为假的场景里，可以更方便地录音、录像、录屏等，也可以更方便地给别的同事或利益相关方观察，以促进共识的达成。比如，很多大公司都有专门用于用户研究的房间，提供单面玻璃、观察室等配套设施。

当然，有条件的话，我个人还是倾向于优先在真实场景里采集需求，因为这样更具“临场感”。

能够拥有“临场感”是产品经理的一项基本能力。因为需求本身通常都是带着特定场景的，只有到那时那刻去亲身体会（或者通过想象去体会），才知道你的设计是不是有问题。而对这种体会的准确把握，就是“临场感”。

之前我听过一个面向钓鱼爱好者的产品——“智能鱼漂”。这款产品可以通过 APP 观察鱼漂的状态，提醒钓鱼者有没有鱼上钩。打算推出这款产品的公司认为这样对钓鱼新手的帮助很大。

但经过临场观察之后，就发现了不少原先的设计问题。

首先，每次提醒之后都需要重置鱼漂的状态，而钓鱼的时候，人们要经常搓饵料，手上黏黏的，根本不方便操作手机。更要命的是，很多人钓鱼本来就是为了要远离手机、放空自己才去钓鱼的。

钓鱼的人给了些建议，说用振动提醒如果和智能手环相结合，可能会好些。作为产品经理，最好去钓几次鱼，或者多看几次钓鱼，才能找到这个临场感。

5. 是否和产品发生交互

最后一个维度的分类方法，是看需求采集过程中，用户是否和产品发生交互。

有些需求的采集只是跟用户聊一聊，用户在现场并没有接触这个产品。这种需求采集可能更多的是在“发现新问题、探索新方向”。

还有一种采集方法是在用户跟产品发生交互的状态下进行采集，往往更适用于“优化现有方案”，当然，如果你没有产品的时候，也可以让用户和竞品发生交互。

所以，不一样的阶段、不同的目的，需要使用不同的需求采集方法，通常是先探索方向，再优化方案。

对于很多产品，用户想象中的自己是否需要，和真的用过以后的自己是否需要，是完全不同的。而这正需要通过产品交互来发现，下面是我给两种很典型需求的隐喻。

需求采集是一个螺旋上升的过程，各种方法要反复交替使用

KANO

KANO 模型的工具对产品功能进行分类和优先排序。

KANO 模型的应用

今天要说的 KANO 模型，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的关系。

这样的 KANO 原始模型图不止可以用在产品创新上，在团队管理上也有应用，其实，你如果去深入了解，会发现 KANO 模型的缘起叫双因素理论，最经典的应用就是工资是保底，奖金是激励。

举个例子，你会发现，有一些非常基础的功能，比如一个网站的登录模块，包括忘记密码的找回功能什么的，是非做不可的。这些功能其实没那么高频，性价比也不会很高，可我们为什么必须做呢？要想正确看待和理解这个矛盾，KANO 模型正好能为你解惑。

再啰嗦一句，由于 KANO 模型并不是专门针对产品创新而设计的，所以这一讲里的一些内容，是我在原始模型的基础上做过优化的。

1. 基础功能

当这类功能没有实现时，用户对产品是“极其不满”的。但是，即使这个功能做得再好，用户也认为是“理所应当”。

怎么判断一个功能是不是基础功能呢？这主要靠产品人的领域知识了。

如果你的领域知识不够，无法做出正确判断，还可以通过问用户两个经典问题来补救：

如果产品没有功能 A，你觉得如何？请从很满意、一般满意、无所谓、不太满意、很不满意（或 5、4、3、2、1）这五个评价选项中选出一个来作答。

如果产品有了功能 A，你觉得如何？同上给出相应的答案。

然后，在 KANO 模型图中为以上两个答案对应的坐标点之间做个连线，就能看出这一功能所属的类型了。这个方法对接下来要讲的几类功能同样适用。

2. 亮点功能

当这个功能没有做时，用户并不会不满意或觉得有问题，因为已经“习以为常”。但是一旦有了这个功能，用户就会大为惊喜，甚至“赞不绝口”。为什么会这样？主要因为这些功能通常是新的，用户事先想不到产品居然还能有如此妙用。

比如，若干年前，有谁会想到，手机能当手电筒用，浏览器能通过记忆和联想自动补全你刚开始输入的网址，已发送出去的电子邮件还可以因内容不妥在几秒内撤回……

这类功能有一个共同的名字，叫做“亮点”，对应的英文说法是 Excited To Have。

亮点是忠诚度、口碑传播的基础。

如今，一个没有亮点的产品，用户也许偶尔会用，但不会与产品建立正向情感连接，更不会主动帮我们传播。想要低成本引流，让老用户带来新用户，产品必须找到自己的亮点。

那么应该做什么样的亮点呢？

常见的亮点特性有“用户没见过”“未经市场检验”和“如果被认可就能获得巨大回报”这几种。由此可知，选择亮点不能一概而论，大公司和小公司，已经很厉害的产品和新生的产品，都会做出截然不同的判断。

小公司和早期产品，应该优选成本低的亮点，仅将其作为锦上添花。

比如很多网站有趣的 404 页面、很多 APP 里用心的交互小细节。因为一个潜在的亮点在投放市场之前，并不知道它会不会真的变成亮点。如果投入太大成本去做这样的亮点，对小公司来说往往等于孤注一掷，一旦用户不买账，公司基本就完蛋了。

大公司或很厉害的产品来说，情况则完全不同。

由于大公司在市场竞争中处于领先地位、资源充足，完全可以不用那么在乎成本，做一些可以让自己保持领先地位的亮点，以寻求更大突破。

况且，大公司还可以通过大量市场调研和技术预研，在功能推向市场之前就基本确定它是一个亮点，然后再投入大量资源重点研发，把这个亮点打造成领跑市场的杀手锏。

比如华为手机这两年不断引领的拍照能力，像暗光、高倍变焦，就是一个比较典型的例子。这种级别的功能，一定需要投入大量市场、研发的资源，但因为能事先确定必会成为大趋势，先做出来就能引领潮流，而且公司和产品的状态也足以支撑这样的突破，自然不会放过这样的亮点。

怎么做出亮点？这就主要靠对用户人性和心智的理解，因为亮点是用户想不到、说不出的，要求你必须能领先一步，深刻洞察。

3. 期望功能

它的曲线比较平直，这类功能叫作期望功能，对应的英文说法是 Nice To Have。

这类功能，少了用户有点不爽，但还不是无法接受；多了用户会觉得不错，但也不是欣喜若狂，对产品而言往往是“多多益善”。这类的产品功能选择起来也比较简单——先做性价比高的。

之所以取“期望功能”这个名字，是因为这类功能都是用户的期望。比如，你要做一款创新的智能手环，去问用户有什么需求，用户的答案可能是：

“最好操作简单一些”

“充电不用太频繁，希望充一次至少用一个礼拜”

“样子要酷一点”……

这种大多数用户能说得出来的，就是期望功能。

产品具备了期望功能，用户当然会继续使用，但因为缺乏惊喜而不大可能去主动传播。如果只是通过简单地和用户交流来采集需求，最终实现的大多只能是期望功能，这再一次印证了我们之前提到的 Y 模型中的一个原则：“用心听，但不要照着做”。

KANO 模型从另外一个角度告诉我们，如果只是从“1”到“3”，照着用户说的做，这个产品的功能往往是不完整的。因为用户能告诉你的，只会是期望功能。

用户不会提基础功能，因为他觉得你的产品肯定会有；用户也不会说亮点功能，因为他想不到。

由此可见，做产品是不能抄近道的，必须从“1”往下挖，挖到“2”后用领域知识来补全基础功能，再挖到“4”，这时要通过对人性和心智的理解来提出亮点。

前三类功能的时间演变

我们刚刚讲的前三类功能，还只是在一个时间点上去分析。现在，我们再加入时间维度。

我先说结论，随着时间的推移，一个功能的类型是会变化的，往往会经历从亮点功能到期望功能再到基础功能这样一个完整变迁。

预测未来很难，但可以通过追溯过往来找到适合你的例子。

2000 年左右，有少数手机已经可以用来听歌，彻底颠覆了单独使用 MP3 的用户习惯，所以“可以听歌”明显是个亮点。一、两年后，越来越多的用户意识到手机能听歌的好处，会在参与需求调研时提出“希望你们的下一款手机也可以听歌”，这时“可以听歌”又变成了典型的期望功能。再过去几年，当所有手机都能听歌了，用户就再也不会主动提这个功能，“可以听歌”变成了理所当然的基础功能。

有些新功能因为一直没能成为亮点，最终淡出了历史舞台，而有些基础功能也有可能被新技术替代，慢慢不再被用户需要，这都是时间的力量。现在看一下自己手机里的短信，会发现短信收发这个功能，已经彻底沦落为只用来接收验证码和垃圾广告了吧？几乎所有的短信，收发的对方都是机器，很少是真人，所以已经渐渐变得无足轻重，也许再过若干年，它会完全消失。

时间的推移，也是一个市场逐渐成熟、由俭入奢的过程，越来越多的功能成为基础功能，行业门槛也就随之提升。因此，基础功能常用来满足旧有的存量市场，而亮点功能则更有可能创造一个全新的增量市场。随着市场竞争的日益充分，企业要想胜出，必须不断创新，对市场进行有效细分，以快速找到自己产品的亮点。

4. 无差别功能

接下来，再说第四类功能。它和横轴重叠，做不做，用户对产品的感受是没有变化的。

可能你会觉得奇怪，怎么会有这样的功能呢？举个例子，某产品的某个二级菜单，从后台观察数据，从来没有人点击，这就是无差别功能。

这样的功能怎么应对？当然是不要做。

那么问题来了，如果不做，怎么知道它是无差别功能？所以，我们之前讲过的低成本验证就能派上用场了，我们至少有七种做原型的方法，不是吗？其实，对任何类型的功能，准备做取舍时，我都极力推荐低成本验证的方法。

5. 反向功能

在 KANO 模型图中的线条呈现为一条单调递减的直线，你可看到这条线的两个坐标点位置。

线条代表的含义是做得越多用户越讨厌，这类功能叫做反向功能。

听起来是不是很奇怪？既然用户讨厌，不做这种功能不就好了？可是问题没有这么简单。

比如百度的广告，对普通搜索用户来说，搜索结果页里广告越多，满意度就越差，但对投放广告的用户，肯定希望搜索结果中也里有自己的广告。

这是因为，KANO 模型里的纵轴叫用户满意度，而一个产品的用户是多种多样的，不同用户的目标也各不相同，所以这里的“满意”，针对某一种用户可能是反向的，而针对另外一种用户却可能是正向的。

一个 KANO 模型，往往只针对一种用户，通常是核心用户。实际上，也可以针对不同的用户画出多个 KANO 模型。一般情况下，因为必要性不大，实操中很少有人这么做。

反向功能非常考验做产品的人，我们需要在多种用户利益之间寻找平衡，这门课里提过的用户生态图，就是方便我们理解这件事的。

痛点：基础功能，没有的时候不可忍受；

爽点：亮点功能，有了以后惊喜连连；

痒点：期望功能，可有可无能有最好。

• 基础功能：留足资源；

• 亮点功能：做成本低的（对更多创新产品而言）；

• 期望功能：看性价比；

• 无差别功能：做好低成本验证；

• 反向功能：权衡多方利益。