編輯導讀：需求，是戴在每一個產品經理頭上的緊箍咒。產品經理每天要面對大量的需求，建立需求管理機制能夠幫助產品經理更好地工作。本文作者對此進行了分析，希望對你有幫助。

產品經理每天都需要面對大量需求，很多朋友會通過“需求池”對零散需求進行統一、高效、有序的管理。但需求池只是需求呈現的載體和工具，并不能包治百病，實際操作中會出現各種意外，比如：

• 無效的需求記錄：不是指需求記錄的不清晰，而是指明顯不符合產品定位、場景不明確的需求未經篩選就被記錄。
• 超量的高優先級：需求方都認為自己的需求更重要更緊急。面對多方的各種催促，出現了大量高級別需求，導致等級制度失效。
• 短視的版本規劃：將迭代周期內的需求塞滿即可。把需求、設計、上線做成了下意識的循環，缺乏產品整體層面的發展規劃。

為了避免需求管理的效果打折扣，接下來根據需求的流轉，依次講解需求處理過程的管控要點。

01?需求的有效采集和過濾

需求是產品的源頭，產品是需求的解決方案。所以，有效采集需求是需求管理的第一步。雖然每個產品所處的環境存在差異，但是為了不在需求階段迷失其中，需要從全局角度對需求來源、采集方法、需求篩選（初步）有整體的認知，便于后續對不同需求采取更合適的應對策略。

1. 需求獲取渠道

不同產品的適用場景和使用角色都不一樣，造成了需求來源較為復雜的現象?？梢酝ㄟ^渠道通用屬性的方式進行分類。

分類目的在于全面了解產品的相關方，避免遺漏。畢竟不是每個角色都會主動反饋問題和需求，更多情況下需要產品經理主動溝通和挖掘。產品經理不要忘記“沉默的大多數”。

渠道分類的維度也多有不同，本文以內外渠道區分為例：

• 內部同事：組織內任何和產品相關的角色都有提建議的權利。比如：Boss、銷售、運營、技術等。
• 外部客戶：客戶通過對應渠道反饋產品需求或問題。在項目中客戶也區分決策人、使用人等多種角色。
• 產品經理：基于對產品、用戶、發展戰略的觀察、分析等行為，進而得出需求。

2. 需求采集方法

需求獲取的方法是多樣的，有的是產品經理通過設計進行獲取，有的是客戶主動進行反饋。具體方法如下：

• 產品方獲?。河僧a品方主動獲取需求的方式。如：行業研究、調研問卷、實習輪崗、數據分析、現場訪談……（詳見：B端需求調研：客戶訪談操作詳解）
• 客戶方反饋：由客戶方主動反饋需求或問題的方式。如：客服咨詢、用戶投訴、意見建議、公開渠道的評價（微博、垂直社交媒體……）

客戶主動反饋時，產品經理并不能改變采集方式。針對產品經理主動獲取情況下，采集方式應當如何選擇？我們知道每種方法各有優劣，要結合實際情況靈活選用。影響選擇的關鍵因素有哪些呢？我認為至少考慮以下3方面：

• 用戶是否接受此方式？面向不同角色，或同一角色的不同場合。用戶對各方式的接收程度都是不一樣的。有時我們希望面談，但客戶總是沒時間……
• 資源是否支持此方式？公司的時間、人力等資源都是有限的，產品經理需要在合理資源限度內完成采集。比如實習輪崗，可以較深入的了解現場，但耗時太長，通常采用的比較少。
• 能否達到采集的目的和效果？如果調研后沒有達到目標，意味著采集無效以及投入資源的浪費。

3. 需求初步篩選

通過各個渠道獲取需求后，就進入的記錄階段。會發現需求總是源源不斷的過來，但是產品經理的精力以及公司的資源都是有限的。所以要辨別需求的真偽和潛在價值，把不符合要求的需求剔除，不計入該產品的需求池中，避免后續資源的無效投入。

篩選的過程是“砍需求”的過程，是對需求潛在價值判斷的過程。除了要對產品本身有所了解，也需要專業能力的支撐才能更加準確的判斷。事實上，從需求收集到研發上線之間會經過多次“砍需求”。

