編輯導語：需求，是產品經理不可避免的工作日常。產品經理每時每刻都在與需打交道，因此必須處理好需求，工作才能順利地進行下去。所以，產品經理需要在工作中建立自己的“需求池”，讓需求寬進嚴出，保證開發(fā)的需求都是有助于產品發(fā)展的。而如何管理好需求池，這是產品經理必須練好的基本功。

產品經理的日常工作中，最頻繁的一項是「接需求」，特別是 B 端產品經理。記得有一次和朋友聊天，說剛入職的時候有需求池中 100 條記錄，工作 2 年離職后，需求池中只剩下 300 條了。

如果你感覺每天被需求包圍，東一頭西一頭忙忙碌碌而無價值產出，那就好好思考下，是不是需求池管理出了問題。

一、為什么要做需求池管理？

1. 人是很容易健忘的

特別是產品經理每天要和研發(fā)、運營以及和業(yè)務方溝通，會記錄大量的反饋和要求，如果沒有一個地方來管理這些內容，我都想象不到工作該有多混亂。

甚至在思考業(yè)務的時候，產生靈光一現(xiàn)的想法，比如半夜睡不著，想到一個不錯的方案，如果不記錄下來，很可能再也無法想起來。

2. 需求池給自己看的

剛才說了，人是健忘的，很多信息如果不及時記錄，那就等于以后不會在想起來做。有一個記錄清晰，分類明確的需求池，也是幫助產品經理做好產品規(guī)劃的好武器。

3. 需求池是合作伙伴看的

運營、銷售、市場或者兄弟團隊給我們提了那么多需求，現(xiàn)在進度怎么樣了？

老是來問你也不是個事，有個需求池一目了然，減少不必要的溝通，也能增加你在合作團隊中的靠譜度，讓合作的小伙伴明白你的計劃和進度。

版本規(guī)劃要用到版本的內容，很大程度上來自需求池，也是版本迭代的一部分。

二、完整記錄原始需求

做好需求池管理的第一步：完整記錄原始需求。

雖然不是所有的需求都會進需求池的，但要盡量保證完善的記錄反饋結果，或許溝通的時候覺得不合理，回過頭來思考，或許還會有新的發(fā)現(xiàn)。

溝通原始記錄：誰反饋、什么問題、場景。

需求池是作為溝通的原始記錄，要包括以下幾個信息：

• 需求來源（參與人員）：方便后續(xù)追蹤和反饋；
• 場景（溝通內容）：誰在什么場景下發(fā)生的、遇到了什么問題、想達到什么結果，反饋問題的人，不一定是遇到問題的人，一定要找到需要解決問題的人。

如果是和外部團隊合作，是需要確定一下合作的時間節(jié)點，避免影響進度。

收集需求的過程中，和不同類型的用戶溝通，方法也不一樣。

比如面對核心客戶或核心支撐的業(yè)務團隊，除了接收反饋，還要主動探聽業(yè)務目標和場景。

特別是 B 端業(yè)務，因為他們是跑在其他客戶或業(yè)務的前面，我們要通過和這些用戶緊密配合，讓我們的產品時刻保持行業(yè)領先，通過解決核心用戶的問題，給其他用戶提供業(yè)務思考和解決方案。

三、需求分類、設置優(yōu)先級并反饋

拿到這么多需求，我們要把需求管理起來，形成我們的工作內容。整理需求的過程，就是把用戶反饋，翻譯成產品需求，分類并制定優(yōu)先級。

在整理需求之前，產品經理內心要明確 2 件事：負責產品的定位，以及當前階段產品的目標。這樣才能在管理需求的時候，有統(tǒng)一的衡量標準，確定好需求的優(yōu)先級。

優(yōu)先級的方法很多，比如說緊急重要 4 象限等，我這邊的優(yōu)先級劃分標準：

1. bug：評估影響，要盡快解決；
2. 老板需求：盡快解決，給你發(fā)工資的人，偶爾給你提一個需求，難道還要拒絕？還不趕緊處理好？
3. 能給業(yè)務或客戶帶來直接價值的大小，確定優(yōu)先級高低；
4. 與產品的定位契合，與公司發(fā)展大方向有關的，雖然和現(xiàn)階段目標無關，但也是要記錄到需求池中，雖然優(yōu)先級可能不高，但會比較重要，需要時常拿出來看看。

1. 結果反饋

我們做完需求分析、分類、優(yōu)先級劃分后，要給提需求的小伙伴一個直觀的反饋：比如說 bug 馬上修復，或需求在未來 1 個月內上線，甚至如果需求不符合當前產品的定位，可以拒絕。

有一個明確的反饋，業(yè)務小伙伴也會根據(jù)你的節(jié)奏，配合你的工作。

2. 需求池參考格式

舉個例子：內部運營工具自動應答工具，不支持設置的關鍵詞搜索，業(yè)務團隊也反應過好幾次，那這個要不要立即做呢？

看下產品當前階段的目標：當前是要做一款快速拉新工具，幫助運營團隊快速獲客。雖然自動應答工具搜索不好用，但搜索的場景極少，遇到這種情況，可以查數(shù)據(jù)庫解決問題。于是這個需求的優(yōu)先級設置的比較低。

最后給業(yè)務團隊反饋：已列入需求池，遇到類似問題找產品解決，但近半年不會有調整的計劃。

四、避免踩坑

需求池最終是服務于版本的，B 端產品經理一定要在深入理解業(yè)務的前提下，整理需求并與業(yè)務驗證，基于業(yè)務的目標來制定版本。

在收集需求時，要確保信息的完整和準確，不要想當然的加戲，添加一些自己想象出來的需求，雖然有可能給客戶一些驚喜，但大概率是給自己挖坑。

#專欄作家#

司馬特小隊，公眾號：司馬特小分隊，人人都是產品經理專欄作家。8年+互聯(lián)網(wǎng)資深產品經驗，多年B端產品管理經驗。具有多個從0到1的大型B端產品的孵化、重構、迭代經驗；主要教授產業(yè)互聯(lián)網(wǎng)產品相關的硬核知識點。

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

題圖來自Unsplash，基于CC0協(xié)議。