需求挖掘：老司机教你如何获取需求？​

一、定义

1. 什么是需求？

需求是人们在某一特定的时期内在愿意付出各种可能的成本（时间、精力、现金）购买某个具体或者虚拟的商品、服务的数量或数量集合。例如肚子饿了又懒得做，在线点餐外送就是一种需求，用户愿意多花费比线下饭店更贵的价格购买一份餐品和平台附带的服务，于是诞生了像美团外卖、饿了么等企业，这是一种欲望需求。

此外，问题也是一种需求，用户在使用产品时遇到的各种问题，产品就是需要解决这些问题从而满足用户的诉求。

2. 什么是需求挖掘？

需求挖掘是主动通过一系列的方法、渠道获取用户非表层（深层次）真实需求的过程。例如这样一个通过与需求方对话完成需求挖掘的场景：

运营人员小龙：我们即将推出一项新的服务，希望上线一套能收集用户反馈还能将反馈同步到不同商家的的工具？

产品经理小菜：你们用这套工具去做什么？

运营人员小龙：我将用户的反馈建议进行统计整理后，同步给商家，给予商家最好反馈内容。

产品经理小菜：你们一般收集反馈内容包含哪些数据类型？是否需要人工处理数据呢？

运营人员小龙：图片、语音、文字都有，我们需要把用户的反馈内容挑选出有用的同步给商家，商家去改善从而为用户提供最好的服务。

产品经理小菜：你们现在是用什么工具去管理这些数据呢？

运营人员小龙：我们是通过Excel完成，考虑到工作量还是希望上线这个系统。

产品经理小菜：我们可以从用户获取服务订单的维度，将用户的反馈内容精准推送到订单对应的商家后台和内部邮箱，即使用户现场出现问题可以第一时间找到商家配合解决，不需要你们主动去进行推送，只需从后台负责运营监控即可。

运营人员小龙：那这样更好呀！

真实需求就是这样被一步步挖掘出来，我们挖掘出运营人员的核心诉求是把用户的反馈同步到商家侧，让商家侧进行服务升级，为用户提供良好服务体验。现在只需负责监控商家是否实际去执行落地，效率和结果会比直接通过系统工具完成更好。

二、目的

1. 需求挖掘，获取真实需求

（1）没有需求挖掘，需求不完整

用户（项目中指需求方，以下均用用户代替）的需求普遍是基于一定的业务视角提出的，业务之外的关联及配套需求是用户考虑不到的。例如用户即便已经签完需求确认单了，后面仍然有不断变更和新增的需求，因为对于用户来说这是无意识的或者未梦想的。

如下图所示，用户需求像一座冰山，有很大一部分信息是埋藏在海平面之下的，这会需求挖掘造成困扰。

• 意识到的需求：位于海平面上方，一般是困扰用户的问题，用户自己能够想到的功能。
• 无意识的需求：这些需求主要分布在用户实际工作场景，用户不实际操作或者产品经理没有场景模拟的能力，这类需求也是容易漏掉。
• 未梦想的需求：用户不懂产品、技术，对技术解决方案不擅长，无法构想出具备革新性的解决方案，产品经理需要对问题域充分理解的基础上选择合适的技术方案，才能创造出用户梦想的功能。

用户也不会考虑需求变更产生的负面影响，虽然经验丰富的产品经理会向用户阐明需求不能变更的原因或变更后的影响，但是有的需求是因为产品经理没有经过深层次挖掘造成的“产品bug”是必须响应的，不然用户的业务实施起来效果不佳。

例如产品经理小菜（以下简称小菜）为房产中介公司开发信息管理系统，该家公司的房产经纪人小明（以下简称小明）向小菜介绍：“他平时是通过两个本子工作，一个本子记录房源信息，一个本子记录客源信息，便于查找匹配机会。但是现在客户和房源增多了，记录和查找都非常麻烦”。小菜一想，很简单，两张数据库表+查询功能即可解决，便告诉小明说，没问题。（仅挖掘意识到的需求就停止了）

