資深產品經理是如何做需求管理的：需求的優先順序判定原則

需求管理是產品經理的基本功。雖然從入行開始，產品經理們就開始接觸需求了，大部分的人跟過一遍需求流程都能快速上手。但是基本功也正是考驗功力深淺的關鍵所在。本來希望用一篇文章去講清楚如何做需求管理，但發現這樣會導致文章過長不易讀，索性用一個系列來仔細聊聊，到底什麼是需求，如何做好需求管理。

這一期主要講兩個基本問題：

什麼是需求

整體思路下的優先順序判定原則

以下，Enjoy。

需求是流水線上的零件？

回想剛入行時，我對需求的理解就好像是從流水線上傳過來的一個零件，這個需求是上游給的，這個需求是業務給的。即使是mentor說，或者你意識到要評估衡量管理需求，對於一個新手來說，事實上總是缺少對需求的管理的。當然，這是每個產品經理成長必須經過的一個階段，我以及周圍很多同行的經驗告訴我，這個階段是無法jump過去的，在這個階段中的PM們也不要心急，沒有什麼秘訣或者捷徑可以讓你獲得老司機的功力，必須有這樣的思想準備。

和所有迷茫焦躁的新手PM們一樣，我也是跟著一遍一遍走需求的完整流程。最開始在需求的管理和把控上都很被動，因為在業務驅動的公司，業務部門具有天然的話語優勢，你會感受到分分鐘被GMV碾壓——「這個功能非常重要！這一期必須上！」「為什麼？」「不上我們會損失XXGMV，會嚴重影響用戶體驗」……類似的對話相信很多產品都很熟悉了。我當時的感受是，每個月總有那麼幾天是在和業務圍繞著成噸的需求進行低效率地撕逼，撕完之後再去反省，就會覺得自己好弱雞，「如果換成這樣的思路，這樣的說服方式，效果應該會好一點。」經歷多次撕逼——反省——撕逼的非良性循環後，正好是另一個新的大版本的開始，我下定決心要整體復盤尋找這種循環的七寸。經過一個春節假期對所有舊版本需求的梳理以及分版本的復盤之後，突然感覺打通了經脈，有一種「呵，原來需求要這樣管理」的感悟以及「我原來到底是怎麼做需求的？！」的詫異。

需求是partof your plan

前面講到，最開始我認為需求是流水線上的零件。雖然每一期都會對需求進行「優先順序判定」，但是那個階段做得更多的是把零件放到不同的地方而已。看起來好像已經排了優先順序，但是這種排序的問題在於——缺少連貫性和繼承性。這個問題的癥結在產品的頂層設計。

當然這個insight來自於我對舊版本的復盤。我驚訝的發現，在一個大版本裡面，竟然每個小版本都有交互優化型需求。（我究竟幹了些什麼樣的需求。。）在移動產品中，大部分交互優化型的需求屬於緊急（資源集中在前端並且要跟著發版上線，時間上游限制）但不重要的需求。不重要，並不意味著交互優化對用戶體驗沒有作用，而是說，根據這個工作的ROI來看，根本不值得每一版傷筋動骨。

那麼，為什麼會出現密集的交互性需求呢？只有一個原因，產品經理根本沒有想過「產品框架設計」。就好比一個建築師首先必須明白房子的結構是怎樣的，產品經理也是，必須跳出需求本身去思考產品框架怎麼設計。也正好比一棟建築的結構不能隨意改動，產品經理在設計產品框架時，也必須用長期的視角去考慮，要搭建什麼樣的基礎框架，更直白點說，一個大版本，基礎產品形態是怎樣的？整體的思路如何？

經過這樣的復盤和思考，我對需求的理解也有所升級：需求應該是part of your plan,是大框架下的小模塊甚至小磚頭，也就是說，所有的需求都要為Plan這個整體目標服務。

整體思路下的優先順序判定原則

當意識到需求要為整體目標服務時，對需求的優先順序判定就有了頂層設計思路。

當然，涉及到大版本的整體思路，必須要和相關團隊同步腦暴，形成共識。（後續會和大家分享下如何做產品規劃）在團隊達成共識的基礎上，由於大家目標一致，在小版本上的需求管理就會變得容易很多。實戰經驗表明：如果團隊目標一致，主要是業務方和產品有統一的共識，不僅在需求提報環節模糊的需求會減少很多，在需求評估環節，雙方也更傾向於快速達成一致，低效的撕逼也減少了。

團隊沒有共識的時候，很容易發散地走向不同的思維路徑，這種情況是我做低年級產品時經常遇到的困境，經常是溝通了多次之後發現誰也說服不了誰。在團隊思路一致的情況下，這種情況基本上不會出現了，如果意見不合出現分歧，那就回到爭論的原點從整體的思路出發看到底哪種方案更有利於共同目標的實現（優先順序判定的終極原則）。

如果你發現你總是陷入低效的溝通或者無結論的爭辯，建議lead團隊對產品的框架進行腦暴和review，對於後續整個的需求管理，這是最重要的步驟。

本文由 @時雨 原創發佈於人人都是產品經理。未經許可，禁止轉載。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！