接到了來自業務部的需求反饋，要求馬上實現才能簽單客戶，實現後發現並沒有其他用戶感興趣。。。
接到了來自某KOL用戶的需求反饋，優化後發現並沒有多少用戶認可。。。
是不是。。。好尷尬啊。。。
是的。這就是我們經常在產品上線後，優化產品的過程中，獲取需求反饋的判斷中，遇到不少的僞需求現象。導致迭代無休止、
技術團隊對產品需求真實性的質疑和排斥。因爲他們是能清楚看到自己研發的功能有多少用戶在使用。
曾經就有技術負責人在我做運營時（那時公司沒有PM）去提某個功能需求的時候，問：“你能保證你提的需求我們做出來後就能盈利麼？”“只要你保證，我們在公司打地鋪，通宵加班研發都沒問題”，於是又尷尬了，答案很簡單：“保證不了”。
我相信上面類似的情況在各家公司仍不少出現，很難避免。通常需要PM在蒐集需求-整理需求-瞭解需求的過程中，最大可能地去判斷需求的真僞。那麼如何從排着隊的來自四面八方的需求反饋中區分真正的用戶需求和僞需求呢？
一、清楚需求來源
一個需求提報上來，你需要清楚是誰提報的，這個人在產品中扮演什麼角色，使用產品多久了，在什麼情況下提出這個需求，想解決TA的什麼問題，然後就是基本的信息，包括性別、年齡、所在省份、城市、職業、興趣愛好，能提取到的信息儘量提取記錄，相當於需求提報人的簡易畫像，也方便用作未來需求提報的透視分析。因爲每個人都有自己獨特的需求出發點，你覺得無關緊要，TA覺得沒了活不了。就如同你在底層仰望，TA在樓頂俯瞰。
最好通過EXCEL表來做需求的記錄，並形成數據公式。相比於常用的word撰寫PRD，其實在實踐過程中，我更傾向用excel，處理較多數據時更加靈活可控。
二、瞭解同一需求的反饋量
辨別真僞需求一定是不能想當然的。沒有數據的支撐和分析，很難有靠譜的理由來確認真僞。所以多少用戶反饋了這一需求，是同類用戶，還是不同類用戶，反饋數量整體反饋中佔比多少，都是些什麼類型的用戶反饋的這個需求。這能估算出這個需求是否具有代表性和普遍性。如果數量不足或者需求不確定的功能需求（可能影響工期），也可附以抽樣調研，通常數據可通過運營人員，從運維的忠實用戶羣中隨機篩選100左右。
三、清楚需求的屬性
是細節優化類、還是功能迭代類，是強需還是弱需。細節優化類的需要十幾分鍾或幾個小時就能搞定的順手也就做了，哪怕只是錦上添花都可接受。涉及功能迭代的影響用戶使用習慣的需求，尤其是即將耗費超過一週的研發週期的需求，就要仔細考量了。這就需要我們不斷地整理需求，配置優先級和重要性。不要讓有限的技術力量浪費在無限需求的開發週期上，畢竟如今的技術好貴好貴的。
四、確認反饋較多需求的真實覆蓋面
將此需求向忠實用戶進行求證，通過在線調查問卷、KOL羣體、微信、QQ、需求反饋有獎活動等多渠道進行確認，看是否能得到抽樣調查查過50%以上用戶的認可。超過了可進入排期考慮優先級和重要程度。沒超過向後順延，等待合適的階段和時機。
五、清楚需求開發週期的長短和優先級
根據PRD設計好產品原型後，和業務開產品討論會確認，清楚知道業務方向對各個功能模塊的重視程度和用戶體驗效果。接下來再和技術開技術討論會確認，清楚知道技術對產品原型的認可度，包括功能實現的價值和必要性，從而估算開發週期，必要時候也需要爲了在規定時間內完成工期，對一些小功能進行分版本迭代。
六、清楚需求在產品當下階段的重要性
PM是要清晰產品在當下階段對應的業務拓展是什麼，以此來判斷哪些功能是加班加點也要必須上的，補上就是不完整，有殘缺；哪些功能是可以後期迭代的，來協助業務進一步拓展的。避免緊要功能沒及時跟上，導致業務受到影響，那就該背鍋了。所以產品也要及時與一線團隊保持溝通暢快。確保團隊整體隊伍的一致性步伐。
七、用戶願意爲之付費的需求可多考量
此處爲老闆和盈利設計~只要開發方向對頭，開發週期不離譜，均可考慮嘗試。
總結：耳根子不要軟，腦袋不要懶，眼見的少不一定爲實，耳聽的多不一定爲虛。多聽用戶聲音，多從用戶中取材，才能得出靠譜的判斷。
