4.1 需求采集方法的分类

4.1　需求采集方法的分类

产品概念通过筛选之后，就要投入更多资源推进这个产品了。在开始设计功能之前，先要尽可能多地收集信息，即采集需求。采集需求只是手段，其目的是通过研究用户来更好地满足需求。接下来先从多个维度给需求采集的方法分类，看看各自的优劣，以便灵活应用。

4.1.1 　直接采集与间接采集

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

►第一个角度： 需求的提出者是不是有需求的人。如果用户是为自己提需求，采集到的就是一手需求；如果这个需求是转述的，就是二手需求。举个例子，比如说某一位销售见过一个客户，没有成单，然后他把阻碍成交的问题转化成一个需求提给产品经理，我们收到的就是一个二手需求。

►第二个角度： 需求是原始的还是加工过的。比如直接跟用户聊，采集到的就是一手需求，而去看第三方机构做的一些行业分析报告，采集到的就是加工过的二手需求。给大家提个小的注意点：看报告时一定要关注它是出自哪个机构之手，甚至要查阅这个机构的股东结构，看看有没有可能存在影响报告客观公正性的投资方或关联企业。

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

直接采集的一手需求更准确，所以产品经理一定要确保手里有足够比例的需求是来自直接采集的，这样才能让产品本身和自己对产品的判断更接地气。而间接采集的二手需求，就需要带着问号来看，思考其需求者和提出者分别是谁，以及有没有被曲解过。但，二手需求（比如一份客户反馈周报）是经过梳理的，所以获取结论的效率更高。在工作中并不是说只用其中一种就可以了，而是要视需求不同灵活选用。

实践层面，“全员参与采集，产品经理处理 ”是比较可行的模式。

既然有二手需求，就意味着公司里面除了产品经理，还有其他岗位也在做需求采集的工作。产品和其他岗位怎么分工呢？有一个做法供大家参考，我也在公司里面推行过——采集阶段可以全员一起上，一般不会有太大问题，甚至每个采集者可以做一些简单的需求归类、合并工作，也可以对满足需求的方案提出自己的建议。但是针对具体需求的最终方案，还是由产品经理说了算，千万不要让非专业人士告诉产品经理应该做哪些功能。否则，既有可能使产品方向跑偏，也有可能掺杂部门利益。

4.1.2 　说和做，定性与定量

接下来，从另一维度来对需求进行分类。可以用如图4-1所示的两个关键轴把所有需求采集方法分成四类：说、做、定性、定量。

纵向是说和做。

怎么说表达了观点，怎么做反映了行为，用户怎么说和怎么做经常是不一致的。“说”最大的劣势是“耳听为虚”，怎么解决耳听为虚呢？看他怎么做。“做”的优势就是“眼见为实”，但也有劣势：我们不知道用户为什么这么做，背后的原因是什么，也就意味着没法从根本上解决问题。于是，需要再去听他如何说。所以说和做是一对不可分拆的方法，尽量同时用于一次需求采集，否则可能会出问题。

横向是定性与定量。

定性研究可以找出原因，偏向于了解，属于个体研究；而定量研究可以发现现象，偏向于证实，属于群体研究。定性的问题是“以偏概全”。如果你的产品有几百万用户，而定性研究经常只针对几十个用户，那么这几十人是否能代表全体？这种情况下很可能被部分样本的特殊情况带入歧途，所以要辅以定量的方法。但是定量会“以表代本”，只能用来发现表面的现象，却无法从中知道背后的原因。比如，通过定性的数据发现7月份用户活跃度比6月份降了5个百分点，那么，就可以抽取几个6月活跃但7月不活跃的用户，做一个定性的访谈，来搞清楚到底发生了什么。

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

图4-1中两根轴划分出的四个象限，各对应一种常见的需求采集方法，分别为用户访谈、调查问卷、可用性测试 [1] 、数据分析 ，《人人都是产品经理》里有过详述。 沿着这些方法的使用顺序可以写出一个“Z”字，如图4-2所示。在需求采集的不同时期，可以有针对性地分别采用不同方法。这套简单有效组合拳，就是接下来要用案例加以说明的“Z字采集法”。

下面是一个我参与过的淘宝产品的完整需求采集过程。

►产品规划阶段： 听用户“定性地说”，确定产品方向（做什么）；随机抽样了40个用户做访谈，据此写出需求列表。

►项目早期： 听用户“定量地说”，确定需求优先级（先做什么）；投放了20万份调查问卷，确定了需求优先级的排序。当然，这只是确定优先级的辅助手段，最终做什么，还是由产品经理决定。

►项目实施过程： 看用户“定性地做”，确定要先实现的那几个需求应该怎么做；设计的同时完成可用性测试，其间陆续找了10个用户来验证。

►上线后的优化阶段： 看用户“定量地做”，根据产品的用户使用情况做数据分析，不断地改进产品。

“Z字采集法”也有一个螺旋上升的循环，数据分析以后，通常又会做用户访谈来证实数据分析的假设。

当然，这是一个比较重要的产品，所以在用户研究上投入了较多的时间与人力。更多的时候，会视情况采取简化的方案。而每种方法具体怎么运用，网上资料很多，本书不再赘述。

接下来看一些其他划分方法。

4.1.3 　是否在真实场景里

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

出于性价比的考虑，有一些采集是在模拟状态下完成，比如很多大公司都有专门用于用户研究的房间，提供单面玻璃、观察室等配置。但如果在用户需求发生的真实场景里进行采集，那么可靠性肯定更高。比如，平时用户在家里用产品，采集也发生在他家里，会更加可靠。当然，这种情况下，记录难度会增加。既然各有利弊，如果不是为了积累素材、给别的同事看或者节省时间，我个人还是倾向于在真实场景里采集，因为这样更具“临场感”。

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

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

