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