對于產品經理而言，“需求”這個詞并不陌生，聊到產品設計要談到需求，聊到功能開發要談到需求，聊到用戶畫像要談到需求等等。產品經理所設計的產品被視為連接企業與用戶（也包括客戶，為便于理解，統一稱為用戶）的媒介，連接的關鍵點就在于用戶需求的滿足程度和先后順序，因此產品經理需要具備針對需求的洞悉和管理能力。

一、需求定義

1. 基本定義

需求是指由需要而產生的要求，更底層的來源是人的欲望。比如因生存的需要，而產生溫飽需求；因精神共鳴的需要，而產生社交需求；因想擁有愉悅的情緒，而產生聽音樂的需求；因想舒適出行，而有打專車而非坐地鐵的需求等等。

需求無處不在，貫穿于我們的工作、生活每一個具體的場景當中。其實仔細想想，我們日常的每一個決策、動作，都是基于需求在背后的推動，只不過對于那些可以快速決策和反應的行為，有時我們自己都感知不到，而那些需要耗費腦力、精力和時間的行為，我們才會有清晰的感知。這就涉及到人類大腦的“系統1”和“系統2”，本篇文章不做詳解，感興趣的話可以翻閱丹尼爾·卡尼曼的著作《思考·快與慢》。

2. 需求的合理性

從用戶，即需求產生者的角度出發，需求永遠是合理的。在沒有外力的脅迫下，每個用戶提出的需求都是基于自身主觀效用最大化而產生估的。

即使作為一名產品經理，基于一些理性的成本和收益分析，認為用戶提出的需求是不合理的，也不能改變用戶站在其自身角度出發，所認為的該需求是合理的認知。

反過來思考，產品經理認為用戶的需求“不合理”，也是產品經理把自己與其背后的企業放在一起，從未來的成本、收益出發才有的判斷，這本身也帶有主觀偏向性。因為產品經理有自己的需求：為企業發展帶來效益、為產品規劃更好的未來的需求。

我們常說產品經理需要有同理心，其實說的是產品經理需要學會與用戶“共情”，讓自己站在用戶所提出需求的具體場景去思考用戶所表達需求背后的真實原因，而且要去感受用表達訴求時的情緒反饋。我現在在做B端產品，銀行客戶是我們產品的目標客戶群之一，有時跟同事聊到產品的穩定性就經常會提到一個場景：試想一名柜臺工作人員正在幫助客戶辦理取錢業務，但是用我們的產品時卻總在關鍵時刻卡頓影響業務的正常辦理，而客戶又急需用錢。若你是這位柜臺工作人員，你會如何評價你所使用的產品呢？當你接收產品廠商的調研時，你會給與什么樣的反饋呢？

雖然每個人的成長經歷、生活環境、認知水平都會有所不同，產品經理難以對每個用戶反饋的具體需求都做到感同身受，但是對于那些自己認為不合理的需求，其實更應該花時間去了解和挖掘用戶提出該需求的更深層次原因，這種方式也很有可能會給產品的發展方向帶來意外收獲。

3. 需求的差異性

用戶其實并非就是自然人，更確切的說，應該是需求的集合，只不過當前所討論的產品大多數都是為自然人而設計的，因此習慣性的將用戶理解為自然人。但其實我們也有很多產品是為其他生物設計的，比如為貓狗專門設計的飲食器等。

自然人本身具有異質性的特點。

因此，針對同一類需求，不同的用戶之間也會存在差異。同樣都是通過飲食來滿足溫飽的需求，但有的人偏向于辛辣口味，而有的人偏向于酸甜口味。

放在互聯網產品中亦如此，比如音樂類的產品是滿足用戶的聽歌訴求，但不同的用戶對于聽歌的音效喜好是不同的，有的喜歡 live 場景，有的喜歡音樂會場景，還有的喜歡寬廣環繞等。

對于產品發展來說，基于需求滿足的用戶量覆蓋來考慮，要優先洞察用戶的共性需求，這類共性需求是保證更多的用戶使用產品的基礎，可以為產品帶來可用性價值。當產品逐步趨于成熟，用戶量足以支撐為滿足個性化需求所投入的成本時，再做共性功能的拓展或其他個性化需求的補全。

