需求分析可以說(shuō)是產(chǎn)品經(jīng)理最常見(jiàn)的工作之一了，無(wú)論是新產(chǎn)品的上線還是產(chǎn)品迭代都離不開(kāi)需求分析。需求分析決定著產(chǎn)品的研發(fā)和迭代方向，一旦出現(xiàn)偏差就會(huì)和用戶的真實(shí)需要背道而馳，因此掌握正確的需求分析方法論也就特別重要。作者就需求收集到需求落地過(guò)程中，應(yīng)當(dāng)如何完成需求分析才能夠更全面展開(kāi)分析，一起來(lái)看看。

什么是需求呢，用最簡(jiǎn)潔描述其實(shí)就是用戶在一定場(chǎng)景下尚未解決的需要。用戶，場(chǎng)景和需求內(nèi)容三者缺一不可。從開(kāi)始的用戶需求到最后的產(chǎn)品需求，背后有一個(gè)需求分析的過(guò)程。

不同的產(chǎn)品經(jīng)理所采用的需求分析方法和流程并不完全一致，段位越高的產(chǎn)品經(jīng)理分析流程可能越簡(jiǎn)約。但基本的宗旨都是一致的，那就是發(fā)現(xiàn)用戶最本質(zhì)的需要，進(jìn)而提供相應(yīng)的產(chǎn)品功能去滿足它，為用戶創(chuàng)造價(jià)值。

本文嘗試歸納一種普遍性的需求分析流程，可以快速地運(yùn)用到工作中去。

一、需求來(lái)自哪

在需求分析前，需要先了解我們接收得到的需求一般來(lái)自哪。按照主動(dòng)性劃分，需求可以分為被動(dòng)來(lái)源和主動(dòng)來(lái)源。

被動(dòng)來(lái)源就是來(lái)自于老板，用戶以及運(yùn)營(yíng)等產(chǎn)品相關(guān)崗位的反饋。

主動(dòng)來(lái)源的渠道就很多了，主要包括定期的用戶訪談、運(yùn)營(yíng)數(shù)據(jù)分析、競(jìng)品動(dòng)態(tài)追蹤、內(nèi)部會(huì)議研討等。

不管是來(lái)自于哪種渠道的需求，都要將其沉淀到需求池中，并進(jìn)行需求分析。

因?yàn)楣ぷ髑榫爸械男枨蟠蟛糠謥?lái)自于用戶，因此本文也主要以用戶需求分析為主，其中部分內(nèi)容同樣適用于其他需求來(lái)源主體。

二、需求分析方法論

1. 需求是什么

需求是什么，也就是用戶對(duì)需求的描述。這里有兩點(diǎn)需要注意，一是要收集來(lái)自于用戶的客觀需求，所謂客觀，就是產(chǎn)品經(jīng)理不能引導(dǎo)用戶說(shuō)出自己的需求。

第二就是確保需求描述的完整性，這種需求發(fā)生在什么場(chǎng)景，用戶的具體需要是什么。需求一定是和場(chǎng)景結(jié)合的，脫離了具體場(chǎng)景的需求也就喪失了其價(jià)值。

2. 為什么會(huì)產(chǎn)生這種需求

在接收了用戶需求具體內(nèi)容之后，產(chǎn)品經(jīng)理需要分析為什么會(huì)產(chǎn)生這種需求。了解了原因之后，其實(shí)也就為下一步的產(chǎn)品研發(fā)或迭代指明了方向。

但就是這一步其實(shí)對(duì)產(chǎn)品經(jīng)理的定性能力要求很高?！坝脩粜枰氖瞧?chē)，而不是一匹更快的馬?！备Ｌ匕l(fā)明汽車(chē)的故事相信大家都已耳熟能詳。在與用戶的交流中，想要洞察用戶表面需求背后的底層動(dòng)機(jī)并不容易。

最容易想到的角度就是馬斯洛需求層次理論，可以從這個(gè)角度來(lái)思考用戶提出的需求是否契合其中一點(diǎn)。馬斯洛把需求從低層次到高層次分別為七個(gè)層次：生理需求、安全需求、歸屬與愛(ài)的需求、尊重需求、認(rèn)知需求、美學(xué)需求、自我實(shí)現(xiàn)的需求。例如用戶希望自己的抖音賬戶可以設(shè)定為私密賬戶，其實(shí)就是為了滿足安全需要。