系统交付后，小明找到小菜说：希望系统可以支持多组信息查询。小菜觉得查询多次不就行了，问什么还要同时查多组信息？

小明告诉小菜：多次查询，查询结果没有合在一起，不方便。（这就是实际场景的无意识需求，实际场景客户需求和房源之间存在一对多和多对一的关系）

小菜觉得增加多做同时查询并且结果合并在一起比较麻烦，不确定是否响应这个需求变更，于是回去问其领导小牛，小牛一听便明白了，小牛就给小菜建议：建议你增加一个记录销售线索的数据库表，每当新增一个房源或客源时，系统自动生成相应的销售线索，这样可以连查询功能都不需要了。（这是用户梦想的需求）

设想一下，如果没有小牛的建议，小明的需求也必须响应，因为是因为小菜没有考虑实际场景一个客户对多套房源有诉求，或者多个客户同时对一套房源产生诉求，属于小菜的“产品bug”。

这时候你去说服了研发继续投入大量的时间把多组查询的需求实现了，然后经过多轮需求变更才达到小牛提供解决方案阶段。代价是就是期间浪费大量的研发资源，并且研发同事也会觉得你的解决方案不靠谱，当你下次提需求时，研发会不断去挑战你的方案可行性及解决效果。此外，用户还会觉得你能力一般，总是用户说啥，你做啥，没有体现产品经理的价值，等同于“需求翻译机”。

（2）没有需求挖掘，提供用户不是真正想要的

有一次运营部小龙找到产品经理小菜说：希望让用户关注公众号后自动推送一些内容，回复的内容可以跳转给公众号某篇推文或者页面，这个回复内容可以自由编辑。

小菜一听觉得简单，不就是增加关注自动回复的基础功能嘛，在页面提供一个嵌入一个html文本编辑器不就行了。然后，小龙很快就把需求文档写好交付开发研发。上线后，让小龙来体验和验收，小龙很生气说这不行，不能用。

小菜好奇问：你们要的不就是可以随意编辑用户关注公众号后自动回复后的内容么？

小龙说：回复文本可以，但是在里面放链接不行，而且也不支持小程序的小程序的链接（需要appid和页面路径这些字段参数）。

因为着急使用，小龙便通过将公众号授权第三方，使用第三方完成日常运营需求。

总结一下小菜的问题在哪，小菜拿到需求，完全听从用户的，没有经过深层次挖掘用户目标，虽然提供了编辑器，但是没有提供将链接转为超链接的功能和插入小程序链接的功能，最后需求方小龙完全用不了。

你站在用户的角度想想，你关注了一个公众号，公众号自动回复一段文本夹杂很长链接是什么感觉？你站在小龙的角度想一想，是否有同时回复多条的场景呢？是否有考虑他们的活动是设计在小程序里，需要让用户便捷去小程序呢？

显然，都没有考虑到。小菜经过经过需求挖掘后，并结合实际场景考虑重新设计成如下图，不仅满足小龙的所提需求，同时还小龙增加了一些小龙没有想到但又很实用的需求。

2. 需求挖掘，提高效能

产品经理日常获得需求的来源，除了一些来自外部用户反馈和内部老板各个相关部门反馈来的需求，我们还应该根据我们产品不同阶段的去挖掘一些需求来帮助用户在使用我们的产品时，高效的完成用户想通过产品做的事情。

提到效能很多人认为是B端产品应该关注，其实不然，C端页越来讲究效能了，因为越来越多的年轻人没有耐心了，如果你的产品超过用户耐心忍耐极限，一旦有可替代产品，你的产品就会被打入”冷宫“，效能是产品经理持续奋斗的一个目标。

产品生命周期（Product Life Cycle），简称PLC，是产品的市场寿命，即一种新产品从开始进入市场到被市场淘汰的整个过程。

