產品經理如何寫出一份“簡練”的PRD
導語:寫好PRD文檔是產品經理的必修功課,但這門“必修課”卻沒有統一的課本和答案,本篇文章適用于初入職場的產品新人。本文作者工作于BAT大廠,工作期間寫過多份PRD,將結合作者個人經驗并結合大廠同事的寫法,總結一下如何寫出一份“簡練”的PRD。
一、為什么強調“簡練”PRD?
標題中強調簡練,是因為作者在初入職場時也看過非常多的PRD教程,大部分事無巨細,最長的可以分出十幾個一級標題,這樣“冗長”的PRD讓初入職場的產品經理往往失去了方向。
其實作為文檔三兄弟(BRD、MRD、PRD)中的一環,前兩個文檔如果寫得清晰,那么PRD就可以寫的相對“簡練”。
所以讓我們重新梳理一下BRD、MRD和PRD在一個產品調研、設計、開發、上市中分別起到怎樣的作用,以及它的受眾是誰,需要如何影響受眾 (熟悉的概念的朋友可以跳過這一部分)。
理清三者的關系后有助于產品新手明白哪些內容是應該在BRD和MRD中完成的,哪些內容才是PRD的核心,進而明白為何PRD可以很“簡練”。
1. BRD:Business Requirement Document
BRD可以說是一個產品從0-1過程中第一個誕生的正式文檔,用于論證產品在商業上的可行性。BRD文檔是產品經理向上司、以及財務和預算等職能部門溝通產品立項的工具,主要就是為了說明經典的“產品精益畫布”當中的內容——即下圖1到9幾個模塊。
產品精益畫布是論證商業可行性的常用工具,說明產品賣給誰、成本和收入情況、為什么能贏利、通過什么渠道盈利等關鍵問題。對BRD中產品精益畫布感興趣的朋友可以細讀《精益創業實戰》(第二版)第三章,本文不做細述。
若產品上司、財務預算等職能部門認可了產品經理的BRD分析,那么就意味著產品可以立項了,公司會對這個產品開始投入資源,并開始產品備案等流程。
2. MRD:Market Requirement Document
相比于BRD溝通投入產出、盈利性等目的,MRD在BRD和PRD之間起到一個承上啟下的作用,在BRD之后進一步說明立項產品所處的行業市場現況,目標用戶,競品調研和自身打法。
MRD的受眾主要是產品經理的上司、公司的產品運營和市場品牌部門,向他們說明產品在市場中的定位和打法,同時為自己的產品在同公司的眾多產品線中爭取更多的運營和市場資源傾斜。
3. PRD:Product Requirement Document
當一個產品已經通過了BRD、MRD評審后,說明該產品在資源投入和定位、打法上已經獲得了公司層面的認可,已經具備了啟動產品設計、開發、投向市場的資格。
在這種前提下,一份PRD文檔的受眾就可以拋開運營和市場等職能部門,無需再贅述過多的商業可行性、盈利性等信息,僅面向產品后端RD、前端FE、交互設計師(UI或UX)、測試QA輸出信息即可。
二、如何寫一份“簡練”的PRD?
1. PRD文檔的受眾關心什么
基于上文,PRD是面向后端RD、前端FE、交互設計師和QA的文檔,我們首先要拆解分析這些角色的核心關注點,然后把他們的關注點融合到PRD的不同章節中。
- 后端RD:后端研發主要關注所設計的產品需要存儲哪些數據,需要如何建表存儲這些數據,這些數據是否需要支持增、刪、改、查等功能,以及為了操作這些數據需要為產品提供哪些接口;
- 前端FE:前端FE主要關注后端接口如何與前端界面相結合,調取后端哪個接口,并用怎樣的方式為后端收集入參,在收集入參時前端是否要做額外的限制,以及后端返回的出參如何轉化為前端的提示等;
- 交互設計師:主要關注產品在用戶交互上的體驗及產品的界面調性、視覺樣式是否符合公司的規范。大部分交互設計師和產品經理溝通時都是對著原型圖深化UI稿,所以他們往往是最關注PRD中原型的人;
- 測試QA:主要關注產品的user story,因為QA需要模擬不同的使用場景設計測試case,大部分情況下QA會用Xmind等腦圖設計工具來設計、覆蓋可能出現的case,并進行遍歷測試。
當然,除了上述不同的關注點,PRD的受眾也需要知道一些共同的信息,例如:產品中有哪些通用概念,本次迭代與之前版本的功能迭代的關系,以及本次產品開發的緊急性和重要性。
2. 如何將受眾的關注點融入PRD框架
雖然說不同的產品經理在PRD框架上有自己的見解,本文根據作者自身經驗及對大廠同事們PRD的參考,建議產品新人遵循以下框架,就能滿足大部分RD、FE、UI/UX、QA們的需要。
1)迭代管理
迭代管理記錄了產品開發從0-1的過程,產品經理需要寫清每一次迭代新增、修改或下架了哪些功能,以及迭代的原因。
同時,迭代版本號反映出每次迭代版本更新的大小,以下圖為例,通常兩級版本號就能夠表達出需求屬于“大步迭代”還是“小步快跑”。
2)需求背景
需求背景是RD、FE、UI/UX和QA共同關注的點,在大廠中,一般后端RD和QA是分組的,而FE和UI/UX是部門共享的人力,意味著你的需求在FE、UI/UX面前是要和部門內其他組的需求搶排期。
所以建議“簡練”版的需求背景要包括以下兩點:
- 需求產生的原因:可以是發現了原來版本的局限性,即優化/修改老需求;也可以是基于新發現的用戶需求對產品進行迭代,即增加新需求;
- 需求的合理性和必要性:在需求評審中,RD通常會對需求合理性、必要性挑戰產品經理——即為什么一定要開發上線這些功能,FE和UI/UX同樣也會評估該需求是否為高優緊急。所以產品經理可以正向回答——即開發了需求所提的功能預計能為項目組、為部門帶來怎樣的好處,或逆向回答——不開發該功能會導致什么樣的問題和風險。
3)功能清單
功能清單建議以列表的方式闡明本次新增和修改的功能。在功能清單中需要說明項目信息、新增/修改的功能點、功能點詳情,以及優先級。
功能清單的目的主要是讓后端RD快速了解本次開發的內容大綱,并評估出工作量,當產品經理定好每個功能點的優先級后,后端RD就可以根據工作量和優先級給出詳細的排期,并協調QA提測的時間。
功能清單建議不要寫的太過于繁雜,否則滿滿的文字RD、FE們很容易感到厭煩,反而導致整個文檔模塊被忽略。下表是典型的功能清單例子,大家可以參考:
4)產品流程圖
產品流程圖是PRD中的必備內容,通常有很多畫法,每個產品經理在流程圖中表達的信息都不盡相同。
非技術背景出身的產品經理往往站在使用者的角度來梳理流程,而一些技術背景出身(或研發轉產品)的產品經理往往在流程圖會額外表達數據的流轉關系。
但不論采用何種畫法,他們的目的都是為了讓PRD的受眾理解產品使用的主線和分支。既然本文的核心在于“簡練”,那么如何畫出即簡單但又滿足需求評審要求的流程圖呢?
下面分ToC和ToB兩個場景來討論:在ToC產品中,產品的使用對象往往為單一的個體,產品不涉及多個用戶時,它的故事線和流程圖往往比較簡單,只需按照時間維度,按產品使用流程的主線來整理即可,同時在主線上注明不同分支。
下圖就是一個很簡單的例子:
但在TO B的產品中,產品的使用步驟通常涉及到多個身份的人員,不同人員之間的操作還有時序依賴關系。
在這種情況下,如何“簡練”地將時間維度和人員維度囊括在一張圖里呢?大家可以參考下方流程圖的畫法——按時間維度+參與人員兩個維度,畫一份“泳道”流程圖。
上面兩張圖提供了兩個簡單的例子,可以作為模板衍生、表達大部分的產品流程。
5)產品原型
最后,在一份PRD文檔中不可或缺的就是產品原型了。產品經理在PRD需求評審時花往往花費大部分時間溝通產品原型。通常產品原型可分為高保真原型和低保真原型,具體采用何種形式其實取決于產品經理與UI/UX設計師之間的分工邊界。
在分工極度明確的大廠,一般鼓勵產品經理提供低保真原型即可。因為大廠的UI/UX部門對產品的風格調性、交互邏輯有著極為清晰的規定,產品經理在原型圖上投入太多精力反而會事倍功半。
但是一些中小型公司人員分工不那么全面,產品經理與UI/UX的邊界較為模糊,往往由產品經理本人輸出高保真的原型圖。
所以產品經理在輸出PRD時原型到底畫到怎樣的精細度是因公司、因項目組而異的。筆者建議能輸出低保真原型時盡量以低保真交付,但如果產品已經處于后期迭代時,用現有的真實界面進行P圖改造也不失為一種“簡練”的方法。
下圖是筆者在產品迭代過程中,利用原有界面和新增備注快速迭代出的原型圖(部分截圖):
三、結語
結合上述對BRD、MRD、PRD分工的探討,以及PRD的各個章節如何撰寫的介紹。
本文的目的其實就為了表達一個核心觀點——PRD可以寫的很簡練,初入職場的產品經理無需對PRD的撰寫過分焦慮,尤其是在正確理解PRD在一個產品生命周期中所發揮的核心作用后,我們會發現其實它并不復雜。
作者:Amy有只藍貓,百度高級產品經理,熟悉B端產品、AI產品、產品商業化、人機交互與內容策略產品,歡迎交流。
本文由 @Amy有只藍貓 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自?Unsplash,基于 CC0 協議
實際操作上,很多時候下游開發就只看產品流程圖和產品原型,至于其他的背景介紹什么的,就是靠一個需求溝通會議拉通(有業務方,產品方,開發方),名曰敏捷和提升效率,不知道這樣的做法是好是壞
個人覺得不是很好,我在大廠接觸合作的研發都希望產品經理能把需求背景“寫”下來,雖然很多人覺得會議上口頭說就行,但未來如果合作方有人離職交接,需要回顧文檔的時候是很不友好的。所以“寫下來”留檔是一個合格PM的責任。至于“效率”,你可以讓熟悉背景的研發“直接看N章節流程圖”就行。
哈哈哈,作者大大,產品是PO,不是PM哦,留檔是PO的職責,存檔是PM,PO和PM的差異性是非常大的
個人理解,就是PRD一般情況會有兩份的,一份在原型上(用于開發閱讀),一份在word文檔上(留存檔案及備份參考);不管是初級還是高級都需要詳細寫清楚,不能概況的,這是一個合格產品經理的底線,因為寫的詳細是對產品和項目組人員的負責,也是對公司的負責;每個業務的背景、目的、作用、界面屬性(包括各項關聯屬性)、業務流程、數據流程、跨職能交互協作等都是詳細寫清楚,越詳細越好。
我的理解,其實不管是brd,mrd,prd。首先要清楚是給公司的哪些角色看的,每一個角色都有自己關注的點,討論每個文檔里面什么是不是必須的,可以反問一下,如果不要這塊內容,行不行。比如prd里面的流程圖,主要是給開發和測試看,如果沒有這個,不能清楚的給這兩個角色講清楚。
作為一名運營,收獲不少,謝謝分享
謝謝鼓勵,多多交流,最近太忙了,希望自己可以多產出-。-///
身為一個小白,我還覺得干貨挺多的,既講了概念,舉了實例,又有一些在實際工作中可能會遇到的問題,也做了解釋~
有收獲,感謝~
謝謝你的鼓勵,以后會堅持輸出,希望和大家多交流
我不評判好不好,只是作為一個產品小白說的話:你告訴了我一份PRD里面應該有什么。所以對我來說可能這不是一份干貨,而是一個解釋什么是PRD。PRD=迭代管理+需求管理+功能目錄+流程圖+原型
我的理解是,知道了PRD里必須包含什么,就可以抓住重點,寫的比較簡練,而非事無巨細,囊括產品立項理由等各種信息
是的,您的理解是沒有錯的,因為我現在剛開始接觸產品經理,也看了一些前輩的產品PRD,其實每個人都有自己的一套prd的風格,但是主體的結構都是大同小異,主要是內容和項目對當前的契合度會有增刪,甚至如果是一些老板項目,甚至只有設計思路和原型圖。所以,框架搭好,或簡練或復雜,其實都是為了說明清楚一個PM/PD的思路。謝謝您的回復和指點(:
這是個啥
prd方法哪里簡練也沒說明呀
因為我遇到的一些小伙伴,會把很多無需在PRD文檔里的內容都寫在PRD里,導致特別冗長,所以這篇文章想說明哪些內容才是PRD的核心,以及這些核心大致怎么寫就夠了