产品思维学习(二)--获取用户需求

上篇 产品思维学习(一)–浅显的整体认识记录了我这个2年的菜鸟程序员对产品的一些浅显认识。下面记录下开发产品的第一步：获取用户需求，分析用户需求，转化产品功能。
之前做的一个产品，是直接面向市场，当时开发周期很紧张，基本是两个星期一个迭代。产品人手不足，基本都是BD去采集需求或者老板根据经验说用户想要什么。于是，我们的产品看着做了很多的功能，但是用户量一直没有上来。这其中就陷入了一个误区，什么才是用户的真正需求。
在产品圈有一个经典的例子（大致意思），用户想去一个地方，说我想要一匹更快的马，福特却给用户一辆车。
这个例子就说明你去问用户想要什么，用户告诉你他想要什么，那是他基于自己现有的认知和习惯说的。如果你按照用户说的来做，那么你的产品基本上没有开始就基本预示着结束了。（我以前就经常听到BD同学说，我今天真的发现一个新需求，用户说如果能够做出×××就真的能够解决他们的需求。汗！）
以上说了这么多主要为了说明获取用户真实需求的重要性。下面谈几点需要注意的问题和采集分析需求的方法。
注意：

1. 借用毛主席的一句话：从群众中来到群众中去。放在我们这里就是：从用户中来，到用户中去。从用户中来，也就是说我们需求的来源是用户，并且是广泛的用户。这里面就可能出现几个误区：第一：产品在一起想，用户可能需要这可能需要那，很多需求基本都是自己臆想出来的，一拍脑袋，好，我们做这个功能，肯定能引爆市场，获取用户量。（我想说，别拍脑袋了，出去转转吧）第二：几位同学出去转了一圈，问了几个人，惊喜的发现几个需求，马上就要做功能。这有很大可能出现以偏概全的错误。
2. 我们都知道，我们的行为不可能让所有人满意。产品也是一样，不可能满足用户所有的需求，也不可能把用户人群定位为所有人。如果在采集过需求后不进行筛选和优先级的排定，那么很可能造成这个产品臃肿不堪，使原来真正解决用户痛点的亮点功能淹没其中，变成一个大而全，丑且重的应用。（我们曾经就犯过这样的错误，由于对需求的了解的不细致，没有抓住用户根本的痛点，没有对需求做认真的筛选，结果整个APP越来越重，其中一些功能几乎没有点击率）。
3. 在做用户调研的时候，无意中引诱用户回答问题。也就是说，基本上问一个问题，99%的人都会这样回答。比如：我就听到在做电话访谈时（一个幼儿家校通的产品），这样问：××家长你好，我是××，我事先给××幼儿园园长打过招呼，想请问你几个问题。老师有没有告诉你，要使用我们这个产品？老师发的消息，你会看吗？你经常陪孩子玩吗？你陪孩子时会和TA一起玩吗？（只抽取几个典型的问题）（这串问题问下来，我也是醉了）。你说你让家长怎么回答，家长回答，老师没有说过？（你都给园长打过招呼了）老师发的信息我不看？（还要不要和老师相处了）和孩子在一起，你说一起玩不玩？这里面很多都是指向一个答案，那么最后即使访谈很多人，看似拿到了一份华丽丽的需求数据，如果把这个作为参考标准，我只想去厕所哭一会！
   所以，获取用户需求可以从以下几点入手：
4. 听用户定性说，确定产品的方向。可以随机抽取几十个用户做访谈，然后记录下所有用户提到的问题。当然也不是听用户漫无目的的说，事前要准备一些问题，进行交流式听用户陈述。希望不要出现上文中类似的问题。导致结果是自己想要的答案，而不是用户真实的想法。同时为了避免出现样本少或者以偏概全的失误，要提前对用户群体进行比对，避免出现访谈的用户都属于同一类人群或者差异很大的人群，最后的结果也会出现很大的偏颇。
5. 听用户定量的说，确定需求的优先级。比如针对目标人群投放几万份调查问卷，当然这里也要区分不同地域的因素，尽可能做到全覆盖。实际情况可能因为时间，人手，预算等不能做到很大量的调查分析。
6. 看用户定性的做，要先做的几个功能具体怎么做，一边设计原型，一边找用户验证。尽最大可能还原真实应用场景。因为在真实的应用场景下用户说的可能和做的会有偏差。设计好原型可以拿给用户看，并且观察用户在真实场景下的行为。避免等到产品开发完，等用户安转后才发现操作流程与现实情况不符，这就悲催了！（开发人员听到产品人员要改需求，恨不能一巴掌打死他)
7. 看用户定量的做，根据用户的使用情况做数据分析不断改进产品。（现在用友盟做数据统计的比较多）。一般数据不会骗人，但是可能会出现我们错误理解一些数据，比较出名的就是微信的下拉拍照，这个功能上线后，拍照的点击率不断上升，这就很可能误以为是下拉拍照转化的，但是真实的情况最终是下拉拍照这个功能被砍掉了。
   以上都是阐述的产品对用户需求的采集和分析等，我作为开发人员，不紧又要多说几句。大部分情况下，都是没有太多的时间给产品做调研，也没有太多的时间给开发人员做开发。所以在对产品进行开发，不要想在一个迭代里加过多的需求，因为时间少任务量大导致产品匆忙上线，不能保证产品质量，影响用户体验。里面就设计到敏捷开发了，下面的笔记中我会阐述下开发中的敏捷开发。
   其实在这个过程中正好验证了：看山是山，看水是水；看山不是山，看水不是水；看山还是山，看水还是水。
   采集用户需求时，我们还比较清晰用户的想法，我们要做什么，也就是看山是山，看水是水；等到需求越来越多，我们渐渐地不清楚用户的真实需求了，也分不清我们应该做什么了也就是看山不是山，看水不是水；最后经过不断的分析筛选，我们找出用户的真实需求，确定产品的方向和功能这就对应看山还是山，看水还是水。