產品的源頭是需求。一切偉大產品的實現都是從需求管理開始的。敏捷開發中的需求管理大致分為三個階段：需求調研，需求分析和需求確認。
需求調研階段
產品立項後，產品經理便開始了和需求打交道的漫長過程。第一步就是需求的調研工作。需求調研的質量，會直接影響到後續產品設計的工作。產品經理可以從以下渠道來調研需求：
（需求的來源）
1.從產品定位出發
從產品定位出發指的是，產品經理應當對自己的產品有足夠認知和把控。簡單來說，就是我的產品是為了滿足哪些人的哪些需求而做的。每款產品必定有其核心價值，基於此考慮往往能得到一些核心需求，摒除價值不大的需求。
2.使用者反饋
使用者反饋包括使用者直接的反饋和間接的反饋。直接反饋指的是使用者直接提出需求，如在產品的交流論壇，官方QQ群等使用者提出的建議和需求。另外，使用者訪談、調查問卷等方式也是比較常用的蒐集使用者需求的方法。間接反饋指的是通過對使用者行為習慣（如習慣、偏好、使用流程等）的分析來獲取使用者的需求資訊。
3.競爭對手情況
知己知彼百戰不殆。競爭對手的產品優勢及不足也是產品經理需求來源的重要渠道。競爭對手好的功能我們如何借鑑優化，不足如何規避，在反覆探討中也能獲得好的靈感。
4.相關人反饋
這裡的相關人包括任何對產品需求有貢獻的人。主要有運營人員、客服人員、市場人員和開發人員的反饋。
產品經理在收集需求的過程中需要注意的一點是，儘量保證需求的精準性，一是使用者意圖的準確，一是語言描述的精煉，否則接下來的需求整理工作必然變得非常吃力。使用者需求在敏捷開發中稱之為使用者故事(user story)。通常的格式為：作為一個<角色>，我想要<功能>，以便於<商業價值>。這也是產品研發中使用者需求描述的最標準格式。
（禪道專案管理軟體中的使用者需求介面）
需求分析階段
通過需求調研，此時產品經理已經掌握了很多使用者需求，但這並不代表所有的需求都會為產品所用。產品經理需要對這些需求進行整理、分析與設計。需求分析主要有兩個目的，一是挖掘使用者的真正需求，二是評估可行性。
在做需求分析時，產品經理可以從以下幾個角度著手：
1.定位分析
產品定位就是滿足什麼樣的使用者在什麼條件下的什麼需求。如，購物網站是為了滿足購物需求，社交軟體是為了滿足社交的需要。購物網站的社交需求，社交產品的購物需求一定是與產品的核心服務不統一的。在做需求分析時一定要多問一問是不是符合產品定位？好需求但不一定是適合的需求，說的就是這個道理。
2.場景分析
場景分析指的是要考慮什麼環境（時間、地點、情境）下什麼型別的使用者基於什麼動機，希望達到什麼目的而採取的一系列行為。比如：
基於什麼環境：辦公室/家裡/公共場合/上下班途中/戶外/室內/白天/夜晚……
基於什麼使用者：老人/小孩/男士/女士/上班族/學生/家庭主婦……
基於什麼動機：省錢/省時/省力/打發時間……
想達到什麼目的：彰顯個性/炫耀/獲得認可/變美/變瘦……
3.深層挖掘
挖掘每個需求產生的原因：使用者基於什麼原因才提出這個需求？
挖掘每個需求背後隱含的需求：使用者提出這個需求，是為了達到什麼目的？
挖掘每個需求的重要性：這個需求是必須的嗎？如果沒有這個需求會怎樣？
通過深層挖掘往往會發現比原始使用者需求更加合理的方案，也能發現那些使用者沒有說出口和沒有想到的需求，而往往這些需求才是使用者的真正需求。
4.價值評估
價值評估是指這個需求需要多少開發資源或運營能力，技術難度如何，時間花費如何等。可以從四個維度考慮：
廣度：該需求能覆蓋多少目標使用者？
頻率：該需求的使用頻率是怎樣的？
強度：該需求對使用者來說有多強烈？
時機：該需求是否符合產品目前的規劃？在當前的資源情況下能否具備可行性？
（產品經理需要不斷提出這樣的疑問）
需求確認階段
經過分析整理，產品經理已經獲得了初步的需求列表，接下來需要對這些需求設計用例場景，並進行用例描述、流程分析、角色分析等。如，模組如何劃分、流程如何設計、業務如何轉換等，一般通過繪製行動圖、狀態圖、用例說明來配合呈現，並最終形成《產品需求說明書》。
很多時候，用例分析工作是產品經理、架構師、設計師等共同協作完成的，因為除了要考慮技術能否實現，還需要考慮產品效能、響應時間、設計風格等非功能性的需求。
最後才是需求確認工作，確認工作一般通過需求評審會議來實現，由於是最終確認，參會人員可能包括運營、開發、設計、測試等成員，共同對需求說明書中描述的需求的正確性、一致性、完整性、可行性、必要性、可測試性進行確認。
（使用者需求的特性）
在正式需求評審之前，產品經理可以提前與專案負責人做需求初評，目的是提前收集問題，溝通是否有技術難點，確認開發成本及是否有考慮不全的邏輯漏洞等。
由於敏捷開發是快速迭代的開發模式，敏捷開發中一般由產品經理根據需求優先順序整理近期待做需求，進行需求評審。評審會議叫做釋出計劃會議，在會上，由產品經理或產品負責人負責講解需求，並對其進行估算和排序，制定出這一期迭代要完成的需求列表。
需要提的一點是，在需求確認中一定要考慮到需求變更的確認。當需要進行需求變更的時候，一定要有書面的文件和簽字手續。由於流程複雜，現在很多研發團隊直接通過在專案管理軟體中來記錄需求的變更。如，禪道中凡是對需求 標題、描述、驗證標準和附件的修改，都應該走變更流程。
（禪道中的需求變更流程）
至此，需求管理工作基本完成，接下來便步入產品設計環節。但這並不代表產品經理工作的結束，需求評審完成後，還需要進一步和開發、設計瞭解實現細節以完善產品方案並跟蹤需求的實現。
需求跟蹤的目的是為了建立和維護從使用者需求開始到測試之間的一致性和完整性。在整個開發過程中，確保所有的實現是以使用者需求為基礎的。
逆向跟蹤：檢查設計文件、程式碼、測試用例等工作產品是否都能在《需求規格說明書》中找到出處。
（需求管理流程）
需求管理恰如裁縫的量體裁衣，它直接關係到最終產品的成型。需求管理的過程，其實是從需求分析開始貫穿整個專案始終，力圖實現最終產品同需求性的最佳結合。
資料借鑑：