除了最底層的需求層次理論以外，也可以思考該需求能滿足用戶什么欲望，例如被激勵(lì)，收集控，強(qiáng)迫癥，利益相關(guān)，新鮮感等等。例如用戶希望app可以有成長(zhǎng)體系，就是滿足自己的被激勵(lì)需要。

一款好的產(chǎn)品是一定能夠滿足人性或者是欲望的。

第二可以從角色—場(chǎng)景—路徑的角度來(lái)分析，用戶的同樣的需求，換個(gè)用戶是否存在，換個(gè)場(chǎng)景是否成立，改變使用路徑是否存在？如果是，那么這個(gè)需求就是用戶、場(chǎng)景或者是路徑?jīng)Q定的需求。例如各大app出現(xiàn)的老年人模式，各種音樂(lè)app出現(xiàn)的車(chē)載模式，根據(jù)查詢單號(hào)自動(dòng)帶出對(duì)應(yīng)的快遞公司等。

第三可以從更為宏觀的系統(tǒng)運(yùn)行的角度來(lái)思考，用戶的需求是否是為了提升效率，節(jié)約時(shí)間，促進(jìn)系統(tǒng)生態(tài)的完善，或者是解決當(dāng)前用戶使用階段/業(yè)務(wù)階段出現(xiàn)的問(wèn)題等（這里需要思考僅靠產(chǎn)品能否解決問(wèn)題）。

例如用戶說(shuō)它需要更快的馬車(chē)，背后實(shí)際上是對(duì)效率的渴求，網(wǎng)易云音樂(lè)推出評(píng)論的功能，除了滿足用戶的自我呈現(xiàn)需要，從系統(tǒng)生態(tài)的角度來(lái)看，信息接受和信息傳播一同才能構(gòu)成完整閉環(huán)，否則用戶只聽(tīng)到經(jīng)典的音樂(lè)而感慨萬(wàn)千，卻無(wú)處釋?xiě)选?/p>

總而言之，在傾聽(tīng)了用戶的需求之后，需要從多個(gè)角度洞悉用戶需求背后的深層次原因，這樣才能讓產(chǎn)品準(zhǔn)確解決用戶痛點(diǎn)。

3. 需求做不做

收集了需求，也弄清了需求的背景和原因，那么這個(gè)需求到底要不要做呢？

這需要從多個(gè)層面來(lái)考量：

（1）用戶層面

首先要思考的是這個(gè)需求解決了用戶哪些痛點(diǎn)？這個(gè)需求是否具有高頻性，是否是強(qiáng)需求？例如每天都要吃飯，這是強(qiáng)需求，每天都要刷2次牙，這是高頻需求。如果用戶提了一個(gè)需求，既不高頻，又不屬于強(qiáng)需求，就要考慮到底要不要上線該需求。

再則是從用戶體驗(yàn)的角度，這個(gè)功能實(shí)現(xiàn)前后用戶的使用路徑會(huì)發(fā)生改變嗎，這個(gè)需求會(huì)犧牲用戶體驗(yàn)嗎，如果是以犧牲用戶體驗(yàn)為代價(jià)的需求，也需要權(quán)衡。

最后是思考它是不是個(gè)“偽需求”?！皞涡枨蟆本褪呛袈曌顬閺?qiáng)烈，但上線發(fā)現(xiàn)其實(shí)并沒(méi)有什么人用，效果并不理想的需求。之所以會(huì)產(chǎn)生這樣的現(xiàn)象是因?yàn)?，互?lián)網(wǎng)時(shí)代聲音由“沉默”轉(zhuǎn)向了“沉沒(méi)”，很多用戶的聲音我們其實(shí)并沒(méi)聽(tīng)到，表面上很大的聲浪遠(yuǎn)不能代表大部分人的想法或者需要。要避免“偽需求”，需要做細(xì)致的用戶調(diào)研。

（2）產(chǎn)品層面