用戶作為自然人而存在，需求產生的背景是多種多樣的，因此用戶提出的需求并非是都可以實現的，完全滿足所有用戶的所有需求的產品也是不存在的。

4. 需求的周期性

如果以時間為維度，一年可分為四季、12 個月、365天，一天可分為 24 小時。用戶在不同的時間所需要滿足的需求是不相同的，就像對于衣服購買的需求，也會有旺淡季一樣。對于各類產品而言，本質上也是在提供服務，這種服務只是區別了傳統交付形式，但目的仍是滿足用戶的訴求。

簡單舉例，以天為單位時，用戶對于消磨碎片化時間的需求大概率會集中在 8:00-9:00、18:00-19:00 之間，其他時間可能忙于工作、陪伴家人、運動健身等。此時，如果去觀測產品的數據統計情況，日活躍度的時段分布也是有明顯特征的。將時間周期放大到月、季度、年，也是一樣的道理。再例如一款戶外產品，在周末的平均活躍度高于工作日，在春秋季的活躍度高于夏冬季。

掌握這些時間規律，可以幫助產品經理更好地了解用戶使用產品時的各種狀態條件，包括用戶的內在心理狀態和外在物理環境，進而能更好地設計產品，以滿足用戶需求。

5. 需求的不可實現性

用戶需求千千萬，但真正可以被滿足的需求是極少數的。很多需求注定是無法被實現的，認識到這一點很重要，雖然聽起來似乎有點殘酷。因為需求是用戶欲望的一種表達方式，而欲望是無窮的。

對于產品經理而言，即使有著要滿足用戶所有需求的雄心壯志，也要認識到客觀現實對于用戶需求滿足的限制性。

滿足所有用戶的所有需求并不是產品唯一的成功方式或檢驗標準，選擇滿足大多數用戶在更常見場景下的基本需求，且提供良好的產品體驗，為用戶帶去主觀效用的最大化，才是需要重點考慮的。一步步地去了解你的用戶，帶領你的前進，適當舍棄那些在當前條件下不可實現或低價值的需求。有些需求也許當前不具備可實現性，但隨著條件的改變（如新技術的出現、國家政策調整等），會讓那些過往不可能實現的需求成為可能。

認識到需求不可實現性的客觀現實并不是讓我們妥協，而是為了讓自己具備更理性的決策思維。

以上都是關于需求的一些基本特點介紹，了解需求的特點并接受其實并不是一件容易的事情，因為這些特點看起來像是在給產品經理的工作制造麻煩：有些特點讓產品工作無規律可循，有些特點感覺又讓產品落地受到限制。

但是這也是產品經理工作的樂趣之一，于眾多內在和外在因素之下，不停摸索需求滿足的最優解，為用戶、為企業、為團隊、為自己帶來正反饋的平衡決策，是產品經理的價值體現所在。

二、需求收集

了解了需求的特點之后，再來聊一聊需求的來源，需求的來源有很多，比如用戶反饋的需求、運營部門的需求、研發部門的需求、領導的需求、競品分析梳理的需求、也有產品經理自身認知所產生的需求等等，重點聊一聊用戶反饋、上層領導和自我認知所產生的需求。

1. 用戶反饋

產品因為用戶愿意為其需求得到滿足，而付出對應的成本（金錢、時間、精力等）而存在，所以某種程度上可以說用戶就是產品的“衣食父母”。無論是各種互聯網產品，還是電影、脫口秀、音樂、飲食等傳統服務，在交易模型上都是類似的，因此產品或服務的價值也就體現在滿足用戶的需求上。

用戶在使用產品的過程中，都會帶有自己的心智體驗感受，這種感受會轉化為情緒體驗，如滿意、一般、不滿意等。在不同的情緒體驗上，用戶會有不同的反饋。以使用APP 為例，滿意時，用戶可能會提高產品使用時長、購買增值服務等；覺得一般時，用戶可能會反饋一些期望增加的功能；不滿時，用戶可能會立刻卸載 APP，甚至還會去應用商店上給一個低評分。

對于用戶反饋要增加的功能，只是其需求得到滿足的一種外在表現形式，因此產品經理需要謹慎評審，更多的挖掘用戶期望增加的功能背后所隱藏的底層需求，一個高質量的用戶反饋是產品經理難得一遇的“寶藏”。

