大家好，現(xiàn)將我過往工作中的在產(chǎn)品層面的一些方法論和實證經(jīng)驗整理分享給大家，方便產(chǎn)品同仁交流學(xué)習(xí)。

本篇是同產(chǎn)品同學(xué)分享我自己在需求提取、需求翻譯、需求管理、需求設(shè)計、需求驅(qū)動、需求交付方面的一些實踐經(jīng)驗，希望通過此篇文章幫助初中級產(chǎn)品從業(yè)者優(yōu)雅的駕馭需求，進而做到從容應(yīng)對雜亂無章的無序需求，對上游需方兄弟做到強有力的專家支持，對下游研發(fā)兄弟做到專業(yè)有序的統(tǒng)籌調(diào)度。

下沉到業(yè)務(wù)中+業(yè)務(wù)敏感

再牛的產(chǎn)品經(jīng)理也需要了解業(yè)務(wù)，不了解業(yè)務(wù)能力再強也容易閉門造車。只有當(dāng)我們?nèi)谌霕I(yè)務(wù)，了解業(yè)務(wù)，才能時刻保持業(yè)務(wù)敏感。

當(dāng)我們下沉到業(yè)務(wù)中，我們才能深刻的、系統(tǒng)的、橫向的、縱向的感知業(yè)務(wù)當(dāng)前存在的問題、潛在發(fā)生的問題、以及相關(guān)問題背后的上下文“語境”。

所謂業(yè)務(wù)敏感，可以用如下幾個場景來表達：

• 場景1：當(dāng)業(yè)務(wù)兄弟或業(yè)務(wù)領(lǐng)導(dǎo)與我們討論某個業(yè)務(wù)“表象問題”時，我們能立刻同頻、入鏡，并能用業(yè)務(wù)語言與當(dāng)事人進行流暢交流，同時我們還能就“表象問題”挖掘出深層的問題或業(yè)務(wù)或老板背后的潛在訴求，以及相應(yīng)的解決策略。
• 場景2：我們要接受某個任務(wù)或解決某一具體問題時，我們心中有大盤，能夠站在整個平臺的角度思考問題、制定解決方案，避免掉坑里。
• 場景3：工作業(yè)余之外，作為產(chǎn)品的天生的好奇心能夠?qū)⑼獠康?、行業(yè)內(nèi)的、行業(yè)外的看似無關(guān)的東西引入業(yè)務(wù)內(nèi)，推動業(yè)務(wù)的良性創(chuàng)新、演變。

熱愛你的產(chǎn)品+持續(xù)的業(yè)務(wù)思考

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

當(dāng)我們持續(xù)的關(guān)注、思考我們的產(chǎn)品時，用戶反饋給我們的問題，我們基本上已經(jīng)提前知道，或者已經(jīng)有排期或者有考慮。我們能走在用戶的前面，更大概率的提前發(fā)現(xiàn)問題，即使我們明知道短期內(nèi)無法解決，但我們有對應(yīng)的非開發(fā)策略予以補位，如我們的幫助手冊，如我們的排期計劃，如我們的業(yè)務(wù)邊界…

4份Excel文檔：Roadmap+功能矩陣+3個版本的Featurelist+需求池

Roadmap的設(shè)計策略及實戰(zhàn)case

Roadmap是以實現(xiàn)公司戰(zhàn)略目標(biāo)為原則來確定我們產(chǎn)品建設(shè)的中長期指導(dǎo)計劃，不同級別、不同階段有不同的粒度尺度把握。

一份優(yōu)雅的Roadmap需要具備如下幾個要素：

1. 以經(jīng)營目標(biāo)為指導(dǎo)；
2. 明確的時間窗口；
3. 明確的業(yè)務(wù)場景、及業(yè)務(wù)目標(biāo)；
4. 邏輯演進的自洽；
5. 基于公司現(xiàn)況的可承受的研發(fā)資源投入；
6. 決策層共識與認(rèn)可。

功能矩陣的設(shè)計策略及實戰(zhàn)case

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

• 區(qū)別一：功能矩陣更偏“矩陣”、更弱“時間”；
• 區(qū)別二：功能矩陣相比Roadmap，我們更習(xí)慣用“優(yōu)先級”、“狀態(tài)”來表述，而Roadmap里的優(yōu)先級基本一樣，只是時間窗口的設(shè)置問題。

換句話說，功能矩陣是產(chǎn)品經(jīng)理通過“自下而上”的內(nèi)生動力,以暗線方式推動產(chǎn)品迭代演進。Roadmap是產(chǎn)品經(jīng)理通過“自上而下”的外在框架指導(dǎo)，以明線方式推動產(chǎn)品迭代演進。Roadmap體現(xiàn)的是公司的戰(zhàn)略意圖，功能矩陣提現(xiàn)的是產(chǎn)品經(jīng)理對產(chǎn)品的深度思考和排兵布陣。

