大家好，現將我過往工作中的在產品層面的一些方法論和實證經驗整理分享給大家，方便產品同仁交流學習。

本篇是同產品同學分享我自己在需求提取、需求翻譯、需求管理、需求設計、需求驅動、需求交付方面的一些實踐經驗，希望透過此篇文章幫助初中級產品從業者優雅的駕馭需求，進而做到從容應對雜亂無章的無序需求，對上游需方兄弟做到強有力的專家支援，對下游研發兄弟做到專業有序的統籌排程。

下沉到業務中+業務敏感

再牛的產品經理也需要了解業務，不瞭解業務能力再強也容易閉門造車。只有當我們融入業務，瞭解業務，才能時刻保持業務敏感。

所謂業務敏感，可以用如下幾個場景來表達：

場景1：當業務兄弟或業務領導與我們討論某個業務“表象問題”時，我們能立刻同頻、入鏡，並能用業務語言與當事人進行流暢交流，同時我們還能就“表象問題”挖掘出深層的問題或業務或老闆背後的潛在訴求，以及相應的解決策略。

場景2：我們要接受某個任務或解決某一具體問題時，我們心中有大盤，能夠站在整個平臺的角度思考問題、制定解決方案，避免掉坑裡。

場景3：工作業餘之外，作為產品的天生的好奇心能夠將外部的、行業內的、行業外的看似無關的東西引入業務內，推動業務的良性創新、演變。

熱愛你的產品+持續的業務思考

熱愛成就偉大，如果不熱愛我們的產品，單純靠考核，靠績效一定做不出偉大的產品。產品經理如果不喜歡自己的產品，如果不用自己的產品，如果不在工作之外也持續的思考自己的產品，很難有出彩的產出和產品創新。

當我們持續的關注、思考我們的產品時，使用者反饋給我們的問題，我們基本上已經提前知道，或者已經有排期或者有考慮。我們能走在使用者的前面，更大機率的提前發現問題，即使我們明知道短期內無法解決，但我們有對應的非開發策略予以補位，如我們的幫助手冊，如我們的排期計劃，如我們的業務邊界…

4份Excel文件：Roadmap+功能矩陣+3個版本的Featurelist+需求池Roadmap的設計策略及實戰case

Roadmap是以實現公司戰略目標為原則來確定我們產品建設的中長期指導計劃，不同級別、不同階段有不同的粒度尺度把握。

一份優雅的Roadmap需要具備如下幾個要素：

以經營目標為指導；

明確的時間視窗；

明確的業務場景、及業務目標；

邏輯演進的自洽；

基於公司現況的可承受的研發資源投入；

決策層共識與認可。

功能矩陣的設計策略及實戰case

功能矩陣是站在產品各一級功能視角或具體的業務場景視角去思考、設計我們產品的演進計劃，某種意義上講功能矩陣是另一個角度的Roadmap，但與Roadmap有明顯的區別。

區別一：功能矩陣更偏“矩陣”、更弱“時間”；

區別二：功能矩陣相比Roadmap，我們更習慣用“優先順序”、“狀態”來表述，而Roadmap裡的優先順序基本一樣，只是時間視窗的設定問題。

換句話說，功能矩陣是產品經理透過“自下而上”的內生動力，以暗線方式推動產品迭代演進。Roadmap是產品經理透過“自上而下”的外在框架指導，以明線方式推動產品迭代演進。Roadmap體現的是公司的戰略意圖，功能矩陣提現的是產品經理對產品的深度思考和排兵佈陣。

需求池：採集、梳理、更新策略及實戰case

產品經理打交道最多的就是需求，面對來自各方雜亂無章的需求，我們需要進行統一管理。基於分層組織架構，實踐中我認為比較好的採用AB結構。

A類需求池原則上是產品總監或一級產品負責人維護，A類需求池需要向產品內部進行實時同步、隨時查閱、協同編輯，共同維護，作為團隊的“公有資源”使用。實務中，產品總監或一級產品負責人需要每週、每月、每季度與產品組同事內部集體Review——指導產品團隊持續的完善需求、聚類整理需求、有序解決需求。如有必要還需與業務領導一起討論技術開發是否有必要或者啟動優先順序及時間視窗設定。

B類需求池原則上是所有產品經理對自己負責模組的維護。大家會問，這兩個是否重，是否存在需求不一致呢？

答案是“一定會”，但是，並非簡單意義上的“重複”，我們姑且可以把B類需求池作為自己的賬本，自己的賬本應該和大賬本保持同步，但是自己的賬本的側重點是更敏捷、更系統、更細膩——方便自己心中有本賬。