2. 上層領導

每個企業或團隊中都有不同的崗位和角色分工。在對行業認知洞察以及產品方向規劃上，上層領導往往可以給出相對更準確的決策結論，至少是全局條件下綜合考慮更合適的，這是由領導層在行業信息掌握程度和認知程度決定的。

只不過上層領導所提供的需求往往是比較寬泛的一種想法、理念或目標，還需要產品經理將這些想法具象化，進而推動落地。

例如針對當前產品現狀和目標，梳理出產品的發展路線圖，根據討論確認的路線圖再進行產品的概念設計、詳細設計等，直到最終可以轉化為研發、測試、設計等同事進行工作的產出物。需要注意的是，產品經理在進行產品具體規劃的同時，還要考慮產品的運營、市場推廣、售后等所有涉及產品上線交付的全鏈條工作。

這是對產品經理全局視野的要求和培養，坊間流傳“產品經理是CEO的學前班”，也是不無道理的。

3. 自我認知

基于自我認知而挖掘或規劃需求是最難的一點，因為需要產品經理長期投入對于產品和行業的學習成本，且多做項目和總結復盤積累，還需要個人對產品的熱愛，投入激情，最終形成行業的產品認知體系，包括但不限于對行業的認知、對產品專業能力的認知、對成本收益評估的認知、對用戶需求的認知等等。

從職場發展來說，自我認知的高低也是產品經理的核心競爭力之一。

當自我認知成體系形成后，便可以引導產品的發展規劃，也可以幫助用戶去發現他們自己都未發現的需求，進而讓產品贏在起點上。當然，除了上述需求來源，前面提到還有來自公司運營、市場、研發等部門的內在需求，也有來自對齊外在競品的需求等。至于何種需求才是具有生命力的，那就需要每個產品經理基于公司和產品現狀和未來規劃做綜合考慮，需求本身的業務價值、投入的成本、收益反饋周期等，也都是需要考慮的因素。

需求是用戶與產品的連接點，對于需求的挖掘、分析、規劃都可能直接影響到企業在市場競爭中的地位。

在了解了需求的基本特點和收集之后，接下來最重要的事情就是需求價值分析，進而通過需求優先級和研發資源情況來進行產品迭代規劃。

4. 場景化分析

“無場景，不需求”，需求都是在具體場景下產生的，因為用戶生活在具體的場景當中。產品經理接收到需求反饋時，首先要做的就是明確需求所發生的場景。如果用一句話來需求，就是：什么人在什么場景下需要用到什么服務來滿足自己的什么訴求。

對于需求的場景化分析，最好的方法就是到用戶中去，例如對于外賣騎手來說，他們對于派單語音播報的音量大小習慣，是坐在辦公室中處于安靜思考狀態下的產品經理容易忽略的。

只有深入了解用戶工作或生活的環境、消費習慣、收入來源、社交關系等信息，才能更加精準地結合具體場景來分析需求價值，進而規劃產品方向。

5. 用戶故事地圖

用戶故事地圖是用戶在具體場景下為尋求需求的滿足，所發生的一系列行為動作的路徑。當我們想將收集到的新產品需求全部實現時，需要在史詩（通常是與特定結果密切相關的原始想法）層面進行多種實現，史詩是一個大的故事，在敏捷開發中稱之為“史詩故事”。對于史詩故事來說，實現的成本和交付時間都更長，對于團隊以及利益相關者來說并非是最佳的。此時，可以拆分成許多小故事，拆分故事的顆粒度，最終成為一個又一個具體場景下的用戶故事。

不過需要注意的是，用戶故事的衡量標準并非是將功能簡單拆分，合理的用戶故事應該具有封閉性、針對性、獨立性這三個特點。封閉性是指該用戶故事有獨立的交付價值；針對性是指該用戶故事只針對特定的用戶群，確保服務的目標用戶對象清晰，多用戶群的需求往往存在差異性；獨立性是指該用戶故事不與其他故事相互依賴，否則無法進行交付。

用戶故事地圖的重要作用就是讓用戶在具體場景下的需求變得更加清晰，也是最終產品交付時，用戶對于使用產品來解決具體場景下的需求更加清晰。