需求池：采集、梳理、更新策略及實戰(zhàn)case

產(chǎn)品經(jīng)理打交道最多的就是需求，面對來自各方雜亂無章的需求，我們需要進行統(tǒng)一管理?；诜謱咏M織架構(gòu)，實踐中我認(rèn)為比較好的采用AB結(jié)構(gòu)。

A類需求池原則上是產(chǎn)品總監(jiān)或一級產(chǎn)品負(fù)責(zé)人維護，A類需求池需要向產(chǎn)品內(nèi)部進行實時同步、隨時查閱、協(xié)同編輯，共同維護，作為團隊的“公有資源”使用。實務(wù)中，產(chǎn)品總監(jiān)或一級產(chǎn)品負(fù)責(zé)人需要每周、每月、每季度與產(chǎn)品組同事內(nèi)部集體Review——指導(dǎo)產(chǎn)品團隊持續(xù)的完善需求、聚類整理需求、有序解決需求。如有必要還需與業(yè)務(wù)領(lǐng)導(dǎo)一起討論技術(shù)開發(fā)是否有必要或者啟動優(yōu)先級及時間窗口設(shè)定。

B類需求池原則上是所有產(chǎn)品經(jīng)理對自己負(fù)責(zé)模塊的維護。大家會問，這兩個是否重，是否存在需求不一致呢？

答案是“一定會”，但是，并非簡單意義上的“重復(fù)”，我們姑且可以把B類需求池作為自己的賬本，自己的賬本應(yīng)該和大賬本保持同步，但是自己的賬本的側(cè)重點是更敏捷、更系統(tǒng)、更細(xì)膩——方便自己心中有本賬。

無論是A類需求還是B類需求，都遵循“實時記錄”、“及時整理”、“定期復(fù)盤”、“干系人共識”、“狀態(tài)更新”。

無論是A類需求還是B類需求，在信息處理時，都應(yīng)該有如下幾個必備字段：“提出人”、“問題描述”、“問題歸屬”、“問題性質(zhì)”、“優(yōu)先級”、“版本規(guī)劃”、“狀態(tài)”、“責(zé)任人”。不同團隊，不同個人習(xí)慣可以略有不同，示例如下：

三個版本的Featulist

基于上述Roadmap的“明線指導(dǎo)”和產(chǎn)品功能矩陣規(guī)劃的“暗線指導(dǎo)”，結(jié)合上述需求池的原始線索，我們需要梳理出下個版本要解決的問題，并基于可投入的研發(fā)資源及時間窗口設(shè)置下個版本的Featurelist。

相對產(chǎn)品功能矩陣表，F(xiàn)eaturelist的粒度要更細(xì)。具體哪些需求可進入Featurelist，可以同大家分享我的一些實務(wù)經(jīng)驗：

• 如果是運營類需求，F(xiàn)eaturelist包含兩個維度：運營面上的功能需求點+產(chǎn)品內(nèi)部相關(guān)聯(lián)動點；
• 如果是產(chǎn)品類需求，F(xiàn)eaturelist包含兩個維度：主功能點占比80%+用戶體驗（含bug修復(fù)）優(yōu)化點：占比20%。

為了將產(chǎn)品經(jīng)理從需求應(yīng)付中解放出來，發(fā)揮我們的產(chǎn)品owner原始價值，我的操盤經(jīng)驗一般是采用三段式，也即研發(fā)一版、設(shè)計一版、規(guī)劃一版。

研發(fā)一版：當(dāng)前研發(fā)團隊正在進行的，產(chǎn)品的時間投入基本分布在如下幾個場景：文檔動態(tài)更新、研發(fā)動態(tài)支持、項目進度動態(tài)跟進、測試驗收、上線培訓(xùn)等工作，這些場景的特點是：瑣碎、緊急。

設(shè)計一版：是我們提前對已共識要干的下個小Roadmap進行拆分設(shè)計，也是研發(fā)前期產(chǎn)品擁有最寶貴的靜態(tài)時間窗口期。

這個場景的特點是：產(chǎn)品內(nèi)部方案論證、產(chǎn)品內(nèi)部評審、需求方二次確認(rèn)、必要的前置視覺啟動等。設(shè)計一版也是最考驗產(chǎn)品經(jīng)理能力的，出色的產(chǎn)品經(jīng)理可以很好的做好時間窗口把握，幫公司和團隊節(jié)省巨大的人力資源（不是產(chǎn)品經(jīng)理自己，而是整個下游團隊的靜態(tài)等待時間）。

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