先定位開(kāi)始說(shuō)起。產(chǎn)品經(jīng)理應(yīng)該始終明晰自己產(chǎn)品的定位所在，一切需求都要的服務(wù)于產(chǎn)品的當(dāng)前定位。例如你不能因?yàn)樗緳C(jī)在等紅燈時(shí)無(wú)聊，就要求滴滴打車(chē)上線游戲功能。

這里需要注意的是，有的需求可能符合產(chǎn)品定位，但不是產(chǎn)品當(dāng)前階段要做的事情，也需要排除。例如在產(chǎn)品冷啟動(dòng)階段，應(yīng)該聚焦于核心使用路徑與核心需求，其他需求即使合理，但也不是當(dāng)前階段應(yīng)該做的。

其次要考慮的是，現(xiàn)有產(chǎn)品功能是不是從側(cè)面也可以滿足用戶所提出的需求。例如很多人呼喚微信語(yǔ)音進(jìn)度條，但是微信的語(yǔ)音轉(zhuǎn)文字方案，在大多數(shù)場(chǎng)景下其實(shí)從側(cè)面就能替代語(yǔ)音進(jìn)度條。

最后還要從整體的角度思考新需求是否會(huì)影響產(chǎn)品設(shè)計(jì)語(yǔ)言。例如淘寶上線直播的功能，這就需要從設(shè)計(jì)語(yǔ)言的角度對(duì)產(chǎn)品進(jìn)行重構(gòu)。因?yàn)橹辈ナ莻€(gè)大風(fēng)口，所以這樣的需求不得不做。但是其他的需求如果影響整體設(shè)計(jì)語(yǔ)言，勢(shì)必也要仔細(xì)思考一番。

（3）商業(yè)化層面

商業(yè)化層面主要需要考慮市場(chǎng)規(guī)模，商業(yè)模式和成本預(yù)算方面的問(wèn)題。小的功能性需求其實(shí)并不需要考慮市場(chǎng)規(guī)模和商業(yè)模式這樣長(zhǎng)遠(yuǎn)的問(wèn)題。但是一個(gè)大的功能上線，就要考慮到它的引流效果，可能帶來(lái)的盈利增長(zhǎng)點(diǎn)。例如抖音在其app中上線“抖音商城”，這是一個(gè)非常大的動(dòng)作，必然要考慮到市場(chǎng)規(guī)模，商業(yè)模式這些問(wèn)題，正是電商市場(chǎng)空間遠(yuǎn)未飽和，所以字節(jié)才開(kāi)始布局。

無(wú)論是什么需求都需要考慮成本預(yù)算。這里的成本分為研發(fā)成本與非研發(fā)成本。研發(fā)成本很好理解，非研發(fā)成本主要包括用戶教育成本，內(nèi)容是否需要人工審核，以及各種運(yùn)營(yíng)推廣成本等，非研發(fā)成本其實(shí)就是如何讓用戶喜歡上這個(gè)功能的成本。王堅(jiān)老師在《結(jié)網(wǎng)》一書(shū)中有提到，一般而言可以按照研發(fā)成本占20%，非研發(fā)成本占80%進(jìn)行測(cè)算。

（4）內(nèi)外部資源情況

巧婦難為無(wú)米之炊。需求做不做有時(shí)候也不是自己能決定的。

產(chǎn)品經(jīng)理針對(duì)當(dāng)前需求需要思考，哪些核心資源是已經(jīng)具備的，哪些是欠缺的。如果當(dāng)前相關(guān)資源欠缺，需要外部的合作伙伴嗎，如何進(jìn)行協(xié)調(diào)溝通，這些都要思考全面。

拿到一個(gè)需求，放到上面這些維度進(jìn)行考量，可以解決大部分的需求做不做的判斷性問(wèn)題。但是有的時(shí)候，可能并不需要這么復(fù)雜，就一句話，老板要你做，你能不做嗎？

4. 需求做什么

如果把需求進(jìn)行劃分的話，無(wú)非就兩種，別人已經(jīng)做過(guò)的需求和別人沒(méi)有做過(guò)的需求。如果是做別人沒(méi)有做過(guò)的需求，我們直接進(jìn)行大刀闊斧的創(chuàng)新就可以了。但創(chuàng)新畢竟是少數(shù)，很多時(shí)候我們做過(guò)的東西別人早就有類(lèi)似的概念出來(lái)了。像微信這樣現(xiàn)象級(jí)的產(chǎn)品最初也是來(lái)自于Kik Messenger的產(chǎn)品概念。