具体来讲，这个过程其实就是经历了一个从“开发、引进、成长、成熟一直到衰退”的阶段。对于企业来说，就是要想办法提高开发和引进阶段的效率，加速成长的步伐，延长成熟以及成功的周期，减缓衰退的进程。

例如在末端快递校园快递配送场景里，常规作业流程是：接货-分货-上货-学生取件。

这看似非常标准化一套作业模式，该企业的产品小菜经过现场观察作业员作业，发现现在的模式有优化的空间，最初设计作业为接货-分货（校园内多区域）-上货目的，在快递网点将包裹运输到校园时，紧急需要一张接货单（带条形码）进行签收和作为交接凭证。

但是现在因为已经建立了快递网点和校园门店已经建立了信任并进行了系统对接，这个单据实际过程没有使用，于是他将接货和分货流程直接合并。在第一次接货时同时完成分货的信息处理，该方案通过并成功上线了，门店作业效率单人效率从300件/小时提升至460件/小时。

有了这次经验，小菜决定继续进行挖掘，经过大量运营数据分析，他发现只要和快递公司完成每个作业环节的对接，并对快递网点到校标准化管理，还可以将接货-分货-上货三个流程合并。也就是让快递公司将各个校区的件提前分好，运输至对应校区，这样效率可达到600件/小时，虽然流程合并，系统中的还是区分业务节点的。当效率提升了以后，可以帮助门店节约一个人力成本6000+的费用。

3. 需求挖掘，提升体验

一款产品带来好体验的标准是：是否超出用户预期，要想提升用户体验必须通过需求挖掘并管理好用户预期，才能为用户带来核心的体验的提升。这个观点来自于711创始人铃木敏文的《零售心理战》，书中提到一种描述是让用户感觉“来对了”、“买对了”、“吃对了”，用户说这句话的原因是超出了用户的预期。

好的体验中最重要的初次体验，谈到初次体验不得不谈游戏了，因为初次体验方面没有人比游戏公司做的好。

例如大部分年轻人都喜欢玩的一款暴雪娱乐的游戏《守望先锋》，一款成功的游戏一定是时间杀手，让人从初次体验就沉浸其中。游戏公司非常懂用户懂人性，知道如何让不同的人上瘾。新用户非常没有耐心，初次使用还对产品不信任，不确定你的产品能给他带来什么，要尽可能让他们的生活更快、更有效率，所以必须尊重用户的时间。

传统方面，一款5v5或多人对战类的游戏，都会让用户停留在等待界面等待所用户连接服务器成功后在进入游戏作战页面。可是《守望先锋》没有让玩家停留在等待页面，而是让所有玩家投入到一款迷你游戏：没有目标，没有规则，玩家可以做互相挥手、握手、拥抱、尬舞等动作，非常和谐快乐轻松，让玩家不知不觉就度过等待时间。

说到这里如果你看明白了，你是不是想到了“吃鸡”这款国民游戏也是这样设计的，实际在这里是隐藏了一个等待界面的，以人为本是好体验的必要条件。

三、需求挖掘的方法

1. 用户访谈

（1）用户访谈前

• 明确访谈目标：访谈分为特定问题访谈和发散性访谈，无论如何在访谈前一定要将这次访谈的内容和问题以文档或者脑图的形式梳理出来。
• 尽量面对面访谈：访谈不只是从对话中获取有效信息，察言观色，也能对获取信息的质量进行有效的把控。
• 选择合适的场地：选择能够让访谈者放松畅谈的地方，比如咖啡馆、茶馆等。
• 对访谈中进行细分：为每个访谈用户建立一张用户画像卡片，因为你邀请是用户代表，他代表一类人群的观点，这是很有必要的。

（2）用户访谈时