此時作為初步篩選，要求并不嚴格。只需要做2件事：需求場景還原，需求屬性分類。

1）需求場景還原

需求有對應的完整場景是篩選的第一步，如果還原不了場景，則認為需求是假需求。場景還原只需要問幾個問題，能回答出來且邏輯自洽即可——誰（角色）在什么情況（背景）下，遇到了什么問題（需求）？當前的處理方法是什么？

場景還原時需要將相關的場景進行窮舉，避免因場景遺漏導致后續產品設計時出現漏洞。

需要注意的是，有的需求場景還原完整，但不符合本產品定位，此類需求對本產品無價值，但需求本身沒問題。建議記錄在另一張需求池表單中，作為外延產品的需求儲備。

2）需求屬性分類

除了需求基本的信息記錄，還要判斷需求的類型，為后續的需求評級和需求分析提供支持。比如：核心需求，基礎需求，衍生需求，技術需求，運營需求，體驗需求……

需求分類同樣沒有標準答案，存在多種維度的分類方式。重點在于你定義的需求類型，在后續分析中是否存在對應行動策略，如果僅作為需求池的統計查看使用，意義不大。

存在潛在價值的需求將被一一記錄在需求池中，等待下一輪的篩選和價值分析，直到被某個版本選中……

02??優先級的制定和維護

初步過濾可以把部分需求排除在外，剩余需求將被納入到需求池中。至于選擇哪些需求進入實現階段，則根據需求的優先級來排序。每個團隊都應該有自己的優先級評估標準——你的優先級評估標準是什么？評估標準又是怎么維護的？

1. 區分需求所屬類型

在制定具體的優先級規則之前要先區分需求類別，不同類型的等級制定策略存在差異?？梢曰凇爱a品管理權”和“需求確定性”來劃分需求類型。

1）基于“產品管理權”劃分

在公司內部，一款產品的管理權限通常是由多個角色共同組成。不僅有產品經理，還有運營、上級領導等其他角色也具備管理權。

• 響應性需求：對應角色行使自己對產品的管理權限，產品經理沒有拒絕的權利，根據具體要求排期和執行即可。比如運營同事策劃了一場活動，需要在產品中實現。此時產品經理沒有拒絕的權利，只要建議的權利。
• 自主性需求：當產品經理在處理自己管理模塊內的需求時，其他角色也不能拒絕（領導可以拒絕）。其他人同樣可以提供建議。并不是要產品經理剛愎自用。

2）基于“需求確定性”劃分

針對自主性需求也要區別對待，首先是判斷需求實現結果的可控性，面對可控和失控的需求要制定不同的策略來應對。

• 不確定需求：對需求實現的結果預測精準度過低，不具備參考價值。常見于全新業務情況，沒有過往數據和歷史經驗作為參考。面對此類需求通常采取MVP策略。
• 確定性需求：對需求實現的結果預測相對準確的，可以將需求代入制定好的優先級等級，進而找到優先級順序。（本文針對此類需求的優先級進行講解）

2. 制定優先級標準

優先級標準是判斷各需求實現先后的依據。比如Bug優先還是需求優先，實際上當然不會如此粗獷?？梢杂贸Ｒ姷闹匾o急程度、KANO模型等方法幫助我們建立和細化等級標準。

1）重要程度：以產品目標為中心

假設有2個需求，實現需求A可以帶來新用戶10000人，實現需求B可以提高活躍用戶10000人?？墒褂玫馁Y源有限，只能實現1個需求。你會選擇那個需求實現呢？選擇依據是什么？

需求重要程度的判斷依據是“產品目標”，契合產品目標的需求就是重要的需求，偏離產品目標的，不論能夠帶來多大的收益，都不能稱之為重要。

產品目標是根據公司戰略、產品定位、發展規劃、領導決策、用戶反饋（KANO模型 – 期望型需求）等綜合因素制定的。產品目標落實到執行層面，會反應在某項數據指標的變化上。比如：產品/某活動/某功能的拉新；產品/某功能的促活；某環節/某功能模塊轉化；商業化指標……