有一句話講的特別好，不要重新發(fā)明輪子，因?yàn)闆](méi)有產(chǎn)生價(jià)值增值。那剩下的就是別人已經(jīng)做過(guò)的需求了。雖然別人已經(jīng)有了，那么我們也可以思考的是，能不能二次創(chuàng)造價(jià)值和放大價(jià)值？這才是關(guān)鍵。

可以的創(chuàng)新點(diǎn)有其實(shí)有很多，比如說(shuō)更新的體驗(yàn)，更新的技術(shù)，更好的商業(yè)模式，更適合的時(shí)機(jī)，更強(qiáng)大的平臺(tái)，更完善的管理。例如同是短視頻平臺(tái)的美拍和抖音，抖音賦予了用戶全新的體驗(yàn)，同時(shí)電商，有人To B，有人To C，有人To B2C，這就是商業(yè)模式的不同。

之前我就特別不理解，為什么新浪要打造一個(gè)酷似Instagram的綠洲？后來(lái)對(duì)比使用發(fā)現(xiàn)，綠洲確實(shí)更符合國(guó)人的社交媒體使用習(xí)慣，而且國(guó)內(nèi)缺乏圖片社交app，依托于微博平臺(tái)的強(qiáng)大引流，是很有前景的。也就是說(shuō)，綠洲的產(chǎn)品需求源自Instagram的概念，但是卻賦予了它很多的創(chuàng)新，這也未嘗不可。

此外，對(duì)于一些細(xì)小的功能性需求，比如說(shuō)腦洞大開(kāi)的微信消息置底功能，因?yàn)樗容^具象，就不太適合從更新的體驗(yàn)，更新的技術(shù)，更好的商業(yè)模式等角度來(lái)分析。這種情況可以借鑒HWM思考方法，它主要適用于頭腦風(fēng)暴前去尋找解決問(wèn)題的方向，擴(kuò)展我們的思路。 HWM思考方法主要包括否定，轉(zhuǎn)移，積極，腦洞，分解幾個(gè)部分。

就拿微信消息置底功能來(lái)說(shuō)，這個(gè)需求本質(zhì)是用戶需要保護(hù)隱私，從“轉(zhuǎn)移”角度來(lái)看，那可以出一個(gè)聊天框不顯示的功能，或者是聊天框自主排序的功能，就不需要了置底這么奇葩的功能了。從“腦洞”的角度來(lái)看，當(dāng)用戶頻繁刪除與一個(gè)人的聊天記錄時(shí)，下次退出聊天會(huì)主動(dòng)提示是否隱藏與該用戶聊天記錄，或者推出閱后即焚的功能等等。

5. 需求怎么做

（1）優(yōu)先級(jí)排序

在工作場(chǎng)景中，同時(shí)會(huì)有許多需求需要做，這時(shí)候就需要對(duì)需求進(jìn)行優(yōu)先級(jí)排序。常見(jiàn)的方法有KANO模型，四象限法則和金字塔型劃分。

① KANO模型

在卡諾模型中，將產(chǎn)品功能/需求和服務(wù)的特性分為五種屬性：必備屬性、期望屬性、魅力屬性、無(wú)差異屬性、反向?qū)傩浴?/p>

魅力屬性：用戶意想不到的，如果不提供此需求，用戶滿意度不會(huì)降低，但當(dāng)提供此需求，用戶滿意度會(huì)有很大提升；

期望屬性：當(dāng)提供此需求，用戶滿意度會(huì)提升，當(dāng)不提供此需求，用戶滿意度會(huì)降低；

必備屬性：當(dāng)優(yōu)化此需求，用戶滿意度不會(huì)提升，當(dāng)不提供此需求，用戶滿意度會(huì)大幅降低；

無(wú)差異屬性：無(wú)論提供或不提供此需求，用戶滿意度都不會(huì)有改變，用戶根本不在意；