除此之外，出色的產(chǎn)品經(jīng)理還要做到如下兩件事：通過提前思考來逆向指導(dǎo)“設(shè)計一版”的邏輯擴展性和方案策略的合理性，二一個是與業(yè)務(wù)體系進行論證、明確哪個部門的優(yōu)先級高，哪個需求優(yōu)先級高，并向外部提前一個月同步一個月后的預(yù)定攻擊目標(biāo)和預(yù)期交付成果，進而避免業(yè)務(wù)追著產(chǎn)品問，我的XX需求啥時候做？我的XX需求啥進度了？你們下一步打算做什么？

定期Review：回應(yīng)需求方關(guān)切+明確行動共識+再次澄清需求

需求池有了、版本規(guī)劃有了、產(chǎn)品設(shè)計也干了、研發(fā)也吭哧吭哧啟動了，這么多需求，我們的資源有限，時間有限，不可能全部做完，也不可能一步到位。而我們的老板、我們的需求方（內(nèi)部各業(yè)務(wù)方）是不清楚我們在干什么的？

這就需要產(chǎn)品經(jīng)理需要做如下事情：

1. 啟動前與需求方再次明確共識：哪個優(yōu)先級高、哪個優(yōu)先級低、大的策略框架、預(yù)期可達到的效果是。
2. demo文檔設(shè)計完后要與干系人確認(rèn)，進一步澄清需求是否符合預(yù)期，避免研發(fā)進行中變更或者上線后推到重來。
3. 每周小通報、每月大通報，向干系人通報Roadmap的整體進度、當(dāng)前在途項目的進度以及干擾事項、前置協(xié)作等信息。

產(chǎn)品設(shè)計：目標(biāo)訴求、干系人、業(yè)務(wù)場景、需求邊界、業(yè)務(wù)鏈路、產(chǎn)品架構(gòu)

目標(biāo)訴求、干系人、業(yè)務(wù)場景

我撰寫PRD有個習(xí)慣，也即每個功能模塊、每個頁面（敏捷需求或時間不允許時省去），花時間撰寫（思考梳理）“業(yè)務(wù)場景、目標(biāo)用戶、設(shè)計訴求、設(shè)計策略、背景說明”等信息，基于上述背景，在整理需求會讓自己的思路清晰、考慮系統(tǒng)、方法得體，還有個好處是避免遺漏。

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

業(yè)務(wù)鏈路的設(shè)計策略及實戰(zhàn)case

產(chǎn)品經(jīng)理千萬不能接到需求上來就畫原型，鉆入細(xì)節(jié)，而是先調(diào)研業(yè)務(wù)、靜下心來思考人，然后用手（或工具）畫出業(yè)務(wù)鏈路圖。畫完業(yè)務(wù)鏈路圖后再自行推敲是否合理，正向的、逆向的、約束條件、分支條件等是否都考慮到了，業(yè)務(wù)鏈路是否有遺漏、業(yè)務(wù)鏈路能否再簡化，現(xiàn)有功能如何自然演進（如需）。

上述基礎(chǔ)工作做完之后，再結(jié)合前述的功能矩陣圖（如excel、如腦圖）二次推敲、調(diào)整。

二次推敲完之后，再與業(yè)務(wù)方、干系人討論、看下是否有遺漏，如無遺漏方可開展原型撰寫。這里有個坑，業(yè)務(wù)方并非只是領(lǐng)導(dǎo)，還要邀請實際使用者參與討論，避免我們閉門造車或遺漏業(yè)務(wù)中的特殊規(guī)則等。

產(chǎn)品架構(gòu)設(shè)計策略及實戰(zhàn)case

產(chǎn)品架構(gòu)是產(chǎn)品經(jīng)理站在公司的業(yè)務(wù)、資源和時間三個維度，統(tǒng)籌考慮當(dāng)前產(chǎn)品的業(yè)務(wù)架構(gòu)、技術(shù)架構(gòu)、研發(fā)平臺（客戶端還是小程序還是都干）、先做哪些功能？再做哪些功能？各個功能模塊之間的耦合解構(gòu)關(guān)系、不同的研發(fā)小組分別并行或串行做哪些功能，最后有序會師等。

一方面考驗產(chǎn)品經(jīng)理的過往大項目經(jīng)驗沉淀能力；一方面考驗產(chǎn)品經(jīng)理的業(yè)務(wù)理解深度；一方面考驗產(chǎn)品經(jīng)理敢下功夫投入的系統(tǒng)思考的邏輯嚴(yán)謹(jǐn)性和前瞻預(yù)見性；一方面考驗產(chǎn)品經(jīng)理的權(quán)衡決策能力；最后一個是考驗產(chǎn)品經(jīng)理的落地執(zhí)行能力。