無論是A類需求還是B類需求，都遵循“實時記錄”、“及時整理”、“定期覆盤”、“干係人共識”、“狀態更新”。

無論是A類需求還是B類需求，在資訊處理時，都應該有如下幾個必備欄位：“提出人”、“問題描述”、“問題歸屬”、“問題性質”、“優先順序”、“版本規劃”、“狀態”、“責任人”。不同團隊，不同個人習慣可以略有不同，示例如下：

三個版本的Featulist

基於上述Roadmap的“明線指導”和產品功能矩陣規劃的“暗線指導”，結合上述需求池的原始線索，我們需要梳理出下個版本要解決的問題，並基於可投入的研發資源及時間視窗設定下個版本的Featurelist。

相對產品功能矩陣表，Featurelist的粒度要更細。具體哪些需求可進入Featurelist，可以同大家分享我的一些實務經驗：

如果是運營類需求，Featurelist包含兩個維度：運營面上的功能需求點+產品內部相關聯動點；

如果是產品類需求，Featurelist包含兩個維度：主功能點佔比80%+使用者體驗最佳化點：佔比20%。

為了將產品經理從需求應付中解放出來，發揮我們的產品owner原始價值，我的操盤經驗一般是採用三段式，也即研發一版、設計一版、規劃一版。

研發一版：當前研發團隊正在進行的，產品的時間投入基本分佈在如下幾個場景：文件動態更新、研發動態支援、專案進度動態跟進、測試驗收、上線培訓等工作，這些場景的特點是：瑣碎、緊急。

設計一版：是我們提前對已共識要乾的下個小Roadmap進行拆分設計，也是研發前期產品擁有最寶貴的靜態時間視窗期。

這個場景的特點是：產品內部方案論證、產品內部評審、需求方二次確認、必要的前置視覺啟動等。設計一版也是最考驗產品經理能力的，出色的產品經理可以很好的做好時間視窗把握，幫公司和團隊節省巨大的人力資源。

規劃一版：更多是提前思考下下個版本應該做哪些、相對大Roadmap我們進度有哪些偏差、是否有最新的需求或市場變化需要考慮進來，帶有較大的不確定性。

除此之外，出色的產品經理還要做到如下兩件事：透過提前思考來逆向指導“設計一版”的邏輯擴充套件性和方案策略的合理性，二一個是與業務體系進行論證、明確哪個部門的優先順序高，哪個需求優先順序高，並向外部提前一個月同步一個月後的預定攻擊目標和預期交付成果，進而避免業務追著產品問，我的XX需求啥時候做？我的XX需求啥進度了？你們下一步打算做什麼？

定期Review：迴應需求方關切+明確行動共識+再次澄清需求

需求池有了、版本規劃有了、產品設計也幹了、研發也吭哧吭哧啟動了，這麼多需求，我們的資源有限，時間有限，不可能全部做完，也不可能一步到位。而我們的老闆、我們的需求方是不清楚我們在幹什麼的？

這就需要產品經理需要做如下事情：

啟動前與需求方再次明確共識：哪個優先順序高、哪個優先順序低、大的策略框架、預期可達到的效果是。

demo文件設計完後要與干係人確認，進一步澄清需求是否符合預期，避免研發進行中變更或者上線後推到重來。

每週小通報、每月大通報，向干係人通報Roadmap的整體進度、當前在途專案的進度以及干擾事項、前置協作等資訊。

產品設計：目標訴求、干係人、業務場景、需求邊界、業務鏈路、產品架構目標訴求、干係人、業務場景

我撰寫PRD有個習慣，也即每個功能模組、每個頁面，花時間撰寫“業務場景、目標使用者、設計訴求、設計策略、背景說明”等資訊，基於上述背景，在整理需求會讓自己的思路清晰、考慮系統、方法得體，還有個好處是避免遺漏。

當然了、C端產品相對比較簡單，這些步驟的價值沒有B斷產品明顯，示例如下：

業務鏈路的設計策略及實戰case

產品經理千萬不能接到需求上來就畫原型，鑽入細節，而是先調研業務、靜下心來思考人，然後用手畫出業務鏈路圖。畫完業務鏈路圖後再自行推敲是否合理，正向的、逆向的、約束條件、分支條件等是否都考慮到了，業務鏈路是否有遺漏、業務鏈路能否再簡化，現有功能如何自然演進。

上述基礎工作做完之後，再結合前述的功能矩陣圖二次推敲、調整。