需要注意區分用戶目標和產品目標。提升效率、降低成本、優化體驗等以用戶視角提出的訴求都是用戶目標。需要把用戶目標轉化轉為為產品目標。比如，在滿足了提升效率的用戶目標后，會達成產品目標數據指標A的變化。

2）緊急程度：以嚴重程度為中心

假設產品目標是提升拉新數據，現在有2個需求，需求A可以帶來新用戶10000人，需求B會帶來新用戶1000人?？墒褂玫馁Y源有限，只能處理其中1個。你認為那個更緊急呢？

很顯然，多個需求都滿足產品目標時，效果越好的越優先（緊急）。

假設產品目標是提升拉新數據，現在有1個需求和1個Bug，需求可以帶來新用戶10000人，Bug會造成流失用戶5000人?？墒褂玫馁Y源有限，只能處理其中1個。你認為那個更緊急呢？

處理Bug時不考慮產品目標（重要程度），只考慮緊急程度。把需求和Bug的緊急程度放一起對比，之后再根據各自評估的嚴重程度來決定先后順序。通常采用如下的緊急程度標準：

P1：處理需求，獲得良好的正面效果

P2：處理Bug ，避免持續的嚴重損失

P3：處理需求，獲得一定的正面效果

P4：處理Bug ，避免持續的輕微損失

3）其他代價：關聯指標的變動

經過重要緊急程度的篩選，我們可以得到重要（符合產品目標）的需求和Bug，并根據緊急程度進行排序。實際操作中還需要注意需求實現后的其他代價！

這里的代價不是指實現需求的成本，而是指需求實現后對產品目標之外的其他數據的影響。正面影響也就罷了，需要格外注意負面影響，負面影響會改變需求的價值。

假設產品目標是提升營收，現在需求A是向用戶端投放廣告，預測能夠獲得50萬營收，但是會造成3萬名用戶的流失。這時候需求A還是高優先級的需求嗎？

3. 需求等級的動態調整

產品目標不是一成不變的，產品目標變更后對應的優先級標準也同步變化。標準變更后，各需求的優先級也要重新評估。

比如：產品目標從原來的提升“活躍”數據，變成了現在的提升“拉新”數據。對需求A的結果預測是能夠拉新1000人，促活100人。需求A對拉新顯然價值更大。結合產品目標來看，需求A的價值隨著產品目標變更而同步變更，從低優先級轉變成高優先級。

產品目標的變更有什么規律？變更的影響因素和建立時一樣，此時更關注目標變更的觸發點?；痉譃?種：定期變更、臨時變更。

• 定期變更：通常以1個季度為周期，定期檢查產品所處環境和發展進度是否符合計劃。出現脫節時要及時調整，避免發展偏航。
• 臨時變更：通常是因為市場、政策、競品、產品自身發展突然出現重大變化，所以需要及時關注產品相關的重大事件，便于及時應對。

03?契合優先級的需求序列

當我們獲取了有效需求，建立了優先級規則。各個需求具體的優先級順序如何排列呢？大部分公司都有自己的優先級制度，但是為什么執行總是不如人意？可能是因為執行力松散，也可能是因為對需求價值的判斷失誤。

一旦實現的需求選擇錯誤，會造成數據結果不能滿足產品目標。意味著投入的時間，人力等資源的浪費，也可能導致產品在瞬息萬變的市場上失去競爭機會。所以要建立更加細化的規則，進而量化需求的價值。

1. 判斷需求屬性

對“確定性需求”的優先級排序，首先根據“優先級”的重要程度判斷需求屬性——即：需求是否符合產品目標。

需求的實現會影響產品的多項數據表現，列出受需求影響程度較高的數據項和產品目標進行匹配。選取匹配程度更高的需求進入當前版本的“待定清單”中。

比如：產品目標是提升拉新數據；需求A有效提升活躍數據，拉新數據影響不大；需求B有效提升拉新數據，活躍數據影響不大。所以會選取和產品目標更匹配的需求B。

通常1個版本中只有1個產品目標，更有利于增強目標的實現效果。如果設立了多個目標，則需要先對各目標本身做優先級排序，并分配對應的權重。估算需求的對各目標的效果后，結合目標權重再重新進行需求排序。