征詢討論：領(lǐng)導(dǎo)征詢、業(yè)務(wù)方征詢、技術(shù)組長征詢

心中裝有產(chǎn)品架構(gòu)、在已達成共識的業(yè)務(wù)鏈路和Featurelist指導(dǎo)下，完成PRD（我習(xí)慣直接用原型，而非寫word）初稿。

初稿更多的是頁面結(jié)構(gòu)、信息布局、事件流轉(zhuǎn)的呈現(xiàn)，并不涉及研發(fā)層面的詳盡的邏輯注解。初稿自查無異議后，要與產(chǎn)品Leader（如無略）內(nèi)審，內(nèi)審?fù)ㄟ^后再與需求方一起走查看下是否符合預(yù)期，是否有遺漏的場景未覆蓋，產(chǎn)品策略是否合理等。

與業(yè)務(wù)方達成共識后，就部分高復(fù)雜業(yè)務(wù)或有一定技術(shù)難點的再與各組長進行逐一征詢，提前獲取各技術(shù)組長的專業(yè)指導(dǎo)建議和方案認(rèn)可，為后面的正式需求宣講掃清障礙。

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

需求宣講完后，我們需要各研發(fā)組長在指定時間內(nèi)（原則上不超過2工作日）基于Featurelist和PRD返回排期，如果資源有沖突，可以分組錯茬開發(fā)。

產(chǎn)品經(jīng)理要利用好需求宣講這個舞臺的前、中、后三個場。

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

中場就是我們最拿手的需求宣講，千萬不要搞砸了，注意順序“功能矩陣”>“業(yè)務(wù)鏈路”>“具體模塊”>”全局潛規(guī)則”，最后來個虛心請教是否有遺漏，請在座的研發(fā)、測試專家們“扔磚”~

后場就是再次重申，決戰(zhàn)開始，此刻起兄弟們都?xì)w我管了，立項后誰的需求都不能接了，誰敢私自接需求，咱們周會上刀槍相見~

風(fēng)險化解：真誠干練、更新同步、每周Review+進度通報

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

從業(yè)秘訣如下：

• 千萬要真誠、千萬要真誠、千萬要真誠
• 千萬要干練、千萬要干練、千萬要干練

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

備注：更新不代表立即上傳SVN，但每日必須同步一次。

及時組織或協(xié)助組織項目進度Review，每周一次，會上就干三件事：進度驅(qū)動、協(xié)調(diào)協(xié)同、風(fēng)險披露。

驗收交付：標(biāo)準(zhǔn)對照、需求池更新、數(shù)據(jù)初始化、運營客服培訓(xùn)

標(biāo)準(zhǔn)對照

時間充足：從大到?。ò茄笫[）、事無巨細(xì)（推土機），分層推進；

時間緊張：關(guān)鍵業(yè)務(wù)點體驗，其它交給業(yè)務(wù)方和測試兄弟把關(guān)。

需求池更新

基于研發(fā)測試進行中暴漏的問題，動態(tài)更新我們的需求池、及潛在版本的Feturelist。

數(shù)據(jù)初始化

永遠(yuǎn)記住，數(shù)據(jù)初始化是一個標(biāo)準(zhǔn)動作，永不可忘記。基于此倒排，我們的數(shù)據(jù)初始化策略和前置準(zhǔn)備工作。

運營客服培訓(xùn)

領(lǐng)導(dǎo)一句話，產(chǎn)品一拍兄，研發(fā)一把淚，事終于成了。

但我們要對運營同學(xué)、客服同學(xué)進行系統(tǒng)的培訓(xùn)。

培訓(xùn)秘訣：概念導(dǎo)入；業(yè)務(wù)鏈路串講；具體操作演示；操作手冊。

以上是自己在產(chǎn)品中的一些實踐總結(jié)，限于文采拙劣和時間有限，未能精細(xì)呈現(xiàn)，海涵。文中所述觀點不當(dāng)?shù)?，希望廣大產(chǎn)品同仁不吝拍磚，共同提高。

不同的產(chǎn)品團隊、不同的崗位角色，會導(dǎo)致我們的分工不同，以上很多場景可能不涉足或不主控，但萬變不離其宗，方法相同，只要我們有產(chǎn)品盤感、業(yè)務(wù)敏感、邏輯嚴(yán)謹(jǐn)、靈通好學(xué)、干練帶風(fēng)、狠下功夫，放到哪我們都一樣熠熠生輝。

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

作者：九天牧人，個人微信unifarm

本文由 @九天牧人 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議