百木园
好像有近4个月没写产品类文章了，并不是偷懒，而是这期间经历了裸辞-休整-求职-入职这一系列的事情，没有太接触一线的产品和业务，所以这段时间更多是在思考职业和生活上的一些问题。
而这几天恰逢入职2个月整，刚好完成了第一个从0到1的迭代、和客户有了很多频繁的接触，于是也借此积累了很多素材，有关于需求调研的、关于产品架构设计的、也有一些关于数据模型的，那这次先来和大家一起分享下对于需求调研的理解。
对于产品经理而言，需求调研是一件老生常谈的事情，也是产品经理最重要的基本功之一。
那是不是成长到5年、10年的产品经理就不需要做需求调研了呢？
当然不是。
首先，需求调研做的好坏，很大程度上决定了一款产品的成败，其价值无需过多赘述，所以这件事并不只能交给初级或者入门的产品经理来做；
其次，需求调研本身并不是简单的调查问卷、现场采访聊天这么简单的事情，它是一项由深到浅、由外及里不断能够去提升的能力点。
从产品实习生到工作5年10年的产品专家、产品总监，谁都逃不开要做需求调研，但区别就在不同阶段进行需求调研的方法论、关注点、理解能力都有很大差异。
因此，结合笔者过往的经历和接触到的一些优秀产品经理身上所展现出来的能力，我把需求调研分为了4重境界，大家可以看看自己当前在哪一层？
01 境界1：全盘倾听，全盘照做
境界一很好理解，就是用户说啥你就做啥，常见于刚毕业或者刚入门做产品的新人。
例如，用户说这个列表他需要能够导出来，那产品经理就照做、直接给程序员提需求加了导出的功能，反正用户原话就是这样，那产品也是在遵循「满足用户需求」这样一个大原则，能有什么问题呢？
没错，原话确实如此，是用户亲口说来的，但这其实还是存在3个问题：
1. 用户亲口说出的需求，并不一定是他的真实需求
举个很简单的例子，在你生气的时候，你能保证说出的每句话和真实想法一样么？不能。那用户也是一样的，也许这个功能对他本身可有可无，但鉴于花了钱付了费，那自己多提点需求和功能岂不是更赚了？所以，出于各种不直接可见的目的和情绪，亲口说出来的需求也需要再加以判断和甄别。
2. 用户说的到底是需求还是解决方案？
先来看一下需求和方案的区别：需求是用户遇到的问题以及产生的诉求；而方案则是用于满足这些诉求和解决这些问题的方法。
而用户往往习惯于说方案而不是诉求。例如，“给我加一个导出功能”“没有名字查询的功能的话，我们就完全没法用了”等等，这就是典型的解决方案。
一旦你按照用户所说的方案照做，看起来似乎是满足了他的需求，但用户毕竟不是专业的产品经理，他们所提出的方案肯定会受限于业务和经验，这些方案是否能够解决当前和长期的问题、是否是最优方案、是否又能够解决其他用户的类似问题都是存疑的。
因此，当用户开口说出需求时，一定要「嗅觉灵敏」，判断这是方案还是需求。如果用户说的是方案，那就一定要从方案-诉求-问题这3层刨根问底、找出问题真正的根源。
3. 照做能解决一个人的问题，但不能解决一群人的问题
个体是有很大差异性，更不用说组织或企业了。如果用户说什么你就做什么，那A用户要这个功能，B用户说不要，那到底该如何取舍和抉择？用户的需求经常会出现矛盾和利益冲突，照做是不能解决大部分人的问题的。
总而言之，境界一的优点在于能够仔细倾听用户，而缺点就在于照做，这也是很多刚入行产品在入门路上的必经之路。
02 境界2：选择性倾听，带着方案去调研
前面说境界一的优点在于能够仔细倾听，肯定有人会想：这很难吗？倾听什么时候也变成一种需要单独拎出来说的优点了？
讲真，很难，因为境界二就是这样一群选择性倾听的产品经理。
当产品经理工作一段时间后，沉淀了一些经验也解决了一些问题，内心便逐渐不再像以前那样面对用户「唯唯诺诺」，开始有了很多自己的想法。
在这样的情况之下，当你在进行需求调研的时候，其实在问问题之前内心就已经臆想 和规划出了一套自认为行之有效的解决方案：面对用户，你所有的问题设计和愿意听到的答案都会被用来证明「自己是对的」这件事，而不是在解决真正的问题。
需求调研变成了你用来给自己方案搜集和添加证据的方式。
讲个自己的真实案例吧。
2017年正值小程序创业风口，当时笔者就想和朋友一起做一款活动报名的小程序。因为自己本身也是活动的组织者和参与者，因此，在内心对这个小程序有了一定雏形之后，便开始找身边的朋友开始了调研之旅。
在调研过程中，有活动组织者吐槽说：“现在我们活动报名都要在APP里，每个人报名还要去下载APP，这样很不好用”。
听到这里我喜出望外：诶，小程序不就可以完美解决这个问题吗？无需下载、还不耗内存，这不是很贴合用户诉求嘛！那只要我们上线了和原有APP一样的功能，用户肯定就会抛弃原来使用的那款APP，转而使用我们的小程序。
但事实上，最终来使用我们小程序进行活动报名的人远远没有我们最初所设想的那么多。为什么呢？就是因为当时陷入了选择性倾听、带着方案去调研的陷阱：
1. 人群选择有倾向性
因为想做小程序，所以我们当时的调研人群核心为使用APP进行管理和报名的人群。这样一来，小程序确实在下载、内存和轻量化上相较APP会有很大优势。但其实，我们在无意中通过选择有倾向性的人群来佐证自己想做小程序的这件事。
2. 问题设计侧重于自身产品的优点
正是看准了小程序在轻量化上的优势，所以问的问题会很倾向于使用成本、下载注册等方面利于小程序发挥的问题，而没有问到一些活动、管理、报名等这类更核心的真实诉求。
因此，这样带有倾向性的选择和倾听让我们觉得小程序能够很好的解决用户当前的问题，但我们其实忽略了一大批通过群内手动发帖/跟帖报名的俱乐部群体、忽略了产品替换成本的问题、忽略了小程序对微信版本有要求、甚至很多人都不知道小程序入口等这些基础性的问题，最后也导致了整款产品的Roadmap制定过于乐观、而现实却和预想千差万别。
整体而言，境界1和2都是自己亲身经历过的阶段，但现在看来，这些都不是需求调研的能力层问题，而取决于一个人对人性、对问题、对社会的认知到底有多深刻。
03 境界三：认真倾听，找准根本问题
在逐渐踩完境界1和2的坑之后，产品经理就会来到境界3：认真倾听、找准根本问题。
解决问题的前提是先能够找准根本问题，而问题都是被一层又一层的声音和表象所包围的，一不小心就会掉入境界1和2的陷阱中。
境界1中，解决问题的产品经理是一种唯唯诺诺、任人摆布的姿态；境界2中，解决问题的产品经理是一种高高在上、自以为是的姿态。而境界3所要求的姿态是一种不评判、平等对话的姿态。
在这层境界中，产品经理能够抛开自己的预设和猜想，全心做好一个倾听者的角色，并且有自己的调研方法论（用户故事、用户画像/分群等），能够清晰地从「方案-诉求-问题」或是「问题-诉求」去剖析用户。
不知道大家是否了解心理咨询的过程，在一场心理咨询中，心理咨询师会通过倾听和引导，帮助用户逐渐卸下防备和顾虑、吐露出真实的心声，当然用户调研自然是没有这么多时间和精力去关注到每一个用户的，但这种平等对话的思路和引导方法值得借鉴。
当然，需求调研有非常多的方法论，限于篇幅这里就不展开讲了。但是呢，在境界3需要大家重点关注的是此时面对用户的态度是不高不低、不卑不亢，这里已经和境界1和2有了很大的不同。
04 境界四：调研组织，寻找各方利益平衡点
前面3重境界都在强调单一的人群，但是随着toB和toG行业的盛行，越来越多的产品经理需要从单一的人群转为对庞大的企业和组织进行需求调研。
不同于单一的人群，复杂的组织若要良好的运转起来，其各部门和链条之间势必存在着非常多互相制衡和约束的关系，而这些是是很难通过调研这种摆在明面上的方式问出来的。
因此，境界4进行需求调研的难度和量级将远远大于前面3层。
在这一层的关键点除了选择好关键人进行对应深入访谈之外，还需要意识到2点：
1. 用户并不是表面上看到的职业角色那么简单
他们背后其实是各重身份的交叠：业务负责人、某项目的关键把控人、关键大领导最相信的得力员工等等，如果仅仅停留在一个单一的职业角色，那么很可能就会踩坑。
2. 需要识别出各个部门之间不同的利害关系
这些隐藏在需求背后的利益点可能是由于流程的上下游、绩效考核方式、和关键领导关系亲疏等造成的，这类企业中人情世故的问题会极大程度上影响我们的产品真正推进和落地的情况。
所以，能够真正达到第四层需求调研境界是一件很难的事情，因为你面对的不是一个简单的人群，而是复杂的组织和组织关系，这需要有极强的洞察力和对人情世故的理解能力。
假如你只听了A部门的诉求并给予了满足，但有可能会损害同一公司内B部门的诉求，那么，这个方案就很难在一个公司推行下去；再比如，你按照客户公司Leader的想法推进了一项方案，但是关键执行部门却不怎么配合、总是敷衍推行，那么，这也许就可能和该部门的绩效考核方式有一定关系。
所以，在境界4的组织需求调研中，除了需要像境界3中一样找准每个人的诉求之外，还要梳理出每个小组织、每个个人之间的利益关系图，最终真正能够解决问题的一定是能够相对很好平衡各方利益点的方案。
最后，在写这篇文章的时候，我也想到了乔布斯——一位声称自己从来不做用户调研的产品传奇，他曾经说过这样一句话：消费者并不知道自己需要什么，除非你把产品展示给他们看。
但是呢，大部分人可能都会像俞军在《俞军产品方法论》里说的B类产品经理一样——缺乏天分、但有很强的学习和迭代能力。如果你不是乔布斯这样的天赋型选手，那就还是老老实实做好调研吧，日积月累的调研也能够帮助我们积累出非常好的嗅觉能力。
以上，就是笔者对于需求调研4重境界的理解，大家可以对比看看自己当前在哪一层、未来需要提升和进阶的方向在哪里。
给作者点赞，鼓励TA抓紧创作！
来源：http://www.woshipm.com/pmd/5427549.html
本站部分图文来源于网络，如有侵权请联系删除。