如何從排著隊(duì)的來自四面八方的需求反饋中區(qū)分真正的用戶需求和偽需求呢？

接到了來自業(yè)務(wù)部的需求反饋，要求馬上實(shí)現(xiàn)才能簽單客戶，實(shí)現(xiàn)后發(fā)現(xiàn)并沒有其他用戶感興趣。。。

接到了來自某KOL用戶的需求反饋，優(yōu)化后發(fā)現(xiàn)并沒有多少用戶認(rèn)可。。。

是不是。。。好尷尬啊。。。

是的。這就是我們經(jīng)常在產(chǎn)品上線后，優(yōu)化產(chǎn)品的過程中，獲取需求反饋的判斷中，遇到不少的偽需求現(xiàn)象。導(dǎo)致迭代無休止、技術(shù)團(tuán)隊(duì)對(duì)產(chǎn)品需求真實(shí)性的質(zhì)疑和排斥。因?yàn)樗麄兪悄芮宄吹阶约貉邪l(fā)的功能有多少用戶在使用。

曾經(jīng)就有技術(shù)負(fù)責(zé)人在我做運(yùn)營時(shí)（那時(shí)公司沒有PM）去提某個(gè)功能需求的時(shí)候，問：“你能保證你提的需求我們做出來后就能盈利么？”“只要你保證，我們?cè)诠敬虻劁仯ㄏ影嘌邪l(fā)都沒問題”，于是又尷尬了，答案很簡(jiǎn)單：“保證不了”。

我相信上面類似的情況在各家公司仍不少出現(xiàn)，很難避免。通常需要PM在搜集需求-整理需求-了解需求的過程中，最大可能地去判斷需求的真?zhèn)?。那么如何從排著?duì)的來自四面八方的需求反饋中區(qū)分真正的用戶需求和偽需求呢？

一、清楚需求來源

一個(gè)需求提報(bào)上來，你需要清楚是誰提報(bào)的，這個(gè)人在產(chǎn)品中扮演什么角色，使用產(chǎn)品多久了，在什么情況下提出這個(gè)需求，想解決TA的什么問題，然后就是基本的信息，包括性別、年齡、所在省份、城市、職業(yè)、興趣愛好，能提取到的信息盡量提取記錄，相當(dāng)于需求提報(bào)人的簡(jiǎn)易畫像，也方便用作未來需求提報(bào)的透視分析。因?yàn)槊總€(gè)人都有自己獨(dú)特的需求出發(fā)點(diǎn)，你覺得無關(guān)緊要，TA覺得沒了活不了。就如同你在底層仰望，TA在樓頂俯瞰。

最好通過EXCEL表來做需求的記錄，并形成數(shù)據(jù)公式。相比于常用的word撰寫PRD，其實(shí)在實(shí)踐過程中，我更傾向用excel，處理較多數(shù)據(jù)時(shí)更加靈活可控。

二、了解同一需求的反饋量

辨別真?zhèn)涡枨笠欢ㄊ遣荒芟氘?dāng)然的。沒有數(shù)據(jù)的支撐和分析，很難有靠譜的理由來確認(rèn)真?zhèn)?。所以多少用戶反饋了這一需求，是同類用戶，還是不同類用戶，反饋數(shù)量整體反饋中占比多少，都是些什么類型的用戶反饋的這個(gè)需求。這能估算出這個(gè)需求是否具有代表性和普遍性。如果數(shù)量不足或者需求不確定的功能需求（可能影響工期），也可附以抽樣調(diào)研，通常數(shù)據(jù)可通過運(yùn)營人員，從運(yùn)維的忠實(shí)用戶群中隨機(jī)篩選100左右。

三、清楚需求的屬性

