当写下这个标题时，觉得是不是切入点太大了，因为自己并非全能需求大咖，也不是要写专业的指导性文章，只是在读完一篇推文如何把一款产品做死后，产生了较强烈的共鸣。不是说文章的角度和内容是有多新颖独特，其文末总结也是大师常常挂在嘴边的敏捷开发精神。而是这共鸣也来自于今天发生的两件事。
一是我们BA的周会上，劳拉同学分享了她在实施一个客户时的成功经验，即花最少的代价去实现客户的需求，尽可能简化需求和“拖”需求，有些用户拍脑袋的需求自然而然就会随着时间推移和预计成本而被cut。当时，我也是深受其启发和影响，因为通常在客户看似很急的需求下，以及重重催逼下，往往会陷入我要尽快帮他把功能做出来的思维定势中，但也往往会变成wasted stories.
产品的功能并不是以数量取胜的，那些可有可无的功能不仅仅会降低用户的产品满意度，还会拖延产品上线的时间。毕竟在产品的探索期，小步快跑更为重要…
第二件事也就是下午的一通用户的来电。整个通话持续了有快一个小时，可以说用户就提出了三个他觉得急需要解决的要求，但是由这三个需求所引发的不满足以让他反反复复的絮叨了一个小时。为了安抚他的情绪，我不得不在电话里接受了他的需求（虽然我心里已是比较认可用户的抱怨和诉求）电话挂掉时，旁边的同事就说，你这样答应他的需求，是不是太草率被用户牵走了，而且文中也提及伪需求是产品的坑。
其实我认为也不然，有句话说，没有场景的需求都是 YY。这个客户的抱怨并非没有根据，比如他们存在很多分批实收付款的情况下，如何体现日现金报表？同样一个需求，可能对于货主或者大三方来讲，更关心的是结算月而非结算日。但对于小专线老板而言，他必须关心到每天。财务每天登进登出，看不到这个增量的变化，老板很难发现是否存在猫腻。
所以写到这，想说需求也并非是用哪一种方法去筛选是最好的，也不是说上面两则实例就是反的，应该说是做我们觉得对的。就像大师说的，凡事多问几个为什么，让用户多说，发觉它们最实质的需求，不做需求的脑补。
