導語：寫好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面前是要和部門內其他組的需求搶排期。

所以建議“簡練”版的需求背景要包括以下兩點：

1. 需求產生的原因：可以是發現了原來版本的局限性，即優化/修改老需求；也可以是基于新發現的用戶需求對產品進行迭代，即增加新需求；
2. 需求的合理性和必要性：在需求評審中，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 協議