找人访谈、试用后，发现了不少问题。首先，每次提醒之后都需要重置浮标的状态，而钓鱼的时候，人们要经常搓饵料，手上黏黏的，根本没法操作手机。更要命的是，很多人钓鱼就是为了要远离手机放空自己……

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

还有一个例子：针对Shopping Mall车位紧张时20分钟才能找到车位的常见困扰，有人想做一个帮忙找车位的App。问题在于，这个App的“唤起点”是到地库后发现空车位很少的时候。而这时掏出手机，多半会 “没信号”。所以，在地库的信号覆盖没能解决之前，这个产品只能面对一条死胡同。

还是这个App，假设用户快到Shopping Mall地库的时候就提前想到车位可能很紧张，似乎先付钱锁定车位（假设锁定的是立体车位，可以悬在空中预留）就能解决信号覆盖问题。其实不然， Mall的车库入口一般是公用的，必须等里面空出一个车位，才能再进一辆，你虽然订了车位，也只能排队干等。

这两个看上去很荒诞的场景，如果不去设身处地地体会，在办公室里很可能想不到。

再来一个糗事百科CEO王坚分享过的案例。我们都知道，MacBook有MagSafe磁力电源线[2] ，可以防碰防摔，日本生产的一些电水壶也有这种线。后来，联想有一款手机也借鉴了同样的设计，却出问题了：手机经常一边充电一边用，一不小心线就掉了，给用户带来很大困扰。仔细想想，之所以这样的设计并不适合手机这类产品，是因为适合用磁力电源线的产品，需要在充电或通电的场景下，安安静静地放在固定位置上。

作为一个具备很多专业知识的产品经理，只有能做到秒变小白，回滚到自己完全不了解产品的心理状态，亲自去体会临场感，才能避免做出很多坑用户的产品。而最好的体会临场感的方式，就是到用户发生需求的场景里去。这也是为什么产品经理不能只听“二手需求”，因为那些需求是别人总结过的，已经没有了临场感。真实的用户不是“用户群体”，而是一个个活生生的个体。

4.1.4 　是否和产品发生交互

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

有些需求的采集只是跟用户聊一聊，用户并没有开始接触这个产品，更没有真正用过这个产品。这种需求采集可能更多的是在“发现新问题”。还有一种采集方法是在用户跟产品发生交互的状态下进行采集，往往用于“优化现有方案”。所以，不一样的阶段，需要使用不同的需求采集方法。

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

电视机需求 vs 洗碗机需求。

电视机：装修好新家，大多数人都觉得应该有个电视，这是必需品，所以一定会买来放在客厅或卧室里，但之后可能一个月才开一次，几乎不用。

洗碗机：在国内因为大家都不觉得这是必需品，所以很少有人买。但如果不小心买了，用过之后发现洗得确实挺干净，每周能因此省下不少时间，就“根本停不下来”。

之所以选择这两种产品，是因为它们对应的需求，可以分别用来定义两种很典型的产品功能。

电视机需求：用户以为自己要，但有了并不用的产品功能。

洗碗机需求：用户以为自己不需要，但用过就离不开的产品功能。

举几个例子。

►不少公司在规模很小的时候，就觉得需要制定一些规则来规范化管理。制定好以后，十有八九都没有很好地执行，规则成了摆设。这类无法执行的规则，只会削弱管理者的公信力，还不如没有，是典型的电视机需求。

►很多App里，都有些功能，听了所谓的用户需求后做出来，但在数据上看根本没人用，这些功能都属于电视机需求。

►2016年有个App叫“得到”，颠覆了我们对阅读的认识。在绝大多数人最初的认识中，一本书怎么能通过听几十分钟的音频、看几千字就算读过了呢？要看就得看原书，而且要完整读完。但试过得到以后，很多人都觉得这是一种不错的办法，对于扩展非核心知识面很有效。这就是典型的洗碗机需求。

无论是电视机需求还是洗碗机需求，似乎都基于一个潜在原因：用户不靠谱。那么，究竟该如何应对这种不靠谱，或者说如何在这种不靠谱的现状下实现用户和产品的双赢？

办法很简单，采用低成本验证。具体做法就是，先不上复杂的系统，设法简化实现，或者干脆用人肉跑流程来验证。同时，多让用户低成本体验产品，比如试用、租用。

常见的做法是“免费试吃”，我们来举几个例子。

►产品经理觉得用户肯定会喜欢，但毕竟用户没吃过。先在超市里摆放一个小号的试吃装，用户对从来没尝过的免费零食饮料往往毫无抵抗力，尝了一下后觉得“哎哟不错哦”，就买了。

►企业在考虑是否需要一个收费的协同管理系统时会很纠结。如果系统提供商适时推出30天免费试用版，就可以大大降低客户尝试的心理门槛。

►对用户而言，下载并体验一个新的App产品成本实在太高了。完全可以将一些基础的核心功能做成H5页面，让用户不用下载就能试用。

综上所述，在需求采集时，不但要和用户海阔天空地聊，还得创造机会让用户和产品交互一下。因为用户的想法，往往有些滞后，有些惯性，以为自己一定需要一个大家都在用的东西，以为自己一定不需要一个还很少有人用的东西。所以，就算没有产品，也可以想办法看看用户会如何与类似的产品互动，从而加深对需求的理解，真正达到用户价值与商业价值的双赢。