在項目推進過程中， PRD的使用率和流通率都是比較高的， 那麼針對不同的人員， PRD都有什麼區別呢？
前言·PRD的定位PRD的可讀性很多產品經理在追求一個完美的PRD範本，
筆者認為， 傳統的PRD起到的是字典和記錄的角色定位。 但是產品經理作為最會說話的一個崗位， 將一份又臭又長的PRD直接丟給相關人員， 未免也有點失禮。
很多場景下， 產品經理的懶惰和不得其法， 給團隊增加了更多的溝通成本， 文檔的可讀性很低。
產品經理都會遇到什麼人？
作為產品經理來說， 最關鍵的就是目標使用者。
你的PRD也是一樣， 傳統的PRD冗長而複雜， 所以我們建議採用一種模組化思維， 梳理清楚每一部分的目標使用者， 給我們的PRD寫作一個全新的思路。
筆者將產品經理日常溝通方分為五大角色， 把他們劃分為PRD的目標使用者。 筆者認為：
BRD的主戰場適用於決策層面， 且具有更多保密性。 MRD是專案立項階段的整體規劃。 PRD是MRD的技術指標細化版。所以本文所探討的部分被劃歸為PRD的範疇內。 在項目推進過程中， PRD的使用率和流通率都是比較高的， 所以如何給對應的人看對應的PRD，
對BOSS層面的彙報工具我們推薦是PPT， 內容量在3-5張之間， 總共時間控制在15分鐘左右。
在專案推進過程中， 難免會有例會、週報或是短期彙報。 某世界50強公司的老闆會同時應對100多個專案， 而在他這個層面， 面對任何一個項目彙報，
最後再把要請示的事項重點突出一下， 做到有頭有尾， 這樣4部分內容， 就是一個基本的BOSS彙報思路。
素材上可以取PRD的介面效果圖、業務邏輯圖等部分， 以備跟BOSS突出講解以上內容。
設計師
對於設計師來講， 我們推薦用AXURE直接溝通， 主要提供線框圖+注釋， 還有整體的業務邏輯。
設計師要做的是在瞭解業務邏輯的情況下， 最大程度發貨他們在設計上的優勢。 所以如果不能清除瞭解項目， 就會導致設計師在設計上無從下手， 甚至做出的設計大相徑庭。
我曾經遇到一個案例， 一個產品經理跟設計師爭的面紅耳赤， 互相說對方不懂設計， 最後發現產品經理忘記了告訴設計師某某表格的比對邏輯， 當兩個人在業務上站在同一高度， 設計上很快也互相理解握手言和了。
所以對於設計師的溝通，一定要避免上述低級失誤的發生。要做好以下三點：
場景、功能邏輯、頁面流轉情況的解答元素、欄位、都要按實際生產資料來做案例和線框圖極端情況和限制條件等要交代清楚以上是設計師最關心的幾點內容，所以使用PRD內的原型和介面流轉圖部分是最高效的溝通方式。
研發對於研發來講，我們推薦用AXURE和EXCEL加流程圖來進行溝通。
對於前端研發，我們推薦給出效果圖後，跟設計師一起隨時進行走查以保證UIUE準確。
對於後端研發，建議一定要做好五點：
角色、系統、介面交互情況：在複雜系統的大公司，這個角色往往也有可能是BA/SA的角色在做。觸發條件和時序：是後端做業務邏輯的關鍵。細緻化描述：方便開發對工作量進行準確評估，安排研發資源。資料邏輯規則：可以用EXCEL進行整理，這是後端邏輯的關鍵。資料結果和介面：對於開放平臺會用到比較多，嚴格來講屬於資料產品經理的範疇。研發團隊追求的是技術上的攀登和實現上的快感，需要完整而嚴謹的細節，宏觀性的角度大多是背景瞭解，所以跟他們的交流一定要做到細化和有條理。推薦用PRD裡面的資料邏輯部分和導圖來交流溝通。
市場及運營對於市場和運營團隊，主要是對外的工作，所以最關鍵的是知己知彼。這時產品經理需要針對產品的場景和步驟圖對他們進行詳細的操作講解，這樣才能讓對外團隊深刻瞭解手中的武器，才能打勝仗。
建議使用PPT做一個清晰的場景步驟說明書，其中重點的功能點要特別提及，方便運營做資料埋點、活動策劃等動作。
所以在跟對外為主的部門打交道時，實現層面的東西可以少一點，要針對產品的可用性進行淋漓盡致的展現。
培訓及客服產品經理很多的回饋和建議是來自最底層使用者的。而且，小白用戶的初體驗往往也是檢驗我們設計合理性的關鍵。但是對於百萬量級以上的產品，如果這些回饋和溝通都由產品經理躬親為之，恐怕是會將產品經理變成救火經理了。
所以不管你有沒有客服或者培訓，都需要為小白使用者給出一份FAQ，或者給自己的郵箱設置一個套自動回復，將常規性的問題囊括在內，並指明責任人，這樣可以免去很多工作中低效的轉發動作。
你是產品經理，不是救火經理，也不是二傳手經理。
回溯·模組與效率對目標人群進行分析後，我們顯然可以發現一套完整的PRD結構：
要包含產品概述、流程圖、功能點的介面+場景+元素+邏輯、資料邏輯、操作手冊+測試用例+FAQ。
經過以上分析，相信我們在做PRD的時候，都會有場景化的意圖和理解。
針對實際情況，適合你的團隊所使用的PRD範本，相信也一目了然。
另外建議對於整合變更點，可以用注釋記錄在PRD上，這樣在寫日報週報的時候，會很省力。
綜上所述，本文一共闡述了兩種思想：
見人說人話：眾口難調，要入鄉隨俗，用可讀性來提高效率。模組化工作：清晰明白自己作品的側重點，方便模組化拆解以應對彙報和總結，節約歸檔時間。效率從功利性維度來分，可以被看做溝通和工作的整體，所以通過見人說人話減少不必要的溝通和摩擦，最快地進入狀態，永遠是每個人要好好練習的功課。
本文由 @花生醬先生 原創發佈于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Pexels，基於 CC0 協議
所以對於設計師的溝通，一定要避免上述低級失誤的發生。要做好以下三點：
場景、功能邏輯、頁面流轉情況的解答元素、欄位、都要按實際生產資料來做案例和線框圖極端情況和限制條件等要交代清楚以上是設計師最關心的幾點內容，所以使用PRD內的原型和介面流轉圖部分是最高效的溝通方式。
研發對於研發來講，我們推薦用AXURE和EXCEL加流程圖來進行溝通。
對於前端研發，我們推薦給出效果圖後，跟設計師一起隨時進行走查以保證UIUE準確。
對於後端研發，建議一定要做好五點：
角色、系統、介面交互情況：在複雜系統的大公司，這個角色往往也有可能是BA/SA的角色在做。觸發條件和時序：是後端做業務邏輯的關鍵。細緻化描述：方便開發對工作量進行準確評估，安排研發資源。資料邏輯規則：可以用EXCEL進行整理，這是後端邏輯的關鍵。資料結果和介面：對於開放平臺會用到比較多，嚴格來講屬於資料產品經理的範疇。研發團隊追求的是技術上的攀登和實現上的快感，需要完整而嚴謹的細節，宏觀性的角度大多是背景瞭解，所以跟他們的交流一定要做到細化和有條理。推薦用PRD裡面的資料邏輯部分和導圖來交流溝通。
市場及運營對於市場和運營團隊，主要是對外的工作，所以最關鍵的是知己知彼。這時產品經理需要針對產品的場景和步驟圖對他們進行詳細的操作講解，這樣才能讓對外團隊深刻瞭解手中的武器，才能打勝仗。
建議使用PPT做一個清晰的場景步驟說明書，其中重點的功能點要特別提及，方便運營做資料埋點、活動策劃等動作。
所以在跟對外為主的部門打交道時，實現層面的東西可以少一點，要針對產品的可用性進行淋漓盡致的展現。
培訓及客服產品經理很多的回饋和建議是來自最底層使用者的。而且，小白用戶的初體驗往往也是檢驗我們設計合理性的關鍵。但是對於百萬量級以上的產品，如果這些回饋和溝通都由產品經理躬親為之，恐怕是會將產品經理變成救火經理了。
所以不管你有沒有客服或者培訓，都需要為小白使用者給出一份FAQ，或者給自己的郵箱設置一個套自動回復，將常規性的問題囊括在內，並指明責任人，這樣可以免去很多工作中低效的轉發動作。
你是產品經理，不是救火經理，也不是二傳手經理。
回溯·模組與效率對目標人群進行分析後，我們顯然可以發現一套完整的PRD結構：
要包含產品概述、流程圖、功能點的介面+場景+元素+邏輯、資料邏輯、操作手冊+測試用例+FAQ。
經過以上分析，相信我們在做PRD的時候，都會有場景化的意圖和理解。
針對實際情況，適合你的團隊所使用的PRD範本，相信也一目了然。
另外建議對於整合變更點，可以用注釋記錄在PRD上，這樣在寫日報週報的時候，會很省力。
綜上所述，本文一共闡述了兩種思想：
見人說人話：眾口難調，要入鄉隨俗，用可讀性來提高效率。模組化工作：清晰明白自己作品的側重點，方便模組化拆解以應對彙報和總結，節約歸檔時間。效率從功利性維度來分，可以被看做溝通和工作的整體，所以通過見人說人話減少不必要的溝通和摩擦，最快地進入狀態，永遠是每個人要好好練習的功課。
本文由 @花生醬先生 原創發佈于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Pexels，基於 CC0 協議