反向?qū)傩裕河脩舾径紱](méi)有此需求，提供后用戶滿意度反而會(huì)下降。

KANO模型需要進(jìn)行相應(yīng)的用戶調(diào)研，計(jì)算出相應(yīng)的better-worse系數(shù)值，以確立需求的優(yōu)先級(jí)。一般情況而言，在產(chǎn)品設(shè)計(jì)時(shí)，要盡量避免無(wú)差異屬性、反向?qū)傩?，著力抓住用戶的核心需求，解決用戶痛點(diǎn)，即基本型需求，在確?；拘枨蠼鉀Q的前提下，為用戶提供興奮點(diǎn)，即期望屬性與，魅力屬性。

② 四象限法則

四象限法則將需求等級(jí)劃分為：重要緊急，重要不緊急，不重要不緊急，不重要但緊急。

這里主要是涉及到兩個(gè)判斷標(biāo)準(zhǔn)，重要性和緊急性如何判斷。緊急性很容易，主要看時(shí)間寬度，離deadline很近，那就很緊急。重要性則有根據(jù)產(chǎn)品的不同規(guī)劃，依據(jù)實(shí)際工作場(chǎng)景確定，例如是否關(guān)乎核心功能使用，是否破壞了用戶體驗(yàn)，是否影響產(chǎn)品商業(yè)化等等。

對(duì)于第一象限的事情，需要盡快分配資源，抓緊完成。

第二象限的事情，需要花80%的時(shí)間在上面的，精細(xì)化處理好。如果不及時(shí)處理完，就堆積到第一象限。

第三象限和第四象限相對(duì)來(lái)說(shuō)是不重要的事情，但是它們也是需求，可以每天花費(fèi)一定的時(shí)間，統(tǒng)一去處理。要注意這類(lèi)需求要和第一第二象限的嚴(yán)格區(qū)分開(kāi)來(lái)，不能因?yàn)檫吘壢蝿?wù)影響主線任務(wù)進(jìn)展。

③ 金字塔型需求

金字塔型劃分需求，將需求從下到上劃分為四個(gè)模塊：可用性、更佳體驗(yàn)、可擴(kuò)展能力、生態(tài)。

其中可用性和更佳體驗(yàn)，是整個(gè)產(chǎn)品的最為基礎(chǔ)的部分，更高層的可擴(kuò)展能力，生態(tài)。都是在這基礎(chǔ)上建構(gòu)的。這種劃分非常清晰，產(chǎn)品經(jīng)理可以直接定位手頭需求屬于哪個(gè)層級(jí)，進(jìn)而進(jìn)行需求優(yōu)先級(jí)安排。

（2）關(guān)鍵任務(wù)安排

根據(jù)劃分出來(lái)的優(yōu)先級(jí)，產(chǎn)品經(jīng)理就要協(xié)調(diào)各方技術(shù)資源進(jìn)行關(guān)鍵任務(wù)分配了，產(chǎn)品，UI，研發(fā)，測(cè)試團(tuán)隊(duì)共同合作，完成需求上線，最終向用戶傳遞價(jià)值。當(dāng)然最主要的還是前面的需求分析的過(guò)程，到這里關(guān)鍵任務(wù)安排，很多產(chǎn)品經(jīng)理應(yīng)該都是輕車(chē)熟路，就不再贅述。

三、結(jié)語(yǔ)

我們梳理出了需求分析的一般流程，從用戶需求表達(dá)，需求背后原因追溯，需求要不要做，到需求做什么，以及怎么做。

但是在實(shí)際工作中可能并不需要思考這么多，或者這么多的流程可以放在一起進(jìn)行綜合考量，尤其是對(duì)于資深產(chǎn)品經(jīng)理來(lái)說(shuō)，有的時(shí)候需求分析不僅是理性的思辨，更閃耀著感性的靈光。

總而言之，要了解條條框框，但也不能被條條框框所限制。

作者：我的鞋子大了，微信公眾號(hào)：青芒產(chǎn)品筆記，定位于個(gè)人產(chǎn)品學(xué)習(xí)成長(zhǎng)平臺(tái)

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

題圖來(lái)自Unsplash，基于CC0協(xié)議