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