您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
用户真实需求的分析、挖掘与管理
 
  3035  次浏览      19
 2018-1-22 
 
编辑推荐:

本文来自于人人都是产品经理,想要做出好的产品,就是要想方设法得到产品真实的用户需求,本文我将根据工作中的总结、平时的学习积累,对如何分析、挖掘出真实的用户需求,和如何管理需求做一个简要的总结。

一、用户需求的分析

1. 确定目标用户群及其特征

目标用户群是我们产品的直接受用对象群体,他们的重要性不言而喻。目标用户群贯穿于产品这个的生命周期内,作为产品经理,我们要时不时的问自己:“这是不是目标用户群想要的?”“这么做有没有偏离目标用户群?”。

要确定产品的目标用户群以及目标用户群的特征,通常我们需要明确以下内容:

产品的使用场合:目标用户群在什么时间、什么地点,如何使用我们的产品?

目标用户群体所处的地理位置:是农村?城市(一线城市还是二线城市)?

目标用户群体的生活方式:确定他们的价值取向以及态度。

目标用户群里的使用产品的行为:使用产品的频率如何?他们的决策过程是怎样的?他们的消费渠道是什么?购买时产生的费用支出是多少?

目标用户群体的人口特征:性别,年龄,受教育程度,收入情况。

产品通过目标用户群获得利润的潜力估计:获取利润的成本如何?提供服务的成本如何?

2. 确定目标用户群的痛点

通常,用户真实想要的产品或服务与他们实际购买到或使用的产品或服务间总会用一些差距,这个差距就是用户需求的痛点。评估出这个痛点,才能使我们的产品为用户带来真正的价值。

评估一个需求点是不是用户痛点的方式,主要有:

反向判断法:如果一个需求不能得到满足,导致了用户不会再继续使用或消费的需求就是痛点。

付费策略法:用户愿意为之付费的需求,就是痛点。

变更判断法:用户使用场景变更,也许会导致非痛点需求转变为痛点需求。

马斯洛需求(生理、安全、社交、尊重、信息获取、审美、自我实现)判断法:越底层的需求越可能是痛点需求。

二、挖掘与评估真实的用户需求

在介绍挖掘真实用户需求的方法前,有三点需要我们注意的。

用户认为习以为常的需求,在诉说时就会忽略,用户表达的需求有时是失真的。

由于用户认知和本身能力有限,所以表达不准自己内心真正想要的需求,他们不知道答案是什么。

用户在特定的场合下,用户会说出违心的需求,我们会被用户所欺骗。

由此可见,想要挖掘出真实的用户需求,是需要费一些心思的。当然,有的用户会直接说出想要什么,但是大多是情况用户说的只是解决方案,并不是问题。

所以,我们要学会洞察人性,从人的本性去挖掘出最真实的需求,这也是挖掘用户真实需求的第一种方法。方法总结如下:

洞察人性法:通过人性去判断用户内心最真实的需求。实现一个功能之前,看这个功能是否符合人性,是否跟具体的人性表现相匹配,如果匹配就值得去做。人性的主要表现有:追求快乐、追求高价值、爱美、懒惰、喜欢猎奇、追求有趣好玩、逃避恐惧、建立存在感等。

马斯洛需求层级法:越上层的需求被满足,产品越能展示出高的价值,用户也越愿意为之付出更高的代价。看要做的功能是马斯洛层次的哪一层需要,来判断是不是该做。对应底层需要的功能应该做,同时挑一些对应的中层或高层需要的功能。

观察法:既然用户表达出的需求并不靠谱,那么我们可以观察用户,观察他们的言行举止、行为。推断出用户的内心世界,判断他们真正想要的是什么。

这里顺带说一下需求的评估方法,除了可以应用洞察人性法和马斯洛需求层级法之外,评估需求还可以使用KANO模型法、产品定位法和使用场景法。

KANO模型法:将需求归类到基本型需求、期望型需求和兴奋型需求中。基本型需求的功能必须要做;期望型需求的功能选择性做,提高产品质量;兴奋型需求选择1~2个去做,达到让用户尖叫的效果。

产品定位法:根据产品定位来评估需求是否要做,评估该需求是否符合产品定位。与产品定位比较远的功能就不需要做。

使用场景法:根据用户的使用场景评估需求是否要做。罗列目标用户群的主要使用场景、次要使用场景,基于罗列出的使用场景判断在不同场景下不同需求是否要做。

三、需求优先级的定义

处理优先级的原则,就是“重要性+紧急性”,也叫作商业价值原则。

1. 对于未上线的新产品

未上线的新产品对应的是产品从无到有的过程,此种情况是没有相关运营数据作为支撑的。

通常情况下,用户需求的重要性为:基本型需求>期望型需求>兴奋型需求。

基本型需求是必须有的需求,没有基本型需求,用户是基本上使用不了产品的,如果不做基本型需求,产品将不能使用,基本型需求的重要性是最高的。