6. 最小可行產品

將用戶需求都納入到不同的用戶故事里，將大故事拆分成有價值的小故事進行獨立交付，也就是我們常說的 MVP 產品（最小可行性產品）。

其實MVP 產品不一定是通過軟件代碼開發出來的運行在各種設備上的軟件產品，可將視野擴展到其他行業當中，比如：在酒店行業，MVP產品可能是一套迎接客人的快捷服務流程；在餐飲行業，MVP產品可能是一套核心上菜流程等等。

MVP的目標是在早期階段驗證產品的核心假設，并獲得用戶反饋和市場驗證，以便進一步改進和迭代產品。既驗證需求的真實性，也驗證產品方案的滿足程度。

在激烈的市場競爭中，搶占時間就是搶占市場，考慮到投入成本和交付周期，企業為了后續決策的正確性，往往會選擇先通過推出一個 MVP 產品投入市場，然后觀測用戶使用數據和反饋，用以校準下一次的產品決策。

無論是領導下發的戰略性需求，還是用戶反饋的場景化需求，抑或是運營部提出的產品營銷活動類需求，都有其特有的價值，但是企業所擁有的資源是客觀稀缺的，無法滿足所有角色提出的所有需求。

產品經理的價值體現之一，就是在綜合所有因素之后，制定產品的迭代次序，在投入產出比上創造價值。

7. 需求分類

對于所面臨的眾多事項，人們通常會采用重要緊急四象限來進行劃分，以此來制定事項處理順序，更好地分配精力，確保綜合結果能達到自己預期。面對眾多紛繁復雜的需求，也可以采用同樣的方法進行歸類。經典的需求歸類模型是 KANO 模型，將需求劃分為：必備型需求、期望型需求、魅力型需求、無差異型需求、反向型需求，體現的是產品功能與用戶需求匹配度的一種關系。

簡單地理解，必備型需求就是提供滿足用戶剛需的產品功能，如果沒有此功能，用戶則會放棄該產品，這是產品初期最需要關注且投入資源去完成的工作。

期望型需求則是用戶有所期待的需求，當產品提供了滿足該類需求的功能，用戶對于產品的好感度會直線上升。但是產品即使沒有滿足該類型需求，在其他產品不具備同等功能之前，用戶一般也不會離開該產品。長期來說，這是提升產品持續競爭力的重要一環。

魅力型需求指的是用戶自身也沒考慮到，但是產品經理基于自己的認知等因素，挖掘出了用戶更本質的一些需求，并予以了滿足，讓用戶有一種“喜出望外”之感。用戶也會因此成為產品的忠實粉絲，并向其他非產品用戶推薦產品。無差異型需求指的是從用戶側來說，無論是否提供滿足該類型的需求，都不會影響用戶對于產品的使用和評價。開發此類需求，對于企業來說，是屬于資源浪費型投入。

反向型需求指的是違背用戶初始意愿，開發與用戶在各場景下的需求相反的功能，此行為最為不可取。

8. 需求等級

為了更好地將需求優先級予以體現，還需要一些量化方法對需求進行標記， 常見的如P級制、 百分制、MSCW、高中低等。

P 級制是將需求優先級從高到低為P0、P1、P2、P3、P4 級 別； 百 分 制 是 按 照 100、80、60、40、20 等進行劃分；MSCW 分別代表 must（必須做）、should（應該做）、could（可以做）、won’t（不會做）；高中低等則是最直觀地將需求分為高優先級需求、中優先級需求、低優先級需求。對于產品管理來說，采用何種方式進行劃分標記不是最重要的，而是同一個項目團隊里，對于所選取的等級劃分方法是明確且達成一致的。所有的工具方法本身都沒有意義，只有使用者對其的使用創造價值，才為其賦予了意義。學會優先級的劃分不僅適用于工作，同樣也適用于生活。每個人的資源、精力、時間都是有限的，要學會“把好鋼用在刀刃上”。

三、需求管理

收集需求、拆分需求都是前置工作，產品經理還需要一些管理工具或者說方法來讓收集到的需求為后續的工作服務。

1. 需求池

