|
|
# 15 | 需求采集：各种方法怎么灵活应用
|
|
|
|
|
|
你好，我是苏杰。
|
|
|
|
|
|
从今天开始，我们进入番外篇，这几篇内容，都不单属于四轮MVP的某一轮。它们是随着课程的进展，根据和留言互动才新鲜确定的主题内容。番外篇的第一篇，让我们一起了解需求采集的各种分类，通过这个分类，以后再选取某种需求采集方法的时候，就可以知道是否适用了。
|
|
|
|
|
|
可能有人会觉得，需求采集不算Paperwork么？没错，是一种Paperwork，但我想强调的是，产品创新的全程都需要需求采集，并不是在第一轮MVP阶段做完了就结束了。
|
|
|
|
|
|
一切产品创新，如果有一个抽象模型，那无非是输入信息、运算处理、输出产品。所以，高质量的输入，也就是需求采集，是一切好结果的前提，它的重要性可见一斑。
|
|
|
|
|
|
因为需求采集失误而导致的灾难不胜枚举。
|
|
|
|
|
|
比如你让用户试用了新产品之后，问他，你将来会购买、会使用么？用户往往会因为没必要和你发生冲突，而敷衍的回答，可能会买，应该会用。这样的答案，其实毫无意义，甚至会让我们过于乐观。
|
|
|
|
|
|
再比如，我们通过销售人员的反馈，采集到的需求，很可能夹杂了销售人员的利益诉求，只关注是否有利于拿下订单，而不考虑后期的使用、维护成本。
|
|
|
|
|
|
这些错误的避免，以及每一种具体的需求采集方法怎么操作，有哪些注意事项，业内已经已经有很多资料可以查阅，在一篇文章里给你穷举方法没有什么实际意义。
|
|
|
|
|
|
## 多维度了解需求采集方法的利弊
|
|
|
|
|
|
我想要说的是一个更重要，而且经常被忽视的命题，就是每一种需求采集方法，都各有利弊，各有适用场景，在什么情况下，选对正确的具体方法，这是实施操作的前置条件。这一讲，我会在这个层面上来和你聊聊。
|
|
|
|
|
|
目前，对于需求采集这件事，我是用了五个维度来进行分类的。
|
|
|
|
|
|
### 1.直接采集与间接采集
|
|
|
|
|
|
直接采集与间接采集，获取到的需求分别是一手需求与二手需求，直接采集需要直接和用户互动，你可以从以下两个角度来理解它们的差异。
|
|
|
|
|
|
第一个角度：**需求的提出者是不是有需求的人**。
|
|
|
|
|
|
如果这个需求是用户为自己提出的，那么采集到的这个需求就是一手需求；如果这个需求是由他人转述的，那么这个需求就是二手需求。举个例子吧，比如说某一位销售见了一位客户，但最终没有成单，然后他把阻碍成交的问题转化成一个需求提给产品经理，这时候产品经理收到的就是一个二手需求。
|
|
|
|
|
|
第二个角度：**需求是原始的还是加工过的**。
|
|
|
|
|
|
比如你直接跟用户聊，采集到的就是一手需求，而去看第三方机构做的一些行业分析报告，采集到的需求，就是加工过的二手需求。
|
|
|
|
|
|
给你提个小的注意点：看报告时一定要关注它是出自哪个机构之手，甚至要查阅这个机构的股东结构，看看有没有可能存在影响其出具报告客观公正性的投资方或关联企业。
|
|
|
|
|
|
对于这两种采集方式的优劣，我们可以从**准确**与**效率**两方面加以对比。
|
|
|
|
|
|
直接采集的一手需求更准确，所以产品经理一定要确保手里有足够比例的需求是直接采集的，这样才能让产品本身和自己对产品的判断更接地气。
|
|
|
|
|
|
而间接采集的二手需求，就需要带着“问号”来看，思考原始需求方和转述者分别是谁，以及它有没有被曲解过。但二手需求（比如一份客户反馈周报）可以通过更多的人，收集到更多的用户声音，而且是经过梳理的，所以获取信息的效率更高。
|
|
|
|
|
|
扩展到实践层面，团队内“全员参与采集，产品人员处理”是比较可行的模式，是一种效率和准确度的兼顾方案。
|
|
|
|
|
|
### 2.说和做
|
|
|
|
|
|
用户“怎么说”表达了他的观点，“怎么做”则反映了他的行为，这两种需求采集方式也是各有利弊。
|
|
|
|
|
|
“说”最大的劣势是“耳听为虚”。倒不是说用户故意想骗你，而是因为各种实际情况，有可能言不由衷。比如被问了一个从来没想过的问题，又不想回答不知道，就临时编了一个答案。
|
|
|
|
|
|
Sony发生过一个有趣的故事，曾经他们新推出一个新款游戏机，邀请用户来访谈，其中有一个问题是“两种外观设计，你更喜欢黄色还是黑色”，大多数用户说黄色，访谈结束的时候，Sony跟用户说，感谢你的时间，可以拿走一台游戏机作为纪念，结果发现大多数用户都拿了黑色。
|
|
|
|
|
|
所以，用户怎么说和怎么做经常是不一致的。
|
|
|
|
|
|
那么怎么解决耳听为虚呢？就是看他“怎么做”，像Sony那样让“说”和“做”同时发生当然是个好办法，只是成本不低。
|
|
|
|
|
|
“做”的优势，就是“眼见为实”，但它也有劣势——那就是，我们不知道用户为什么这么做，背后的原因是什么。这也就意味着，我们只靠用户“怎么做”的结论是没法从根本上解决问题的。于是，还是需要回过头再去听他怎么说。
|
|
|
|
|
|
对于处理用户“怎么说”的信息方面，我还有个技巧，那就是注意区分用户说的“观点”和“事实”。用户一般不会故意扭曲事实，但他的个人观点就要带着“问号”听了，你要习惯性地追问支撑用户这个观点背后的事实。
|
|
|
|
|
|
所以，“说”和“做”是一对不可分拆的方法、可以互相补位。
|
|
|
|
|
|
### 3.定性与定量
|
|
|
|
|
|
定性研究通常是对少量样本的深入研究，可以找出问题的原因，属于个体研究；而定量研究是对大量样本的研究，可以发现现象、验证事实，属于群体研究。
|
|
|
|
|
|
**定性研究**可能会存在的问题是“以偏概全”。
|
|
|
|
|
|
简单来说，如果你的产品有几百万用户，而定性研究经常只针对几十个用户，那么这几十人是否能代表全体呢？比如你为了调研的方便，只选取了北京五环内的用户，这种情况下很可能被部分样本的特殊情况带入歧途，所以我们要辅以定量的方法。
|
|
|
|
|
|
但是定量会“以表代本”（表面的表，本质的本），只能用来发现表面的现象，却无法从中知道背后的深层次原因。
|
|
|
|
|
|
比如，你通过定量的数据发现11月份用户活跃度比10月份降了5个百分点，那么，就可以抽取几个10月活跃但11月不活跃的用户，做一个定性的访谈，来搞清楚到底发生了什么。
|
|
|
|
|
|
需求采集理解用户的过程，并不违背人类认知新事物的一般规律——从观点到行为，再从行为到观点，一样会从定性到定量，再从定量到定性，以实现螺旋式上升，使了解和证实在不断迭代中得到进化。
|
|
|
|
|
|
### 4.是否在真实场景里
|
|
|
|
|
|
采集是否发生在真实的需求场景里，也是一种分类方法。
|
|
|
|
|
|
发生在**真实场景里的采集，优势显然是更真实可靠**。举个例子，平时用户在家里用产品，采集也发生在他家里，会更加可靠。当然，这种情况下，记录难度会增加。而**出于性价比和效率的考虑，有一些采集是在模拟状态下完成的**。
|
|
|
|
|
|
因为假的场景里，可以更方便地录音、录像、录屏等，也可以更方便地给别的同事或利益相关方观察，以促进共识的达成。比如，很多大公司都有专门用于用户研究的房间，提供单面玻璃、观察室等配套设施。
|
|
|
|
|
|
当然，有条件的话，我个人还是倾向于优先在真实场景里采集需求，因为这样更具“临场感”。
|
|
|
|
|
|
能够拥有“临场感”是产品经理的一项基本能力。因为需求本身通常都是带着特定场景的，只有到那时那刻去亲身体会（或者通过想象去体会），才知道你的设计是不是有问题。而对这种体会的准确把握，就是“临场感”。
|
|
|
|
|
|
之前我听过一个面向钓鱼爱好者的产品——“智能鱼漂”。这款产品可以通过APP观察鱼漂的状态，提醒钓鱼者有没有鱼上钩。打算推出这款产品的公司认为这样对钓鱼新手的帮助很大。
|
|
|
|
|
|
但经过临场观察之后，就发现了不少原先的设计问题。
|
|
|
|
|
|
首先，每次提醒之后都需要重置鱼漂的状态，而钓鱼的时候，人们要经常搓饵料，手上黏黏的，根本不方便操作手机。更要命的是，很多人钓鱼本来就是为了要远离手机、放空自己才去钓鱼的。
|
|
|
|
|
|
钓鱼的人给了些建议，说用振动提醒如果和智能手环相结合，可能会好些。作为产品经理，最好去钓几次鱼，或者多看几次钓鱼，才能找到这个临场感。
|
|
|
|
|
|
### 5.是否和产品发生交互
|
|
|
|
|
|
最后一个维度的分类方法，是看需求采集过程中，用户是否和产品发生交互。
|
|
|
|
|
|
有些需求的采集只是跟用户聊一聊，用户在现场并没有接触这个产品。这种需求采集可能更多的是在“发现新问题、探索新方向”。还有一种采集方法是在用户跟产品发生交互的状态下进行采集，往往更适用于“优化现有方案”，当然，如果你没有产品的时候，也可以让用户和竞品发生交互。
|
|
|
|
|
|
所以，不一样的阶段、不同的目的，需要使用不同的需求采集方法，通常是先探索方向，再优化方案。
|
|
|
|
|
|
对于很多产品，用户想象中的自己是否需要，和真的用过以后的自己是否需要，是完全不同的。而这正需要通过产品交互来发现，下面是我给两种很典型需求的隐喻。
|
|
|
|
|
|
### 电视机需求VS洗碗机需求
|
|
|
|
|
|
电视机：装修好新家，大多数人都觉得应该有个电视，这是必需品，所以一定会买来放在客厅或卧室里，但之后可能一个月才开一次，几乎不用。
|
|
|
|
|
|
洗碗机：在国内因为大家都不觉得这是必需品，所以很少有人买。但如果不小心买了，用过之后发现洗得确实挺干净，每周能因此省下不少时间，就“根本停不下来”。
|
|
|
|
|
|
所以，简单地说：
|
|
|
|
|
|
电视机需求，是用户以为自己要，但有了并不用的产品功能。
|
|
|
|
|
|
洗碗机需求，是用户以为自己不需要，但用过就离不开的产品功能。
|
|
|
|
|
|
当然，电视机和洗碗机最初的诞生，还是得靠没有产品交互的需求采集方法。
|
|
|
|
|
|
## 今日案例：淘宝产品的完整需求采集
|
|
|
|
|
|
讲完五种需求采集方法的对比，下面来聊聊一个我参与过的淘宝产品的完整需求采集案例，实际情况并没有这么简单，这里为你保留了需求采集的关键节点和主要方法。
|
|
|
|
|
|
### MV Paperwork阶段
|
|
|
|
|
|
随机抽样了40个用户做访谈，据此写出潜在的用户故事、了解用户需求场景、分析用户生态、用户画像、用户旅程什么的，以确定产品方向。你去了现场就是直接采集，你事后看报告就是间接采集（以下都是，如果你只看报告，那都是间接采集），我们在真实场景里听用户定性地说，无产品互动。
|
|
|
|
|
|
### MV Paperwork转Prototype阶段
|
|
|
|
|
|
投放了20万份调查问卷，确定了产品功能优先级的排序。
|
|
|
|
|
|
当然，这只是确定优先级的辅助手段，最终做什么，还是由产品团队而不是用户决定。我们没法面对20万份问卷，所以会处理成汇总报告，算间接采集，听用户定量地说，而是否真实场景、有无产品互动，在这个情况中不是很确定。
|
|
|
|
|
|
### MV Prototype阶段
|
|
|
|
|
|
功能设计的同时，做了可用性测试（简单的解释一下，就是让用户来使用产品的原型）。期间陆续找了10个用户，以辅助最先实现的那几个功能优化。这是直接采集，在非真实场景里看用户“定性地做”，用户与产品是有互动的。
|
|
|
|
|
|
### MV Product和Promotion阶段
|
|
|
|
|
|
根据产品的用户使用情况做数据分析，不断地改进产品、改进运营策略。这算间接采集，看用户“定量地做”，应该是真实场景下，用户与产品有互动。当然，这个阶段显然也需要多和用户聊天，只是不再展开讲了。
|
|
|
|
|
|
以上，每个场景下用什么方法，为什么用这种方法，你可以自己再复习一下。
|
|
|
|
|
|
## 小结
|
|
|
|
|
|
整体而言，需求采集是一个螺旋上升的过程，各种方法要反复交替使用。
|
|
|
|
|
|
当然，这是一个比较重要的产品，所以在需求上投入了较多的时间与人力。更多的时候，会视情况采取简化的方案。而每种方法具体怎么运用，比如“问卷如何设计”这类的方法，你可以从很多专业图书中获得，我推荐你看看《用户至上：用户研究方法与实践》这本书。
|
|
|
|
|
|
这一讲，我们从直接与间接、说和做、定性与定量、是否真实环境、是否与产品交互5个维度对需求采集方法进行了分类，了解了各自的适用场景。你以后在采集需求的时候，可以从这5个维度思考一下应该用哪一种方法。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
希望你可以分析一下当前你负责的产品，碰到的各种问题，找一个可以通过需求采集来推进解决的问题，然后配之以合适的需求采集方法。
|
|
|
|
|
|
你可以在留言区写出自己的答案，与我和其他同学一起讨论，也欢迎你把文章分享给你的朋友。
|
|
|
|
|
|
## 扩展阅读
|
|
|
|
|
|
|
|
|
|
|
|
> 书名：《用户至上：用户研究方法与实践》
|
|
|
> 作者：\[美\]Kathy Baxter、Kelly Caine、Catherine Courage
|
|
|
|