期望型需求是用户期望能有的需求,这种需求用户希望越多越好,没有期望型需求产品还是可以使用,因此基本型需求的重要性要大于期望型需求。

兴奋型需求是产出用户预期的需求,存在则可以给产品加分,没有也不会有影响。如果去掉兴奋型需求,对产品的使用不会有太大影响,因为已经有了基本型需求和期望型需求。所以,兴奋型需求的重要性低于期望型需求。

其实,每个用户心里的基本型需求、期望型需求和兴奋型需求都是不一样的。用户A认为的兴奋型需求在B看来也许就是期望型需求。这是随着时间在动态的变化的,产品需求优先级的定义要根据当时的不同情况来确定。

另外一个重要的因素就是紧急性,基本型需求的重要性最高,且是最紧急的,所以基本型需求的优先级默认是最高等级的。正常情况下,肯定是先做基本型需求,在开发基本型需求时,往往会由于运营、销售等业务需求,会同时做一个期望型需求(重要不紧急)和兴奋型需求(紧急不重要),主要是为了制造产品的亮点,在市场上与竞争对手形成差异化,同时,利用期望型需求和兴奋型需求赢得用户的口碑。

2. 对于已上线产品

此种情况主要是一个调优的过程。此时有了运营数据作支撑,通过数据可以分析出用户的行为。此时需求的优先级原则还是“重要性+紧急性”。可以根据功能的使用率、使用次数和重要性,通过计算得到结果,再结合紧急性来定义需求的优先级。

通常情况,我们默认基本型需求优先级是最高的。

用户需求重要性=(功能的)用户使用率*功能使用率*类别重要性(指期望型和兴奋型需求)

此公式综合考虑了有多少用户需要、用户是经常使用还是偶尔使用、对用户重不重要等因素。

举例说明下:

1功能是期望型功能,一定时间内,总用户数是100人,其中50人使用过1功能,那么1功能的用户使用率就是50/100=50%。这50人使用时,一共使用了1000次,那么1功能的使用率就是1000/50=20。最后,期望型需求的类别重要性我们设置的是50%(基本型100%、期望型50%、兴奋型25%),那么1功能的数值就是50%*20*50%=5。

2功能是兴奋型功能,一定时间内,总用户数是100人,其中30人使用过1功能,那么1功能的用户使用率就是30/100=30%。这30人使用时,一共使用了900次,那么1功能的使用率就是900/30=30。最后,期望型需求的类别重要性我们设置的是25%(基本型100%、期望型50%、兴奋型25%),那么2功能的数值就是30%*30*25%=2.25。

由此看出:1功能的数值大于2功能,所以1功能的优先级要高于2功能。

最后,对于收费的需求的优先级,需要判断其经济效益——经济效益高且紧急的需求是优先级最高的。其次是经济效益高且不紧急的需求,再次是紧急且经济效益不高的需求,最后是经济效益不高也不紧急的需求。

四、需求的管理

1. 需求工作量的估算

需求工作量的估算主要参照的是斐波那契数列法,此方法详细的大家可以百度、知乎一下。本人也是在平时学习中了解到的,暂时还没有实际应用到工作中。

具体方法如下(工作量以小时为单位):

选定参照物。选择一个中等工作量的需求作为参照物,其数字为5。这个数字5是工作量的参照数字,以它作为基准。

团队成员定义工作量。团队成员每个人以斐波那契数列的数字1,2,3,5,8,13,21….定义此需求的工作量,基于与数字5的对比。

进一步明确细化需求。有时如果需求不明确,成员给出的工作量数字分歧会很大,此时我们就要将需求明确细化,具体到每一个功能点的拆解、具体的交互流程、相应的规则等内容。

确定结果。明确需求后,根据成员给出的数值,使用较高的数字或出现频次最高的数字作为该需求的工作量。

通常使用该方法,也可以得到该需求其他相关功能的工作量。

2. 需求管理的工具

我们在工作中要跟进需求的进度,通常是以excel表格的形式进行管理。

下图是我在工作中使用过的表格管理表头信息。

每一个功能点,对应的计划时间、需求阶段、阶段状态、实际完成时间、预计发布时间、相关负责人等都需要填写,责任到人,这样才可以有效把控需求的进度。

此方法也可应用在项目管理中。

五、总结

用户真实需求的把控是十分重要的,我们应当掌握需求分析和挖掘的方法,学以致用,这样才能使产品处于不败之地。

以上就是对于分析、挖掘和管理用户真实需求的方法的简单总结,希望可以对大家有所帮助。

 

   
3035 次浏览       19
 
相关文章

需求分析师的能力模型
基于模型的需求管理方法与工具
需求管理工具DOORS 的接口
使用Web+EA实现基于模型的需求管理
需求经过大脑的过程:需求分析评估方法
 
相关文档

需求分析与需求管理
需求分析具体要求全解
需求分析与验证
需求分析的核心线索
基于UML的需求分析方法
 
相关课程

需求分析与管理
从需求过渡到设计
业务建模与业务分析
产品需求分析与管理
需求分析最佳实践与沙盘演练