產品經理將所有收集整理的需求進行匯總歸類、劃分優先級之后，需要進行統一的維護管理，這就是總需求池?？傂枨蟪刂饕菫榱吮苊庑枨筮z漏，可以從全局上綜合評估所有需求的相對優先級，進而做出更正確的產品迭代內容決策。

同時，每個產品都有自己的生命周期，需求是可持續性的，因此對于每次規劃的產品迭代也需要單獨維護一個迭代需求池來管理。主要是作為此次產品迭代的需求范圍而存在，與技術、測試等團隊達成最終產品驗收的一致認知。

關于需求池的形式，可以用市面上的需求或項目管理工具來維護，也可以通過線上表格等工具來管理，重點是方便信息更新時可即時同步到團隊成員。

2. 產品方案

產品經理接收到需求之后，往往并不需要立刻開始做產品原型的設計。

所有的需求都是為了滿足用戶的需求而存在的，而用戶需求的滿足不一定是通過功能的開發，也許通過一些服務流的程改進也可以滿足。

用戶也可能會針對自己的需求，把自己放在產品經理的角度，提一些“建設性”的產品功能設計方案。就像之前張小龍說每天都有一億用戶在教他如何做產品一樣，這些用戶雖然有自己的具體的使用場景，但是缺少一種全局觀。同樣的，這些產品方案也許具有其參考性，但其參考的價值也是倒推到用戶為何有此需求，期望自己的何種欲望得到滿足。

而產品經理要做的是將用戶需求與產品現狀相結合，尋找其最合適的銜接點。

例如考慮用戶需求被滿足的功能設計時，還需要考慮該設計方案對于產品已有架構的調整程度，這就涉及到成本問題；可能還需要考慮功能上線后，如何做推廣運營，這就涉及到功能的盈利問題等。

綜合而全面的考慮用戶需求，進而提出合理的產品方案才是產品經理需要做的事情。

3. 產品需求文檔

一般來說，對于當前的互聯網產品來說，以界面型需求居多，例如通過觸摸屏點擊來實現交互，那就是涉及到界面的。

當然也有些不涉及到界面的，例如當前很多產品中的推薦算法、排序規則等，不過這些算法規則之后，也是通過界面展示給到用戶的。

對于界面型需求來說，產品經理往往需要輸出產品原型，也就是常說的產品需求文檔（PRD）。

對于開發、測試等同事來說，最忌會的就是來自產品經理的“一句話需求”。

一份優秀的產品需求文檔，應該是可以直接知道開發、測試的工作，而不需要他們來反復找產品經理做內容確認的。

4. 低保真

對于產品經理而言，用來與開發、測試、設計等人員進行需求評審的產品方案采用低保真原型（即線框圖）文檔即可，其優勢就是對于產品經理而言，可以快速將思考的產品方案具象化，進而與參與評審的同事快速對齊認知。

雖然低保真原型文檔不要求像高保真一樣的“養眼”，但是也需要注意最終呈現出來的效果，對于閱讀者（開發、測試、設計等）而言，降低他們的理解成本。

5. 產品需求文檔

首先，對于界面型（即用戶做操作之后，與原先頁面有差異之處的頁面）的需求都需要通過原型來表達。

因為由于每個人認知不同，如果不直觀地將所有界面繪制出來，便會出現“一千個讀者有一千個哈姆雷特”的情況，每個人所設想的都不同，到最終產品方案執行階段，便舉步維艱。

其次，專業的人做專業的事。

在設計低保真原型時，主題色采用黑白灰即可，目的就是不影響與產品經理配合的設計師進行產品高保真設計。

使用黑白灰進行低保真原型設計時，也要注意色彩盡量統一，若采用各式各樣的灰或者黑，最終的低保真原型呈現出來的效果也會不佳，建議每種顏色最多定義兩種，用于不同的頁面元素上即可。

再者，在產品方案設計時，還需要考慮頁面多狀態的情況，例如對于電商產品的訂單功能，需要考慮有訂單和無訂單的狀態；再比如對于增值服務，需要考慮用于購買了增值服務和未購買增值服務的情況等。由此產生的各種數據流轉情況，也要同步予以說明。

同時，還有一些“隱藏性”的需求，也是需要在產品方案中進行說明的。

