一、前言
本文總結了之前工作中，是如何完成需求方向確定，PRD編輯，需求評審，產研高效協作和復盤總結的，希望看完這篇文章後，讀者朋友都可以在當前團隊試用這套產品管理方法，一些產品新人可以了解到如何做產品規劃 ，如何寫出一份結構完整的prd，如何應用靜默評審提升評審/會議效率，如何做復盤總結。
（因作者只在飛書產品線工作，受限於個人能力和視野局限，文中內容既不能代表飛書更不能代表字節，僅是個人對過去一年多的復盤思考，不足之處歡迎評論區拍磚交流。）
二、產品規劃、落地和復盤
任何方法都有適用場景，個人感覺飛書的需求管理更適合於to C的產品，而且一定程度上產品經理要有主導權，pm可以有效的控制節奏，如果是業務主導的隨時插入需求的團隊並不是很適用，如前文所說，產品的規劃是按照雙月緯度去推進的，雖然會有偶爾插入需求的情況，但是大多數需求都是在雙月會上拉齊不同團隊間的認知，協調好跨團隊的資源，按照節奏進入產研流程中。
2.1 產品規劃-one page prerelease
前文中提到，我在飛書的時候，團隊是有年度規劃復盤會和雙月規劃復盤會。當產品定位確定，年度目標和方向給出後，雙月的規劃會更多的是一個目標拆解的過程中的中間環節，它連接著年度目標和具體落地方案，即是年度目標的細化，也是對具體方案的抽象。
一個完整功能的一頁紙即可，以開發布會的視角去抽象和組織信息，以純用戶視角去編輯內容，需要體現產品的用戶價值，one page prerelease內容上主要包含三個部分，標題，2-4個簡短說明，一張示例圖，如果需要可以補充一段注釋。
標題。 一句話說明功能提供給用戶的最主要價值是什麼
說明。 簡要介紹這個功能是什麼，如何幫助用戶提升哪方面的效率，如果有數據可以寫上預計對核心指標的影響
示例圖。 可以是低保真示意圖，也可以是高保真效果圖，還可以是競品或相關產品的拼接圖，核心是體現出這個功能未來可能是什麼樣子的，價值是什麼
可以多看蘋果和google的發布會，如何用一頁ppt對一個產品的核心價值做抽象，喬幫主的發布會值得反覆學習，不堆砌硬體指標，用與用戶相關的數據震撼觀眾，用一張圖加一段文字，甚至只是一張圖，讓觀眾為之瘋狂。
因為底層上來說，雙月會上是爭取團隊資源做目標功能的評審會，需要大家認同當前做這個功能是有意義或價值的，所以在編輯內容過程中，需要對目標用戶價值做出抽象，同時要符合產品定位和年度目標，當然所在領域的頭部競品和相關領域的頭部產品都可以是思路來源，比如gmail的年度發布會說了什麼，微軟在企業知識圖譜上即將上線哪些功能，在這個階段需要pm既要向外看，看市場的同類產品的規劃方向，也要向內看，做功能抽象和用戶價值提煉。其實任何職級的PM都可以考慮試用一下，對當前所負責的功能進行一頁紙規劃抽象，可以想像一下你正在發布會上介紹這個功能，如何做才有可能讓用戶為其買單，有助於提升抽象能力，提升產品看問題的高度。
2.2 產品方案落地-PRD
飛書的PRD模板在結構上感覺比較合理，具體結構和說明如下圖所示：
下面詳細敘述一下這套模板。模板可以看做是一套思維範式，可以統一團隊看問題的視角和思考模式，一份結構合理而完整的PRD模板可以幫助創作者聚焦問題並發散思路，當團隊中所有人用一套模板時，有利於評審時文檔閱讀者快速檢索定位到自己的目標信息。
相關人員。 介紹清楚功能需求的相關方，包括產品Owner，相關PM，設計師，UX，研發leader，研發同學，算法leader，算法同學，前端，後端，SDK等。如果存在跨業務線的情況需要把相關同學全部寫明，方便後續溝通復盤。
評審記錄 。因為一個需求有可能內部多輪評審，包括跟老闆的評審，都會有一些重要的修改方向，通過評審記錄完成關鍵意見和方向記錄，因為通過靜默評審答疑會在文檔右側的區域進行評論交流，所以評審記錄更多是對每一次評審中重大改動意見的記錄。
Change Log。 因為會有可能出現多次修改，包括文字，原型圖片等，包括進入測試環節的一些邏輯補全，都需要以表格的形式記錄好，方便研發和測試同學查看。
名詞解釋。 文檔中可能包含一些需要說明的企業黑話或專有名詞解釋，方便非內部團隊同學閱讀文檔，比如一些常規搜索評估指標，MRR，topN有點比，NDCG等
背景。 用文字清晰的描述需求的背景信息，如果已有功能的優化，可以將數據看板掛在背景模塊，背影模塊需要寫明為什麼做這個這個功能，用戶價值是什麼，公司價值是什麼，對齊那個年度或閱讀OKR。
目標用戶。 包括主要用戶，次要用戶，關鍵用戶，負面用戶
用戶場景。 用實際的案例描述用戶場景，比如小王在什麼情況有什麼訴求
產品方案：
參考資料：
當負責一些比較大型的項目，受限於當前技術能力或技術資源，需求需要拆分成多期落地實現時，微軟的PRD模板比較好用，這是我在貝殼這邊學到的，同樣分享給大家。
Document Properties
Abstract。 對功能的頂層抽象，抽象出系統或功能的主要價值，一般3-5點。有點像是雙月會上的產品用戶價值，同時說明系統/功能對公司的價值，可以按照1分鐘電梯演講提煉和抽象內容。
User Scenario。 描述清楚用戶場景，同上文中的用戶場景
Feature Requirements 。明確列出功能需求，並且給出評級，通過p0s0-p2s2定義產品功能重要程度，通過功能列表的定義，確定哪些功能當前重要緊急，方便切分版本。
Scope for this wave。根據上面的評分，確定哪些功能在這一期的範圍內，哪些不在。
Detailed Design。同上文的產品方案
與字節prd模板有以下幾點差異，對功能的優先級和重要程度界定，方便後續版本管理和規劃。
幾個重點：
1、多思考，多問為什麼 。剛開始做產品經理的時候很容易憑感覺設計，感覺應該怎樣就怎樣，prd模板就是一套思考範式，梳理清楚背景，描述清晰的用戶場景，明確要解決的問題，定義精確的目標，同時對競品有深入的理解和調研，再來設計產品，這些前置的準備其實就是我們這個功能為什麼這樣設計的原因。而且因為評審方式的原因，就需要提前切換成文檔的讀者模式，看一下哪些點可能有疑惑。同時，為了防止評審中被challenge的尷尬，所以需要提前自己多問自己為什麼這麼設計，你的設計是當前能找到的最好設計嗎？
2、終盤反推思維。 在飛書學到一個產品設計思考方法，在產品設計的時候可以一定程度上先跳過技術和人力壁壘，考慮最優的體驗應該是什麼樣的，然後在根據當前的實際能力和人力，去做方案降級，這樣我們能確保產品的方向是對的，同時設計上可以更好的兼容未來的優化，不太會出現全盤推翻重做的情況。
2.3 產品復盤
不知道大家發現沒有，每次我們準備跳槽面試的時候，我們往往會有一波感知明顯的能力提升，因為我們需要對自己過去一段時間的工作進行系統性的梳理，這個過程伴隨著歸納總結，並且找到一些數據去佐證自己的價值，為談薪獲取籌碼。
筆者認為，產品的設計能力提升需要做定期的復盤，復盤包括幾個方面：用戶問題反饋，目標用戶訪談和數據分析，因為飛書會有雙月規劃復盤會和年度規劃復盤會，所以有一個機制幫助產品定期對自己所負責功能進行總結反思。
用戶問題反饋。 上線後會收到字節同學在bug或問題反饋群中提的意見，復盤中需要將這些問題梳理出來，確定是設計問題還是系統bug，並且與反饋問題的同學交流溝通，挖掘問題背後的訴求。
目標用戶訪談。 除了做問題反饋用戶的訪談外，還需要做目標用戶的訪談，關於目標用戶訪談的方法網上有不少，就不在這塊贅述，在雙月會的匯報文檔中可以將這部分內容放在相關文檔出處，歸納提煉出來的一些意見可以放到正文中。
數據分析。 數據可以一定程度上真實反應用戶的行為，所以所有功能上線前均需要做完善的埋點設計，方便分析用操作行為，輔助產品優化方案，監控問題，在復盤時可以作為量化的指標，防止大家憑感覺給反饋。準確的數據埋點是公司寶貴的數據資產，通常來說，在沒有做基於數據模型驅動用戶行為的設計時，往往前端用戶埋點會非常混亂，導致即使有算法工程師介入，也只能服務端取業務數據，行為數據無法使用，還需要長時間的補埋點，積累數據後，才能獲取到準確的數據，歷史用戶行為數據往往無法使用，這是一種極大的浪費，後面計劃寫一篇文章，總結一下我在這塊的思考總結，感興趣的朋友可以提前關注哈。
三、需求評審
現在發現並不是所有的公司的產品方案都會有一個嚴格的內部評審機制，飛書的評審機制比較完整，分享給大家。
第一輪，雙月會上基於prerealease完成優先級拉齊
第二輪，產品團隊內部的評審(複雜方案會切分成多輪多次評審)
第三輪，內部討論一致的方案跟老闆和各團隊一起評審
第四輪，拿著產品團隊對齊的方案跟研發評審排期
過程中都會與對應的engineer leader持續交流，會不斷打磨產品方案。個人感覺上，這個過程是對產品來說壓力最大也是提升最大的，後面換了新的產品老大，流程上做了一些調整，上了一套系統去管理需求，將產品上線相關的所有節點均包含在內，包括翻譯，法務，數據等，因為後面的流程我沒有走過，暫不做展開介紹。
3.1 向上-對功能的頂層抽象
因為需求評審的過程中會有高級別的老闆參與評審，這類評審可能不太關注具體細節的設計(也有可能非常非常非常關注字節)，但是會關注對功能場景的抽象是否準確和深入，用戶需求場景的本質模型是什麼？一些頂級競品如微軟的Team，Google G suite是如何做的，當前這個功能是否與其他非直接競品的底層邏輯一致，比如郵件服務是如何設計過濾器的，電商平臺是如何做信息篩選的，如何實現的重要信息標記、提取和顯示等，為了可以順利評審過關，PM需要做很多抽象工作，嘗試回答現實場景中，用戶需求的本質是什麼，類似訴求下當前的解決方案有哪些，哪些我們可以借鑑，進而去設計我們自己解決方案，當然有可能抽象錯了，也會在評審過程通過提問回答獲得糾正。
3.2 向下-每個設計點多次自我拷問-我為什麼這麼設計？
評審過程中先是小團隊內部多人評審，使用靜默評審的方式，對文檔中疑惑點或者問題點進行劃線提問，默讀過程中，功能owner先用文字回答問題，閱讀完成後開始以回答問題為主的評審，如果文字回答滿意可以不用複述問題，如果需要調整，評論下面創建todo。因為參與到評審中的角色會比較多(組內產品和小組leader，相關功能pm，數據同學，算法同學等)，所以在上評審之前需要自己問清楚自己為什麼這麼設計。包括但不限於互動設計，信息結構，競品設計，策略，埋點，指標等。
3.3 評審方式-靜默評審
上一篇文章中提到了整體操作流程，這次補上一些圖示
1、創建日程，將參加評審同學添加至日程，並編輯會議摘要，說明評審內容，參與者收到飛書push日程的消息，會議開始前X分鐘自動追加一個消息提醒
2、會議開始後，通過日程快速創建會議群，群內發出待評審PRD，大家在各自電腦打開閱讀文檔，對疑惑/質疑點時劃線編輯評論
3、一次PRD評審控制在45分鐘，PRD作者組織評審，一般會15分鐘閱讀文檔，過程中PRD作者通過文字回答評論提問，閱讀完成後文檔底部點讚代表閱讀完成，多數人點讚後開始對評論答疑討論，並記錄todo
好處：
1、通過閱讀而不是presentation展開方案討論，讓評審更客觀，不會被演講者帶節奏；
2、要求文檔邏輯更加清晰簡潔（15分鐘可以讀完）；
3、評審過程基於問答更加聚焦，不容易跑題；
4、問答過程記錄在文檔評論區，同時記錄todo，節省部分會後整理會議紀要時間
看到這裡，你可能會推理出飛書的評審會非常多，一個功能的迭代有可能多輪評審，而團隊中每個成員還需要參與到組內或組間其他人的需求評審，所以評審比較耗時，我的理解是飛書的產品設計過程通過這種評審會(30到45分鐘的評審會)，讓想法充分交流，評審過程中的靜默問答模式讓產品對自己的方案更加負責，上線前長時間的內部灰度確保產品質量，所以這麼多倫的評審也不是適用於所有組織和團隊，但是這個過程中形成的壓力會磨練pm做更深層的抽象，對每個細節都有充分的考量，長期訓練下來，有助於形成產品體感，而且評審過程中會看到高級別的pm如何提問，能問出好的問題是非常非常重要的。愛因斯坦曾經說過：「提出一個問題比解決一個問題更重要」。而靜默評審是一個幫助低階產品學習高階產品如何看產品，如何提問題的非常好的學習場景。
四、高效協作
其實網上一直流傳著產品和研發水火難容的故事，之前的公司中，與研發配合時感覺還好，都能很快跟開發打成一片，和小自己10幾年的研發同學稱兄道弟，在58和字節的時候，都會有一個小圈子，也可以稱為產品的智囊團，先有產品證明自己的專業性，同時找到想把事情做好的關鍵成員，PM說要做什麼功能給出方案，前後端研發，算法，設計會幫著看方案是否有可以優化的點，哪裡有漏洞幫我想到，研發主動提出更好的技術實現方案，大家為了把事情做成做好而愉快配合，也會遇到不好溝通的研發，但總能找到突破口，但最近因為配合的產研團隊都在其他城市，所以遇到了一些協作問題，這讓我開始思考，為什麼會有這種情況出現，是否有什麼機制可以一定程度解決這個問題？感覺在58的時候是運氣比較好，遇到了靠譜的同學，而字節是有一套機制和文化讓人變得靠譜。
本質上來說，產品經理和研發，設計，算法等工作性質不太一樣，也就是為啥pm剛出來就是"經理"的原因，因為我們輸出文檔和原型，具體實現都是研發，設計和算法來落地，我們的價值是通過合作方來實現的，而且一般情況下產品會對產出負責，就如同西遊記中師徒四人，產研協作中，產品就如同唐僧，經常說的就是：「我要什麼」，具體都要看孫悟空們落地，而這個過程中往往是產品經理扛著老闆的壓力和業務的壓力，要給孫悟空們壓時間和提意見，工齡長了之後，其實研發容易從對事情負責變成對任務負責，產品給出要給出沒有問題的需求，研發不出bug的實現，一旦看到有問題的方案就會開懟，筆者認為最底層上來看，這是把事做成做好的壓力沒有傳達到團隊成員的原因，更像是其他人在幫產品實現功能。如果希望團隊高效協作，需要保證團隊內部的成員大家對做成一個事情負責，而不是只對自己所負責的工作負責。
字節的解決方案時增加一個角色，項目級別團隊都會有一個engineer leader，這個角色不單單只是協調研發測試資源，組織站會，為團隊爭取留時間餘量和匯報進度，這個角色需要同產品owner高度配合，這個角色需要在研發評審前，和產品就產品方案達成一致，過程中可以提各種問題，但是對齊後，那麼方案的設計和落地就是兩人共擔，研發的老大開會的時候不會找產品，直接找對應的engineer leader，這個角色就是研發中的那個對項目結果負責的人，扛著對應的壓力，因為他是研發體系的人，在處理內部矛盾上比產品直接協調好很多，而且我發現，越是高階的研發負責人，越是懂業務，很多研發老闆同時負責產研團隊，換個角度來看，這種角色是研發負責人的種子。
五、Owner意識
之前和一個關係非常好朋友聊百度搜索廣告面對客戶需求，產品反應速度慢的問題(可能是有的產品哈)，因為字節也在做搜索廣告，所以有些類似的場景，面對客戶的一個需求，字節可能是對接人快速飛書建群，拉上相關產研同學，鎖定問題，討論方案，排期規劃，有可能1-2周內開發上線，效率非常高，百度有可能耗費更久的時間走流程，一個需求從一線到研發會經歷很多個角色，每個角色可能都有自己的考量。因為沒在百度待過，但是當時在字節的時候也有百度跳過來的同學，感覺投入度超高，非常有Owner意識，閒聊時他們會說在百度並不是這個狀態。從我對自己投入度復盤來看，字節讓我投入度超高主要有以下幾點原因：
1，承諾一致。 《說服力》和《細節》中提到了公開承諾的力量，因為人本能的會保持自己行為和承諾一致，可能是人類為了協作對抗危險，演化寫進我們基因中的一套底層編碼，還記得前文中提到年度，雙月，內部評審會嗎？因為字節在乎數據，所以大量功能都會提前做出數據目標承諾，在多輪需求溝通（公開承諾）後，沉沒成本不多增加，你會感覺這個需求或功能就是你的，千萬不能做砸了，進而會給自己持續增壓。
2，文化和價值觀改變行為-字節範兒。 當年的BAT三家巨頭中，阿里最講企業文化建設，組織中甚至有政委的角色，沒在阿里待過，但是從一些花邊新聞可以看出，阿里是一個非常重視價值觀和公司價值一致的公司，騰訊和百度似乎沒有這麼明顯，三家中阿里的強度和壓力也是最大的。字節沒有政委，但字節範兒就是字節的文化價值觀統一的密碼，每個公司都有自己的文化價值觀，但是字節範的落地是我見到最NB的，當前字節範包含六句話：「追求極致、務實敢為、開放謙遜、坦誠清晰、始終創業，多元兼容」，如何讓這麼抽象的概念深入人心，進而影響行為呢？通過大量的重複出現（辦公室牆上，會議室未接入屏幕，食堂電視，360環評，衛生間宣傳畫），來說兩個場景，360環評和衛生間宣傳畫。
衛生間宣傳畫。 在58我看到的衛生間「展示位」給了公司季度業績，猜測目標是為了激勵員工努力？回憶當時似乎沒有太強烈的感覺，在貝殼，看到的衛生間海報是介紹哪些行為不對，主強調正確行為引導。但是字節的衛生間海報就是宣傳公司核心價值觀-字節範兒，用漫畫的形式告訴這些抽象概念對應的是什麼行為，我在的這一年中經歷過一次海報替換，但最終換回了最初我入職的那一套，感覺這個真的能體現出字節範兒是什麼，大家可以感受一下。至少我感覺通過漫畫我能夠快速將字節範兒的抽象概念快速的與日常工作聯繫在一起了。
360環評。 在字節，試用期需要邀請其他人360環評，8月（年中）和3月（年終）會有360環評決定績效，環評中會需要對被測評人的字節範兒給出評分和描述，環評工具會舉例可以如何去寫，產品一般需要給20-50個合作方寫環評，所以這個過程中自己持續的給別人打環評的過程中，變向的也是在告訴自己什麼是公司鼓勵的行為，也是講抽象概念具象化到自己身邊同學行為的一個過程。
3，周圍同事都很拼。前文中提到了，評審會和討論會佔用大量的白天時間，雖然每個半小時到45分鐘，但是產品有整塊的時間還是要到晚上，因為字節有一個補貼政策，就是公司附近租房子有每月補貼1500元，所以很多同學都住得離公司特別近，而且字節的食堂，下午茶，晚上零食水果是真的香，所以基本上你會發現9點後很多人都不會走，也不著急走，而且確實又很多白天接回來的活要幹，所以就出現了大面積的加班。
4，雙月會匯報壓力。 在飛書經歷了兩個階段，第一個階段，飛書PM人數不多（60人左右），那時候的雙月會都是每個人去說明自己的上個雙月做了什麼功能，上線後數據表現如何，與之前的數據承諾有何差異，未達成的原因，優化的思路是什麼，雙月會上大家往往壓力報表。第二個階段，飛書的PM人數太多了，雙月會上是組長在替具體功能負責人解釋說明復盤內容。就是這一點改變，壓力指數會降低非常非常多。如果希望產品的投入度提升，可以考慮讓執行產品直接給老闆匯報，或者面對多人challenge的場景，匯報人的投入度和圍觀別人替自己匯報的投入度真的是完全不一樣。
六、其他
飛書的有些功能非常贊，所以有些離開字節的同學會抱怨沒辦法再用飛書特別遺憾，文末我想分享一個飛書的小功能，其中部分模塊我也有參與設計優化，真的感覺這個功能可以非常直觀的體現飛書的產品定位和目標，分享給大家，大家做產品的過程中可以做類似的思考和細節設計。
飛書定位就是解決團隊高效協同，希望讓用戶的每一次click都能是最快捷高效的，一次點擊，即使幫助用戶節省0.5秒，當一個企業每天幾萬人多次使用時，所節省出來的時間也將非常可觀。本文想要分享的小功能是飛書的一個全局功能@，在IM和文檔中可以快捷觸發。
先來描述IM協調溝通中的幾個辦公場景的痛點
經常需要在群聊中@群內某人/某些人，希望他們可以閱讀所發送的消息，當群聊人數較多時查找列表低效，搜索不夠高效
群聊中@的人，希望看到他們的閱讀狀態，而不是群全部已讀列表中查找，誰看了這條消息
與其他人單聊或群聊中，需要介紹某個會話/群外的人，這個時候輸入名字，擔心名字輸錯了尷尬，需要列表中查到對應的人，複製其姓名黏貼到對話中
當我在與A的會話中介紹了某件事情可以找B，那麼A同學還需要通過搜索去查找B同學，流程中有點繞，當超過萬人的集團公司，可能多個人都叫B的名字有可能還需要逐個看匯報線和部門
針對以上四個場景痛點，IM中的@功能完美解決上述問題。
群聊中點擊@後，飛書中優先展示可能@的人，當前來看，可能@的人點擊佔比與用戶搜索點擊佔比類似，top1和top3有點比非常高（也就是用戶觸發@後，直接點擊回車選中第一個推薦用戶或前三個用戶的佔比非常高），也就是節省了用戶手從鍵盤上轉移到滑鼠上，滾動滾輪檢索或錄入目標用戶姓名檢索的時間，點擊@直接點回車，那種爽感，用起來就知道有多香，因為這塊的規則策略我參與了設計優化，細節不便透露，大家也可以想一想，如果讓你做規則策略，你會如何設計，期待留言區看到你的答案。
企業微信中也能在群聊中@某人，但是如果想要查看已讀狀態需要點擊消息前方的氣泡查看，飛書這塊直接在@人的名字右上角有個空心氣泡，如果對方閱讀了，則變成綠色實心，目標用戶是否已讀一目了然
會話內可以@會話以外的人，比如我在和張三單聊，我直接@lisi，則觸發公司內搜人接口，可以直接選擇用戶後回車輸入，確保名字準確，如果李四是我的高頻聯繫人，甚至可能只輸入@l的時候就出現了李四的名字，因為針對人的搜索做了大量的搜索策略優化和算法優化
@李四後，@李四是一個可點擊結構化組件，張三可以直接點擊@李四，喚起李四的個人卡片，直接查看OKR或發起聊天
其他產品可復用的啟發：
首先需要明確你的產品目標是什麼，當你的產品目標有了，有哪些場景與這個核心目標相關，核心評估指標是什麼，這些都明確了，可以考慮從推薦策略，交互優化，場景痛點/癢點入手，能推薦準的不用用戶搜索，能直接點擊的絕對不讓用戶再去複製、黏貼、搜索，用戶在具體場景中期待看到什麼結果，如果可以直接展示的，絕對不讓用戶到其他地方用眼睛檢索。
希望本文對大家有所啟發和幫助，如果感覺還有些用處，記得收藏點讚哦~
來源 | 言之有術（ID：yanzhiyoushu）
作者 | PM田宇洲；編輯 | 雜蕪
內容僅代表作者獨立觀點，不代表早讀課立場。