2. 量化需求價值

假設需求A、B、C都進入了本版本的待定清單中，現有的資源有只能夠實現2個需求。那么淘汰誰？剩下的誰先誰后？只有對需求價值或Bug的影響進行量化，才能夠得出較為客觀的結論。換言之對產品所帶來的正向數據變化就是需求的價值所在。

需求價值的計算過程中，需要充分考慮關鍵影響因素。公式表達：需求價值 = 潛在用戶數 x 轉化率 x 使用頻次 x 用戶價值 – 關聯指標負面影響

1）潛在用戶數

• 評估需求會影響的用戶類型，再估算對應類型客戶的數量。
• 用戶類型根據企業內部對客戶的分類。比如：普通用戶、會員用戶、活躍用戶。
• 估算對應用戶數量時，注意用戶的存量數據和增量數據。

2）轉化率

• 預估潛在用戶使用該需求對應功能的轉化率。
• 轉化率一般按照活躍度來計算，不同類型用戶的活躍度不一樣。

3）使用頻次

• 估算目標用戶一定時間內使用該功能的次數。針對不同類型的需求采用不同的時間長度計算。
• 見效快的需求，計算時間周期短，如1~3月；見效慢的需求，計算時間周期長，如3~6月。

4）用戶價值

不同類型的用戶價值需要分別計算。比如：普通用戶和VIP用戶對產品的貢獻是有巨大差別的。

5）關聯指標的負面影響

• 考慮效果時不僅要考慮正面收益，也要考慮需求實現對關聯指標的負面影響。
• 計算收益要減去需求關聯bug負面影響。比如：需求A可促活3000用戶，bug可導致1000用戶流失。所以預估效果應是促活2000用戶。
• 特別需要注意需求實現付出的其他代價。比如：添加廣告可以提升收益數據，但是會降低活躍等數據。

3. 需求的性價比

計算出需求價值后，按照價值高低排序就是我們要的需求優先級了嗎？這樣的想法依然過于片面。做決策不僅要考慮收益，也要考慮成本和性價比。

1）需求成本估算

這里的成本是指實現需求所需要投入的人力成本。同時為了計算方便，一般會將不同崗位的人力成本設定為同一個價格。用公式表達：人力成本 = 所需人天 x 單位人天費用。

比如：需求A實現需要產品設計3天、UI設計2天、研發測試5天，人力成本是500元/人天，則需要A的人力成本是5000元。

2）實現的性價比

最后一個步驟就是計算需要實現的性價比。根據性價比排序，性價比越高則排序越靠前。到此，完整的需求優先級才算制定完成。用公司表達：性價比 = 需求價值 / 人力成本

比如：需求A的需求價值50000元，實現需求的人力成本5000元，則性價比是10；需求B的需求價值20000元，實現需求的人力成本1000元，則性價比是20。綜合來看，雖然需求A更有價值，但是需求B的性價比更高。因此需求B的優先級高于需求A。

附：“需求池”概況介紹

1、創建方式

需求池的創建方式并不固定，團隊內保持一致即可，使用Excel或項目協同軟件都行。比如：Teambition、禪道……

2、表單字段

需求池的具體字段可根據團隊關注的要素自行調整，也可以把部分字段轉移至關聯文件中，比如在“產品版本”文件中記錄各環節的負責人、計劃用時和時間段、實際用時和時間段等信息。主要包含以下：

• 基礎信息：需求方、提出時間、需求編號、需求概述、需求詳情
• 需求屬性：所屬模塊、所屬功能、需求類型、需求狀態、重要程度、緊急程度、需求等級、產品負責人、產品版本

3、補充說明

• 需求詳情：完整需求的描述較多，通過圖文等形式呈現，不便在excel上呈現。通常會用獨立文檔記錄。通過“需求編號”檢索查看“需求詳情”。需求詳情同時會記錄需求方、提出時間等信息。
• 所屬版本：版本規劃屬于項目管理內容，在對應“項目管理”表單中會標記需求實現各環節的負責人、交付物、計劃和實際用時、開始和結束時間等信息。

本文由 @耳目不染 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議