如何判断用户的需求要不要实现

2016-04-14 09:35:20

最近在搞运营， 其中有一个场景是用户建议收集版块， 大概的意思是：要想尽一切办法让用户参与到产品研发中来。关于这个详细的做法与描述，可以看小米的《参与感》，相信在那里已经描述的非常清楚了。

我也仔细看了小米的MIUI论坛中关于用户提的问题的处理方式，首先他是对粉丝是分级的，用户提的每个问题他也不是必须要一定要解决和处理的，会根据用户顶贴高的进行研发。这个是他的基本原理。现在我们面临的问题是，前期为了让用户参与，对于用户提的意见要尽可能多的响应，这就带来一个问题，用户提的问题未必是真的问题。即真需求与非真需求的筛选问题。

随着反馈人员的增加，产品中的功能越来越多，越来越臃肿，也越来越复杂。之前所有的设计理念啥的也都不支撑了。

在调研过程，一些用户总不能一个功能也不提，所以会想办法给你一些建议。或者通过一些活动刺激的原因，必然也会提一些问题上来，但这些并不一定是个问题。?经常有这样的情况出现，软件里增加了某一个功能，就会提有没有批量调整这个功能类似吧。解决这样的问题，我们可以把握以下几个原则：

1、验证是真的需求。比如有用户提出软件里有个临时删除功能，因此提出要有一个批量删除临时删除的条目。要想判断这个需求是否合理，可以做以下判断：1）目前所收集的工程中，临时删除的条目有多少，多还是少；2）反馈这个问题的用户他做的工程中，有多少临时删除的条目，数一下，不超过20条的，都是假需求。3）通过后台监控数据，观测下目前用户对临时删除功能使用的情况是怎么样的。相信通过这三个数据就能判断出此功能该不该做。

2、??大量需求筛选：当有大量需求需要做的时候，可以让粉丝进行投票排序，以确定优先做哪个功能。

3、灰度测试验证可用性实用性：单独给此用户实现，并观察在近期一段使用此功能的使用频率，再判断要不要全面推广开。

4、新功能正反馈：新开发的功能在投放后，针对使用过的人做定向调研，以判断该功能是否真的满足。

结合以上信息，在需求收集前期，如果有用户提出这样的问题，不妨直接从用户现场结合上页的4个方向去验证，多少也可以判断出用户提出这个问题应该受关注度有多大，价值有多大。

我们总是希望给用户提供最有价值的产品，而不是简单的功能堆砌。