“需求”是種很玄的東西-淺談需求管理

自從三年前走上了產品的“不歸路”， 幾個高頻詞匯像“用戶需求”，“用戶體驗”，“用戶疼點”等等，就不斷的在耳邊響起，自己也時不時的跟各路人士侃上一番。隨著經驗值的增加，對“用戶需求”這個詞有了愈加深刻的認識，它不僅僅是個名詞，它貫穿產品設計的始末- 如何定位需求，如何對待需求，如何將這些需求成為有效輸入到產品路線的規劃中，如何后續去驗證需求是否有被滿足。

尤其是開始做面向企業(2B) 的產品， 更是了解到需求管理的重要性。當你產品的revenue絕大部分依靠少數幾個大客戶貢獻時，某個大客戶突然提出了新的需求，要求A功能盡快加入到你們近期開發計劃當中，如果不能滿足，就考慮其他競品。 這時候，作為產品經理的你，應該如何處理面對。

• 確定需求- 明確問題本身，比需求反饋更重要

用戶一定明確的知道自己需要什么嗎？？需求的產生源自于問題，說白了也就是用戶實際遇到了現有產品無法解決的問題時產生的。然而每個人都自認為是解決問題的好手，用戶融入自己的經驗、理解提出他認為的解決方案propose給你的產品。舉個最通俗易懂的例子，一個人覺得冷了，他說他希望獲得更多的衣物保暖，但也有可能是他病了，或是饑餓導致寒冷感。因此，確定需求的目的是要發現問題本身，而不是停留在需求層面。了解用戶在什么場景當中會遇到怎樣的問題，是確定需求階段的主要目標。

• 評估需求- 做對的事情，比把事情做對更重要

回到開篇談到的那個例子，你的某個大客戶突然提出了一個緊急的需求，并claim如果不能盡快實現，就有流失的可能性。作為一個有“節操”的產品經理， 是否因為這個客戶是大客戶，對于來自他的需求就加以更高的權重呢？我認為產品經理應堅守產品設計的“初心”， 判斷需求是否具有代表性 （可以通過反饋統計，用戶訪談，競品分析等等途徑）， 判斷需求是否符合產品的戰略目標 ， 正確評估資源的投入和產出 （不僅僅是短期利益，以及產品發展的長期利益）。

有人可能認為，大客戶這樣就跑了啊。如果你有充分的理由或workaround, 客戶未見得會跑；如果你真的投入很多資源為某個客戶專門開發了某項功能，即便是這個客戶短期內留住了，真正服務給更多用戶的功能被停滯了，又何嘗不是得不償失呢。當然，如果公司的各項資源都足夠支撐，玩兒得起，這另當別論。

• 排序需求- 不以技術實現的難易為主要衡量標準

確定了這個需求要做，但是開發現在已經被各種需求堆滿，不經意的一根稻草，就可能引發暴力事件。因此，合理的排序需求，不僅對于產品經理而言，是保障不成為“群毆對象”的良方，也同時保障產品在健康的生態下得以不斷提升。

然而很多產品經理都會不經意在實踐中陷入一種誤區，開發說容易實現的優先，短時間內不容易實現的放在最后。特別是一些懂一定技術的產品汪，還不用跟開發聊，自己就能判斷出大概的實現的難易，默默以此排序了。我自己也曾陷入過這個坑，當時還記得被一個開發不留情面的說，“你排需求不應該從技術實現角度考慮，而且你憑什么代表開發評估難易。”一時被問的語塞。

這是否意味著Roadmap的設定就不考慮技術實現？當然不！排序要考慮的核心是怎樣以最低的成本，做出對市場效益最大的影響，收獲最大的利潤。技術實現所需的資源也是成本考量的一部分。因此，作為產品經理，應著重對于市場進行分析，根據市場影響、收益等因素進行排序，交由開發團隊評估，并一起討論確定優先級，通過團隊協作以達到利益最大化的目的。

• 驗證需求-知道自己不知道什么，比什么都不知道要好

功能上線，這個需求就被close了嗎？你如何判斷這個新功能是否解決用戶的問題，并如何評估這個新功能的有效性。“知道自己不知道什么，比什么都不知道要好”，這是之前當實習生的時候，師父常說的一句話，當時沒有太深的體會。不一定每一次把握痛點都是穩準狠，特別是對經驗值沒攢高的產品汪，知道gap在哪里，不僅能不斷增加自己對于市場需求的sense ，同時也是對產品負責。

驗證的方法是多樣的，主觀的用戶訪談、反饋收集等，客觀的數據分析都可以幫助評估。在此，想著重說下數據這一途徑。對于產品功能的驗證數據，更多是要在設計初期計劃好，確定核心KPI去度量，確定如何衡量成功與否。如果等功能上線后，突然意識要去抓取某些數據，可能會遭遇后臺根本統計不到的尷尬。所以，產品汪更要具備一定“未雨綢繆“的能力。

收尾：正如開篇談到的，需求是貫穿產品設計的始終，需要從初期考慮需求管理的完整周期-確定、評估、排序、實現和驗證。文章中談到的都是之前經歷的感悟，也多是自己踩過深坑后切身的感悟。