是細(xì)節(jié)優(yōu)化類、還是功能迭代類，是強(qiáng)需還是弱需。細(xì)節(jié)優(yōu)化類的需要十幾分鐘或幾個(gè)小時(shí)就能搞定的順手也就做了，哪怕只是錦上添花都可接受。涉及功能迭代的影響用戶使用習(xí)慣的需求，尤其是即將耗費(fèi)超過一周的研發(fā)周期的需求，就要仔細(xì)考量了。這就需要我們不斷地整理需求，配置優(yōu)先級(jí)和重要性。不要讓有限的技術(shù)力量浪費(fèi)在無限需求的開發(fā)周期上，畢竟如今的技術(shù)好貴好貴的。

四、確認(rèn)反饋較多需求的真實(shí)覆蓋面

將此需求向忠實(shí)用戶進(jìn)行求證，通過在線調(diào)查問卷、KOL群體、微信、QQ、需求反饋有獎(jiǎng)活動(dòng)等多渠道進(jìn)行確認(rèn)，看是否能得到抽樣調(diào)查查過50%以上用戶的認(rèn)可。超過了可進(jìn)入排期考慮優(yōu)先級(jí)和重要程度。沒超過向后順延，等待合適的階段和時(shí)機(jī)。

五、清楚需求開發(fā)周期的長短和優(yōu)先級(jí)

根據(jù)PRD設(shè)計(jì)好產(chǎn)品原型后，和業(yè)務(wù)開產(chǎn)品討論會(huì)確認(rèn)，清楚知道業(yè)務(wù)方向?qū)Ω鱾€(gè)功能模塊的重視程度和用戶體驗(yàn)效果。接下來再和技術(shù)開技術(shù)討論會(huì)確認(rèn)，清楚知道技術(shù)對(duì)產(chǎn)品原型的認(rèn)可度，包括功能實(shí)現(xiàn)的價(jià)值和必要性，從而估算開發(fā)周期，必要時(shí)候也需要為了在規(guī)定時(shí)間內(nèi)完成工期，對(duì)一些小功能進(jìn)行分版本迭代。

六、清楚需求在產(chǎn)品當(dāng)下階段的重要性

PM是要清晰產(chǎn)品在當(dāng)下階段對(duì)應(yīng)的業(yè)務(wù)拓展是什么，以此來判斷哪些功能是加班加點(diǎn)也要必須上的，補(bǔ)上就是不完整，有殘缺；哪些功能是可以后期迭代的，來協(xié)助業(yè)務(wù)進(jìn)一步拓展的。避免緊要功能沒及時(shí)跟上，導(dǎo)致業(yè)務(wù)受到影響，那就該背鍋了。所以產(chǎn)品也要及時(shí)與一線團(tuán)隊(duì)保持溝通暢快。確保團(tuán)隊(duì)整體隊(duì)伍的一致性步伐。

七、用戶愿意為之付費(fèi)的需求可多考量

此處為老板和盈利設(shè)計(jì)~只要開發(fā)方向?qū)︻^，開發(fā)周期不離譜，均可考慮嘗試。

總結(jié)：耳根子不要軟，腦袋不要懶，眼見的少不一定為實(shí)，耳聽的多不一定為虛。多聽用戶聲音，多從用戶中取材，才能得出靠譜的判斷。

#專欄作家#

晨曦 ?昵稱：格格。人人都是產(chǎn)品經(jīng)理專欄作家。7年互聯(lián)網(wǎng)產(chǎn)品運(yùn)營管理經(jīng)驗(yàn)。擅長統(tǒng)籌管理、SEM、內(nèi)容運(yùn)營。某垂直項(xiàng)目聯(lián)合創(chuàng)始人。獨(dú)立接手過5個(gè)B2C互聯(lián)網(wǎng)項(xiàng)目（其中社交類2個(gè)、內(nèi)容資訊類1個(gè)、電商類2個(gè)）的運(yùn)營管理以及1個(gè)B2B項(xiàng)目的市場(chǎng)拓展項(xiàng)目。目前從過往的主導(dǎo)運(yùn)營策劃和市場(chǎng)拓展工作到主導(dǎo)產(chǎn)品設(shè)計(jì)和運(yùn)營工作。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自u(píng)nsplash，基于CC0協(xié)議