• 简单给受访用户阐述访谈的内容和目的：让受访者知道接下来要干啥，会放松很多，页便于他潜意识去思考接下来要回答的涉及的内容。
• 鼓励受访用户讲故事：受访者只是产品的使用者，他无法从专业角度使用很多专业名词描述和回答我们的问题，讲故事会让沟通起来更轻松，也能打开受访者的分享欲望开关。
• 让受访用户对访谈中的问题进行排序：整理在受访过程中已存在或者挖掘出来的问题进行重要性排序，这给产品经理后面进行功能优先级排序提供参考和依据。
• 让受访者尝试提供解决方案：虽然受访者提的方案并不一定可行，但是要让他畅所欲言，一方面为产品经理后期的实施方案提供参考，另一方面还可以分析他的动机。

（3）用户访谈后

• 给予用户一定的奖励：无论是实物还是虚拟的，一定给用户一定的奖励，这样便于维护与受访者之间的关系，下次邀请，受访者才愿意接受产品经理的邀请。
• 问题整理：各个受访者的的问题通过Excel整理成一个工作表，这样便于产品经理后期进行需求分析和挖掘。
• 疑问点趁热打铁：在梳理问题点的时候，对于一些模糊、不确定的场景及问题，要及时联系受访者进行确认，如果产品经理没有理解或理解错了用户的表达的产物，那么后续会产生大量的无用功。
• 需求挖掘：通过每个受访者的问题进行横向、纵向对比分析，提炼出产品需求点和解决方案，并参考受访者的的排序进行功能优先级排序。

2. 问卷调研

（1）问卷设计

• 确定调研目标：根据产品形态、定位，确定你想从用户那里了解他们的内容去设计问题。例如用户是否具有分享意愿、愿意分享的频次以及愿意分享到哪些渠道和场景等。
• 确定目标用户：不同用户人群的用户画像，不同对不同问题的接纳程度也不不同，在设计问卷的时候要要有针对性。

（2）调研方式

• 线上投放问卷：采用问卷星、调查派、问卷网等平台设计调研问卷，然后通过社交平台（微信、qq、微博、脉脉、知乎）进行线上投放分发。
• 线下投放问卷：在样本区域并找到对应目标人群，采用将设计好问卷打印出来、通过平板或让用户扫码等方式进行问卷调研。如调研上班族，可以到写字楼以及附件商超、咖啡厅进行走访调研或者定点摆摊调研。

（3）问卷总结

• 如果线上投放的：一般平台均会有统计功能，通过统计报告即可完成需求分析挖掘。
• 如果线下投放的：需要将问卷结果通过Excel统计整理后进行需求分析挖掘。

3. 业务分析

业务分析是指产品经理对企业各条业务线的进行体验，包括现有业务流程和现有工具所能提供的能力，有条件的可以进行业务建模，抽象归纳后提炼出优化点；最简单的优化方式就是在保证产品目标不变的前提下，优化业务流程，比如现有需要3步完成任务，你提出2步完成任务的需求。

在做业务分析的时候还要考虑企业的战略、企业的发展方向、企业的盈利模式等，找到与公司发展战略相契合的产品需求。比如丰巢2020.4.30开始上线会员制，如果在市场初期，随着知识付费的兴起，假设你向公司提出这样的需求，管理层肯定不会审核通过的。因为这个阶段公司战略是不断通过资本进入，扩大市场规模，最重要的是保证市场占有率前提下兼顾用户体验，战略还不会上升到企业利润层面。

当然，如果考虑契合公司层面的需求，可能还需考虑管理层的一些想法，因为他们的精力更多是在市场、行业层面，他们对整体方向的把握会更准确。如果契合用户层面的需求，需要考虑离用户最近的部门，例如客服、售后、售前、市场等部门。

4. 运营分析

运营分析是指将企业运营相关的数据进行统计分析。数据，是衡量产品功能成效的工具。在产品内通过埋点记录用户行为，通过大量用户在产品内产生的行为轨迹，去发现和探究用户需求。产品上线后，产品经理应该密切关注运营数据的情况，尤其是采用ABtest的时候，需要实时关注数据的变化。

