接到了来自业务部的需求反馈，要求马上实现才能签单客户，实现后发现并没有其他用户感兴趣。。。
接到了来自某KOL用户的需求反馈，优化后发现并没有多少用户认可。。。
是不是。。。好尴尬啊。。。
是的。这就是我们经常在产品上线后，优化产品的过程中，获取需求反馈的判断中，遇到不少的伪需求现象。导致迭代无休止、
技術團隊對產品需求真實性的質疑和排斥。因为他们是能清楚看到自己研发的功能有多少用户在使用。
曾经就有技术负责人在我做运营时（那时公司没有PM）去提某个功能需求的时候，问：“你能保证你提的需求我们做出来后就能盈利么？”“只要你保证，我们在公司打地铺，通宵加班研发都没问题”，于是又尴尬了，答案很简单：“保证不了”。
我相信上面类似的情况在各家公司仍不少出现，很难避免。通常需要PM在搜集需求-整理需求-了解需求的过程中，最大可能地去判断需求的真伪。那么如何从排着队的来自四面八方的需求反馈中区分真正的用户需求和伪需求呢？
一、清楚需求来源
一个需求提报上来，你需要清楚是谁提报的，这个人在产品中扮演什么角色，使用产品多久了，在什么情况下提出这个需求，想解决TA的什么问题，然后就是基本的信息，包括性别、年龄、所在省份、城市、职业、兴趣爱好，能提取到的信息尽量提取记录，相当于需求提报人的简易画像，也方便用作未来需求提报的透视分析。因为每个人都有自己独特的需求出发点，你觉得无关紧要，TA觉得没了活不了。就如同你在底层仰望，TA在楼顶俯瞰。
最好通过EXCEL表来做需求的记录，并形成数据公式。相比于常用的word撰写PRD，其实在实践过程中，我更倾向用excel，处理较多数据时更加灵活可控。
二、了解同一需求的反馈量
辨别真伪需求一定是不能想当然的。没有数据的支撑和分析，很难有靠谱的理由来确认真伪。所以多少用户反馈了这一需求，是同类用户，还是不同类用户，反馈数量整体反馈中占比多少，都是些什么类型的用户反馈的这个需求。这能估算出这个需求是否具有代表性和普遍性。如果数量不足或者需求不确定的功能需求（可能影响工期），也可附以抽样调研，通常数据可通过运营人员，从运维的忠实用户群中随机筛选100左右。
三、清楚需求的属性
是细节优化类、还是功能迭代类，是强需还是弱需。细节优化类的需要十几分钟或几个小时就能搞定的顺手也就做了，哪怕只是锦上添花都可接受。涉及功能迭代的影响用户使用习惯的需求，尤其是即将耗费超过一周的研发周期的需求，就要仔细考量了。这就需要我们不断地整理需求，配置优先级和重要性。不要让有限的技术力量浪费在无限需求的开发周期上，毕竟如今的技术好贵好贵的。
四、确认反馈较多需求的真实覆盖面
将此需求向忠实用户进行求证，通过在线调查问卷、KOL群体、微信、QQ、需求反馈有奖活动等多渠道进行确认，看是否能得到抽样调查查过50%以上用户的认可。超过了可进入排期考虑优先级和重要程度。没超过向后顺延，等待合适的阶段和时机。
五、清楚需求开发周期的长短和优先级
根据PRD设计好产品原型后，和业务开产品讨论会确认，清楚知道业务方向对各个功能模块的重视程度和用户体验效果。接下来再和技术开技术讨论会确认，清楚知道技术对产品原型的认可度，包括功能实现的价值和必要性，从而估算开发周期，必要时候也需要为了在规定时间内完成工期，对一些小功能进行分版本迭代。
六、清楚需求在产品当下阶段的重要性
PM是要清晰产品在当下阶段对应的业务拓展是什么，以此来判断哪些功能是加班加点也要必须上的，补上就是不完整，有残缺；哪些功能是可以后期迭代的，来协助业务进一步拓展的。避免紧要功能没及时跟上，导致业务受到影响，那就该背锅了。所以产品也要及时与一线团队保持沟通畅快。确保团队整体队伍的一致性步伐。
七、用户愿意为之付费的需求可多考量
此处为老板和盈利设计~只要开发方向对头，开发周期不离谱，均可考虑尝试。
总结：耳根子不要软，脑袋不要懒，眼见的少不一定为实，耳听的多不一定为虚。多听用户声音，多从用户中取材，才能得出靠谱的判断。