例如存量數據的處理、排序規則的定義等，這些都是無法通過原型頁面直觀表達出來的內容，但是對于產品的最終上線效果，具有舉足輕重的意義。

另外，這部分需求與技術可行性相關，產品經理可適當尋求技術同學幫助，一起商討方案，確保最終產品方案可落地執行。

最后，也是非常重要的需求標注內容。

需求標注是對設計的產品原型的解釋說明，就相當于是開發、測試等同事在實際工作執行中時的“產品經理代言人”，承載著將產品原型對應的需求規則進行清晰明確的重任。

還有一些內容，如全局說明、背景介紹、交互釋義、展示規則等內容，也是需要與低保真原型文檔組合在一起，最終形成一份產品需求文檔，也就是常說的PRD。

6. 修訂記錄

由于認知偏差的客觀存在，產品經理最終用于需求評審的產品方案往往都不是最終稿，而需要進行修訂。

為了讓產品項目組與產品需求文檔相關的所有人員可以知曉每次修訂的內容，需要建立一個修訂記錄模塊，專門用于記錄產品經理對于此次產品方案的調整內容。

如此，便可以在項目組內保持信息的即時性。

團隊在認知一致的基礎下進行協作，對于工作效率、質量產出，以及團隊的工作效力、契合度都是具有重大意義的。

產品經理基于需求，與研發等同事做了初步討論，設計出產品方案之后，還需要組織項目組相關人員進行產品需求評審，進而推進下一步的產品研發工作。

需求評審的目標是對需求內容達成一致認知，從提升需求評審通過的角度來說，可以將需求評審分為三個階段進行，分別是：迭代價值、業務流程、產品需求，是一個從宏觀到微觀的過程。

7. 迭代價值

從工作流程上來說，研發、測試、設計等角色都是依托于上游的產品經理需求來推進工作的。某種意義上，產品經理的需求迭代規劃決定了他們的工作內容和強度。因此，若希望整個項目團隊中的成員可以有效的進行產品的開發迭代，首先要做的就是與團隊成員明確迭代價值，從宏觀愿景上達成一致認知。

常見的迭代價值如公司戰略規劃要求、用戶反饋的高頻需求、B端客戶反饋的高價值商業需求、數據分析得出的產品優化點、新技術要素催生的商業模式探索等。

將迭代價值與團隊成員做了明確，且得到認可之后，整個需求評審便已成功了一半。因為戰略已定，而剩余的戰術則是容易完成的事情。

8. 業務流程

版本迭代價值達成一致認知后，下一步便是對具體的目標下的業務場景和流程進行講解。

業務講解的目的是為了讓相關人員了解后續所講解需求的背景，而研發、測試等人員都是具備較強的邏輯性思維的，因此在做業務講解時，可以提前準備好業務流程介紹的內容，如業務流程圖。

在講解的過程中，將具體的業務場景結合多角色的流程流轉進行說明，便可以將需求核心功能邏輯講解清楚。

甚至對于一些有經驗的開發人員來說，后續的頁面樣式、功能特點都在這個階段都已經在心里有了個初步的雛形了。

當然，如果有人員提出針對某些復雜的業務流程做具體說明，也可以準備對應的任務流程圖來輔助說明，讓整個流程講解更加清晰。

業務流程與團隊人員達成一致認知后，最后的產品需求就是一個輔助說明的作用了。

9. 產品需求

最后的產品需求主要是針對所設計的產品原型、需求規則等進行說明，也就是最終的具象化的需求。

這一階段的講解是為了將前面的迭代價值、業務流程做一個在產品表現層的說明，促進最終產品需求的落地。

對于產品開發迭代來說，最終發布驗收的還是產品功能、交互、元素展示是否與產品需求文檔一致。產品需求文檔也是作為產品、研發、測試、設計等角色都唯一共同認可的標準。

由于個體認知偏差的客觀存在，需求評審有時并不是一輪評審就可以敲定的，往往都會有一些遺留待確認內容。產品經理需要在評審會上進行記錄，會后將內容確認之后，再行同步相關人員。如有必要，還要繼續發起二次評審，確保將歧義內容都在迭代開始之前進行明確。

做好需求管理，用產品價值為公司的發展奠定堅實基礎。