十年老產品經理教你管理需求池

04-29

所有的產品都是解決用戶問題的工具，解決問題也是產品存在的唯一價值。

問題是客觀存在的，產品經理就是根據企業的戰略目標，找到目標用戶，分析挖掘他們遇到的問題，提出解決問題的方案，整理成需求，設計成產品推向市場。

一、需求來源

一個產品的需求來源是多種多樣的，有的需求靠譜，有的需求不靠譜，需要我們自己學會收集，整理，挖掘。

1. 戰略規劃

戰略規劃的需求往往來自於公司老闆的想法。很多老闆會把一些機緣巧合、經驗積累，甚至可能是一拍大腿而來的想法拿來和你交流。首先要恭喜你，老闆還是很重視你的，在這家公司你能有很大的發揮空間；同時會有更大的苦難等著你。

老闆，尤其是創業公司的老闆很多是不懂產品、不懂互聯網的。但是他們往往都會聽到很多互聯網的名詞，並且以為自己很懂。這樣的結果就是老闆的很多想法不能直接變成產品，還會對產品提出一些似是而非的需求。這個時候就要靠產品經理的氣場、思維、口才來hold住老闆。更關鍵的是你需要知道老闆真正想要什麼，想要打什麼市場，消費者是誰，錢怎麼賺。老闆有一項能力一定比你強，就是他的信息接觸面。只有你真正知道老闆在想什麼，要幹什麼之後，你才能用自己的專業技能為他提出更好的解決方案。

2. 競品分析

最容易聽到的初級產品經理說的一句話就是「我們這個產品是創新的，沒有競爭對手」。這句話直接反映了產品經理的格局不夠高、視野不夠廣。

產品是依賴於問題而存在的，幾乎所有的問題都是長期存在的，也就是說幾乎所有的問題都有現成的解決方法。這些現成的解決方法就是你的競品。不管這個解決方法有多麼low，多麼原始，多麼和互聯網不沾邊，你多麼瞧不上。但我們在做競品分析時一定要認真考慮我們的產品和現有的這麼多解決方法相比，優勢到底在什麼地方。這就是競品分析！

大多數產品經理做的競品分析只是停留在互聯網的區域，這是競品分析的一個重要部分。但如果你的眼光只是局限在某一個領域，也就很難做出真正偉大的產品。

以後，你如果再覺得自己的產品沒有競爭對手的時候，不妨把思路放開後再想想。

3. 運營反饋

產品經理梳理需求後交給開發團隊，這是對信息的過濾和加工，降低開發的成本，作為開發團隊的最後一道重要防線，幫助開發團隊擋子彈。

運營的小夥伴直接面對形形色色的客戶，遇到各種各樣的問題。他們理應將需求梳理後交給產品經理，作為產品、開發團隊的第一道防線，擋掉一部分子彈。但大部分情況，運營不僅不會幫你擋子彈，反而會多補上幾槍。這就需要產品經理自己來過濾、整理運營的反饋了。

4. 用戶反饋

好的產品經理除了對用戶要有理性的數據分析、功能的埋點統計之外，也會找機會直接與用戶溝通，獲得對用戶的感性認識。產品經理是介於理性和感性之間的一種動物。拿到用戶反饋後，一定需要分析這些反饋是個性化的，還是普遍性的，這個用戶是在我用戶池中的哪一組。

用戶反饋的不一定是真實的想法，產品經理需要做的第一步仍然是還原最真實的問題，再想出解決方式（需求）。

5. 市場調研

市場調研分為兩種，宏觀市場調研和消費者調研。宏觀市場調研一般通過網上查找相關資料後整理分析；消費者調研是針對個體潛在用戶進行交流，獲得真實的問題反饋。

通過宏觀與微觀的調研相結合，能讓你對自己的產品所處的生態環境有一個更加全面的了解。

二、需求優先順序

拿到所有的需求後，我們需要對需求進行統一管理。需求池就是所有需求的集散地。需求池裡面要包括需求的簡單描述、需求來源、需求提交的時間、需求提交人。下面就是一個比較完整的需求池：

截圖來自 [領客PM - 互聯網產品經理專屬的需求、版本管理工具]

將需求整理好後，下一步就是最重要的判斷需求優先順序。

最簡單粗暴的方法就是：老闆需求 > 我的需求 > 其他人的需求。這也是很多初學者容易犯的毛病。

一般來說，產品的功能分為三個類別：核心需求、基本需求、擴展需求。

核心需求：解決用戶問題的最小功能集合。最好只解決一個問題。

基本需求：為了讓功能正常使用的流程性需求，比如：登錄、註冊、後台管理等。

擴展需求：為了用戶能有更好的體驗而設計的一些小的功能點。

按照需求的分類，結合當前產品推廣的方案，自然我們的需求優先順序就能定出來了。

三、需求開發流程

1. scrum

關於scrum的詳細介紹大家可以在網上找到非常詳細的資料，這裡就不再多說。scrum的核心是迭代，一般一個迭代周期是一周或者兩周。

需求池裡面會逐步積累大量的需求，但絕不可能把所有的需求都一次性交給開發團隊。這就需要我們在每次的迭代周期前從需求池裡面選擇適量的需求進入開發過程。

選擇的依據一個是前面我們定的優先順序、另外就是開發成本，一些不重要，但開發成本較低的需求可以提前塞到這次的迭代中。

2. 需求鎖定

當需求進入開發過程後，原則上不允許給開發團隊增加另外的需求。也就是說在一個迭代周期內的需求是被鎖定的。這種處理方式能最大化提升開發的效率。讓開發團隊有足夠的時間優化代碼架構。

3. 特殊需求-bug

Bug在產品上線之前是由測試團隊進行測試，開發團隊修復。但當bug是在產品上線運營後才被我們或者用戶發現，這類bug是需要列入需求池的。緊急的bug可以臨時發布版本，一般不是特別緊急的bug會按照普通需求的處理流程來走。

四、版本管理

版本號是迭代開發的標誌。很多創業團隊開發的產品是沒有版本號的概念的，開發的流程也一定混亂。目前有一些通用的版本號規則：

1. 版本號規則

一般版本號為：9.3.6，3.2.0這種格式。

第一位是主版本號：用於產品有重大更新的時候遞增，如最近發布的iOS 10。

第二位是次版本號：用於產品新增部分功能、模塊，但沒有大範圍的修改時遞增。

第三位是修訂版本號：用於產品修復bug，新增小的功能時使用。

第四位是build號：一般用於開發過程管理，不面向普通用戶。

2. 版本庫

產品的版本庫是至關重要的路標，它會反應出來我們之前走過什麼路，今後要走什麼路。結合運營的指標，我們更是能夠分析產品升級給我們的用戶量、市場佔有率帶來是什麼樣的影響。

截圖來自 [領客PM - 互聯網產品經理專屬的需求、版本管理工具]

需求池、版本庫、開發過程管理，是產品經理日常工作的重要組成部分。隨後我們會逐步為大家介紹產品經理工作中要注意的一些關鍵環節，希望能與大家一起進步、成長。