通过运营数据，比如说产品的访问量、用户数、用户使用时长、使用频率、使用时间段、页面访问路径、事件跟踪数据、页面热点图数据、用户流失率、点击率、转化率、留存率、活跃度等方面的数据。

至于这些数据如何获得，产品经理可以从一些第三方平台获取，比如说友盟、TalkingData、腾讯大数据、易观智库、艾瑞、应用雷达、禅大师等，如果这些平台满足不了，那么自己可以设置一些想要的数据监控埋点。

我们可以直观的看到用户在产品内的行为情况，进而评估产品改版(或新功能)效果，挖掘优化点；数据分析可以让我们得出一定的需求结论，但是对行为数据的分析不能完全替代在现实中对用户的观察研究，需要两者结合。比如通过用户行为漏斗去观察用户在某个流程的表现情况，从中就可直观看出用户在哪一步流失较大，紧接着就需要去调研用户为什么流失。

5. 竞品分析

竞品分析是产品经理最常用的需求挖掘方法之一。关注竞品的动向是产品日常工作必不可少的一环，因为竞品也是经过大量的调研、探索、思考才上线的产品。进行竞品分析有利于我们及时对自有产品进行查缺补漏，也有利于取其精华去其槽粕。

那么我们如何去做竞品分析呢，实际工作中并不需要花几个小时去写上一篇详细竞品分析报告，一般我们只需要了解这几点就行：

• 竞品是否有新上线的业务，上线背后逻辑是什么？当前企业是否具备上线该业务的条件？
• 竞品的上线产品的评论及用户反馈。
• 竞品的前端对应后台的管理需求、操作需求、配置需求。

常用的方式是体验，有的外部用户直接下载注册即可使用，有的提供demo，有的提供帮助文档，不懂可以问竞品的客服。

6. 用户反馈

用户反馈是产品经理挖掘需求的最基本一种方式。因此，我们可以看到市场上几乎所有的c端产品均会有「反馈建议」入口，只是每家产品处于阶段不同，入口层级不同而已。

产品上线后，我们可以通过用户反馈后台、各大应用市场、微信公众号、微博、贴吧、客服等渠道去收集查阅用户反馈，无论积极还是消极的，都要去分析这些反馈背后场景、动机、原因，提炼出有价值的信息。

需要注意的是，用户反馈设计一定要考虑鼓励用户进行反馈层面的因素，用户反馈后有条件可以给予一定的奖励，这样才刺激更多用户将自己内心的想法表达出来。

7. 上下游开放平台

关注上下游开放平台是也是产品经理的一项内容，尤其企业的上游企业的开发平台，往往上游的一些新开放的业务能力，会让下游衍生出不少的需求，夸张的一点的，可以省去第三方平台的使用。

如果企业的产品不存在上下游关系或者就是处于上游阶段，同样也需要关注下游或者相关企业的开放平台是否新上线一些新的接口，这些接口是否可以结合现有业务机进行优化升级？

例如企业产品逐渐采用小程序代替，需要关注小程序的开放能力，如果某天企业要做小程序跳转其他下程序的需求，没有关注的话，需要经过调研官方文档才知道相关的一些条件和规则限制，不利于在接收需求时进行需求回复和评估。

寻找开发平台的方式，常用的是在搜索引擎搜索“关键字+开发平台”，或者直接访问官网，从官网入口访问。

8. 关键词搜索

有些情况下，我对某项需求不了解的情况下，我们会通过关键搜索，去了解关键词相关的资料，从而激发产品设计的灵感，常用的方式主要以下两种：

• 关键词+社交平台：当我遇到一个一个自己不知所措的需求时，社交平台也是我们挖掘需求的一个非常重要渠道，比如脉脉、知乎、微博、百度贴吧、微信等，也有专门的垂直领域的社区，比如产品经理可以去 @孟冬初寒月

  版权声明

  本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！