如何找到用户真正的需求

之前的文章有提过，有些不合格的产品经理会把用户说的直接当作需求，比如产品需要做一个数据展示平台给业务用，业务说需要看几张数据表，因为现在还要去拉数据库，太麻烦了，你就给我展示出来吧。于是这个不合格的产品经理便会把业务说的这几个数据表展示出来。更有甚者，有些产品会说反正有地方可以看，不用给业务做了。不要觉得诧异，在没遇见之前，我也是不相信有这样的“产品经理”。

那合格的产品经理会怎么处理呢？第一肯定是想弄清楚业务为什么会关注这些数据，或许他们关注这些数据是为了更具体的目的，比如查找问题。我现在规划这个需求就是这样，大概举例描述一下，这些业务是因为发现某些正常接入的酒店无法正常在外网展示售卖或者产量很低，因为他们想通过查看对接过程中的一系列数据查一下到底问题在哪。那其实作为产品，我需要做的是帮助他们找到那些无法正常在外网展示售卖或者产量很低的酒店，并且直接告知他们原因以及修复的办法。再深一层，我发现一般是供应商让他们帮忙拉数据，然后发现问题后让业务帮忙查，最后问到产品或者开发，然后原路把信息反馈给供应商。那这样的话，我就应该把这块需求面向供应商去做。

最终确认把这块需求对外去做，首先当然是去调研供应商的需求，了解清楚供应商到底在乎哪些数据，为什么，然后再去定位到真正的需求。这里额外提一点，就算是供应商再关注，还是需要公司评估这部分数据是否可以直接对外，信息安全要做好（虽然无形会增加很多流程和时间）。那么问题来了，怎么去了解供应商的需求呢，因为产品并不是直接对供应商的，业务才是直接对供应商的。我呢，开始天真的以为，直接调研业务，问清楚他们目前为止，供应商一般会让他们提供哪些数据，为什么提供这些数据。后来真正调研的时候才发现，业务说的好像都是他们关心的需求。比如某些特殊操作的原因和明细，而且他们会把这些需求放在优先级极高的地位。开始觉得也对，供应商应该也很关心为什么被特殊处理了。不过为了保证需求真正来源供应商，后来我还是自己做了份调查问卷，首先从业务那边搜集到了很多需求，最后整理出来后拜托各个业务发给供应商自己去选择他们认为的最紧急的三个需求，最后发现业务觉得优先级最高的那个并不是供应商选择的排名第一个的需求。原因其实很简单，因为那是特殊操作，所以只是少部分的供应商才存在，只是因为存在这种问题的供应商总是找业务，所以给他们的感觉就是这个需求很多也很急。

所以个人认为需求调研一定要直接找到产品的用户，一层都不能隔。好，现在一层也不隔了，你还是会发现用户的思维一般只会单线发散。比如产品如果问用户平时在操作过程中有没有什么地方觉得麻烦的地方，比如重复人工操作的或者看很多地方才能解决一个问题的？用户可能会说没有，特别是一直在用的，只要不出错，习惯后就觉得很顺手了。那这种时候如果产品经理对业务了解，那可以举例说：你这个数据要去这个模块查看，可是跟这个数据关联的另外一个数据要去另一个模块查看，如果我做在同一个页面是不是就可以让你轻松点。稍微灵光点的用户，这个时候可能就会说了，其实我还会在那个模块查看那个数据，应该也可以做到一起。那了解到这个程度，其实就可以确认需求是有的，那就说明价值是存在的，你可以继续挖了。继续挖就是前面提到的一定弄清楚为什么要看这些数据，最终目的是什么，确认真实需求。如果产品经理对业务一点都不了解，那还是先了解业务，不然问题都提不出来。

所以总结下来，如何找到用户真正的需求：

1，以缩短需求路径，提高效率为目的