二次推敲完之後，再與業務方、干係人討論、看下是否有遺漏，如無遺漏方可開展原型撰寫。這裡有個坑，業務方並非只是領導，還要邀請實際使用者參與討論，避免我們閉門造車或遺漏業務中的特殊規則等。

產品架構設計策略及實戰case

產品架構是產品經理站在公司的業務、資源和時間三個維度，統籌考慮當前產品的業務架構、技術架構、研發平臺、先做哪些功能？再做哪些功能？各個功能模組之間的耦合解構關係、不同的研發小組分別並行或序列做哪些功能，最後有序會師等。

一方面考驗產品經理的過往大專案經驗沉澱能力；一方面考驗產品經理的業務理解深度；一方面考驗產品經理敢下功夫投入的系統思考的邏輯嚴謹性和前瞻預見性；一方面考驗產品經理的權衡決策能力；最後一個是考驗產品經理的落地執行能力。

徵詢討論：領導徵詢、業務方徵詢、技術組長征詢

心中裝有產品架構、在已達成共識的業務鏈路和Featurelist指導下，完成PRD初稿。

初稿更多的是頁面結構、資訊佈局、事件流轉的呈現，並不涉及研發層面的詳盡的邏輯註解。初稿自查無異議後，要與產品Leader內審，內審通過後再與需求方一起走檢視下是否符合預期，是否有遺漏的場景未覆蓋，產品策略是否合理等。

與業務方達成共識後，就部分高複雜業務或有一定技術難點的再與各組長進行逐一徵詢，提前獲取各技術組長的專業指導建議和方案認可，為後面的正式需求宣講掃清障礙。

立項圈人：畫餅、排期、立項、圈人

需求宣講完後，我們需要各研發組長在指定時間內基於Featurelist和PRD返回排期，如果資源有衝突，可以分組錯茬開發。

產品經理要利用好需求宣講這個舞臺的前、中、後三個場。

前場是畫餅，講這件事的背景、緊迫性和價值，用故事、段子、使命等將大家從其它陣地帶入到我們的陣地。

中場就是我們最拿手的需求宣講，千萬不要搞砸了，注意順序“功能矩陣”>“業務鏈路”>“具體模組”>”全域性潛規則”，最後來個虛心請教是否有遺漏，請在座的研發、測試專家們“扔磚”~

後場就是再次重申，決戰開始，此刻起兄弟們都歸我管了，立項後誰的需求都不能接了，誰敢私自接需求，咱們週會上刀槍相見~

風險化解：真誠幹練、更新同步、每週Review+進度通報

人無完人，再大神級的RPD也會有瑕疵，此時我們要做的就是釋疑、補充、完善。

從業秘訣如下：

千萬要真誠、千萬要真誠、千萬要真誠

千萬要幹練、千萬要幹練、千萬要幹練

千萬要及時更新文件、千萬要及時更新文件、千萬要及時更新文件。

及時組織或協助組織專案進度Review，每週一次，會上就幹三件事：進度驅動、協調協同、風險披露。

驗收交付：標準對照、需求池更新、資料初始化、運營客服培訓標準對照

時間充足：從大到小、事無鉅細，分層推進；

時間緊張：關鍵業務點體驗，其它交給業務方和測試兄弟把關。

需求池更新

基於研發測試進行中暴漏的問題，動態更新我們的需求池、及潛在版本的Feturelist。

資料初始化

永遠記住，資料初始化是一個標準動作，永不可忘記。基於此倒排，我們的資料初始化策略和前置準備工作。

運營客服培訓

領導一句話，產品一拍兄，研發一把淚，事終於成了。

但我們要對運營同學、客服同學進行系統的培訓。

培訓秘訣：概念匯入；業務鏈路串講；具體操作演示；操作手冊。

以上是自己在產品中的一些實踐總結，限於文采拙劣和時間有限，未能精細呈現，海涵。文中所述觀點不當的，希望廣大產品同仁不吝拍磚，共同提高。

不同的產品團隊、不同的崗位角色，會導致我們的分工不同，以上很多場景可能不涉足或不主控，但萬變不離其宗，方法相同，只要我們有產品盤感、業務敏感、邏輯嚴謹、靈通好學、幹練帶風、狠下功夫，放到哪我們都一樣熠熠生輝。

產品之路很艱辛，也更能鍛鍊人！在此祝廣大產品兄弟姐妹們不辱“產品”之title，做出好產品！

題圖來自Unsplash，基於CC0協議