導(dǎo)語：寫好PRD文檔是產(chǎn)品經(jīng)理的必修功課，但這門“必修課”卻沒有統(tǒng)一的課本和答案，本篇文章適用于初入職場的產(chǎn)品新人。本文作者工作于BAT大廠，工作期間寫過多份PRD，將結(jié)合作者個人經(jīng)驗(yàn)并結(jié)合大廠同事的寫法，總結(jié)一下如何寫出一份“簡練”的PRD。

一、為什么強(qiáng)調(diào)“簡練”PRD？

標(biāo)題中強(qiáng)調(diào)簡練，是因?yàn)樽髡咴诔跞肼殘鰰r也看過非常多的PRD教程，大部分事無巨細(xì)，最長的可以分出十幾個一級標(biāo)題，這樣“冗長”的PRD讓初入職場的產(chǎn)品經(jīng)理往往失去了方向。

其實(shí)作為文檔三兄弟（BRD、MRD、PRD）中的一環(huán)，前兩個文檔如果寫得清晰，那么PRD就可以寫的相對“簡練”。

所以讓我們重新梳理一下BRD、MRD和PRD在一個產(chǎn)品調(diào)研、設(shè)計(jì)、開發(fā)、上市中分別起到怎樣的作用，以及它的受眾是誰，需要如何影響受眾 (熟悉的概念的朋友可以跳過這一部分）。

理清三者的關(guān)系后有助于產(chǎn)品新手明白哪些內(nèi)容是應(yīng)該在BRD和MRD中完成的，哪些內(nèi)容才是PRD的核心，進(jìn)而明白為何PRD可以很“簡練”。

1. BRD：Business Requirement Document

BRD可以說是一個產(chǎn)品從0-1過程中第一個誕生的正式文檔，用于論證產(chǎn)品在商業(yè)上的可行性。BRD文檔是產(chǎn)品經(jīng)理向上司、以及財(cái)務(wù)和預(yù)算等職能部門溝通產(chǎn)品立項(xiàng)的工具，主要就是為了說明經(jīng)典的“產(chǎn)品精益畫布”當(dāng)中的內(nèi)容——即下圖1到9幾個模塊。

產(chǎn)品精益畫布是論證商業(yè)可行性的常用工具，說明產(chǎn)品賣給誰、成本和收入情況、為什么能贏利、通過什么渠道盈利等關(guān)鍵問題。對BRD中產(chǎn)品精益畫布感興趣的朋友可以細(xì)讀《精益創(chuàng)業(yè)實(shí)戰(zhàn)》（第二版）第三章，本文不做細(xì)述。

若產(chǎn)品上司、財(cái)務(wù)預(yù)算等職能部門認(rèn)可了產(chǎn)品經(jīng)理的BRD分析，那么就意味著產(chǎn)品可以立項(xiàng)了，公司會對這個產(chǎn)品開始投入資源，并開始產(chǎn)品備案等流程。

2. MRD：Market Requirement Document

相比于BRD溝通投入產(chǎn)出、盈利性等目的，MRD在BRD和PRD之間起到一個承上啟下的作用，在BRD之后進(jìn)一步說明立項(xiàng)產(chǎn)品所處的行業(yè)市場現(xiàn)況，目標(biāo)用戶，競品調(diào)研和自身打法。

MRD的受眾主要是產(chǎn)品經(jīng)理的上司、公司的產(chǎn)品運(yùn)營和市場品牌部門，向他們說明產(chǎn)品在市場中的定位和打法，同時為自己的產(chǎn)品在同公司的眾多產(chǎn)品線中爭取更多的運(yùn)營和市場資源傾斜。

3. PRD：Product Requirement Document

當(dāng)一個產(chǎn)品已經(jīng)通過了BRD、MRD評審后，說明該產(chǎn)品在資源投入和定位、打法上已經(jīng)獲得了公司層面的認(rèn)可，已經(jīng)具備了啟動產(chǎn)品設(shè)計(jì)、開發(fā)、投向市場的資格。

在這種前提下，一份PRD文檔的受眾就可以拋開運(yùn)營和市場等職能部門，無需再贅述過多的商業(yè)可行性、盈利性等信息，僅面向產(chǎn)品后端RD、前端FE、交互設(shè)計(jì)師（UI或UX）、測試QA輸出信息即可。

二、如何寫一份“簡練”的PRD？

1. PRD文檔的受眾關(guān)心什么

基于上文，PRD是面向后端RD、前端FE、交互設(shè)計(jì)師和QA的文檔，我們首先要拆解分析這些角色的核心關(guān)注點(diǎn)，然后把他們的關(guān)注點(diǎn)融合到PRD的不同章節(jié)中。

• 后端RD：后端研發(fā)主要關(guān)注所設(shè)計(jì)的產(chǎn)品需要存儲哪些數(shù)據(jù)，需要如何建表存儲這些數(shù)據(jù)，這些數(shù)據(jù)是否需要支持增、刪、改、查等功能，以及為了操作這些數(shù)據(jù)需要為產(chǎn)品提供哪些接口；
• 前端FE：前端FE主要關(guān)注后端接口如何與前端界面相結(jié)合，調(diào)取后端哪個接口，并用怎樣的方式為后端收集入?yún)?，在收集入?yún)r前端是否要做額外的限制，以及后端返回的出參如何轉(zhuǎn)化為前端的提示等；
• 交互設(shè)計(jì)師：主要關(guān)注產(chǎn)品在用戶交互上的體驗(yàn)及產(chǎn)品的界面調(diào)性、視覺樣式是否符合公司的規(guī)范。大部分交互設(shè)計(jì)師和產(chǎn)品經(jīng)理溝通時都是對著原型圖深化UI稿，所以他們往往是最關(guān)注PRD中原型的人；
• 測試QA：主要關(guān)注產(chǎn)品的user story，因?yàn)镼A需要模擬不同的使用場景設(shè)計(jì)測試case，大部分情況下QA會用Xmind等腦圖設(shè)計(jì)工具來設(shè)計(jì)、覆蓋可能出現(xiàn)的case，并進(jìn)行遍歷測試。

當(dāng)然，除了上述不同的關(guān)注點(diǎn)，PRD的受眾也需要知道一些共同的信息，例如：產(chǎn)品中有哪些通用概念，本次迭代與之前版本的功能迭代的關(guān)系，以及本次產(chǎn)品開發(fā)的緊急性和重要性。

2. 如何將受眾的關(guān)注點(diǎn)融入PRD框架

雖然說不同的產(chǎn)品經(jīng)理在PRD框架上有自己的見解，本文根據(jù)作者自身經(jīng)驗(yàn)及對大廠同事們PRD的參考，建議產(chǎn)品新人遵循以下框架，就能滿足大部分RD、FE、UI/UX、QA們的需要。

1）迭代管理

迭代管理記錄了產(chǎn)品開發(fā)從0-1的過程，產(chǎn)品經(jīng)理需要寫清每一次迭代新增、修改或下架了哪些功能，以及迭代的原因。

同時，迭代版本號反映出每次迭代版本更新的大小，以下圖為例，通常兩級版本號就能夠表達(dá)出需求屬于“大步迭代”還是“小步快跑”。

2）需求背景

需求背景是RD、FE、UI/UX和QA共同關(guān)注的點(diǎn)，在大廠中，一般后端RD和QA是分組的，而FE和UI/UX是部門共享的人力，意味著你的需求在FE、UI/UX面前是要和部門內(nèi)其他組的需求搶排期。

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

1. 需求產(chǎn)生的原因：可以是發(fā)現(xiàn)了原來版本的局限性，即優(yōu)化/修改老需求；也可以是基于新發(fā)現(xiàn)的用戶需求對產(chǎn)品進(jìn)行迭代，即增加新需求；
2. 需求的合理性和必要性：在需求評審中，RD通常會對需求合理性、必要性挑戰(zhàn)產(chǎn)品經(jīng)理——即為什么一定要開發(fā)上線這些功能，F(xiàn)E和UI/UX同樣也會評估該需求是否為高優(yōu)緊急。所以產(chǎn)品經(jīng)理可以正向回答——即開發(fā)了需求所提的功能預(yù)計(jì)能為項(xiàng)目組、為部門帶來怎樣的好處，或逆向回答——不開發(fā)該功能會導(dǎo)致什么樣的問題和風(fēng)險。

3）功能清單

功能清單建議以列表的方式闡明本次新增和修改的功能。在功能清單中需要說明項(xiàng)目信息、新增/修改的功能點(diǎn)、功能點(diǎn)詳情，以及優(yōu)先級。

功能清單的目的主要是讓后端RD快速了解本次開發(fā)的內(nèi)容大綱，并評估出工作量，當(dāng)產(chǎn)品經(jīng)理定好每個功能點(diǎn)的優(yōu)先級后，后端RD就可以根據(jù)工作量和優(yōu)先級給出詳細(xì)的排期，并協(xié)調(diào)QA提測的時間。

功能清單建議不要寫的太過于繁雜，否則滿滿的文字RD、FE們很容易感到厭煩，反而導(dǎo)致整個文檔模塊被忽略。下表是典型的功能清單例子，大家可以參考：

4）產(chǎn)品流程圖

產(chǎn)品流程圖是PRD中的必備內(nèi)容，通常有很多畫法，每個產(chǎn)品經(jīng)理在流程圖中表達(dá)的信息都不盡相同。

非技術(shù)背景出身的產(chǎn)品經(jīng)理往往站在使用者的角度來梳理流程，而一些技術(shù)背景出身（或研發(fā)轉(zhuǎn)產(chǎn)品）的產(chǎn)品經(jīng)理往往在流程圖會額外表達(dá)數(shù)據(jù)的流轉(zhuǎn)關(guān)系。

但不論采用何種畫法，他們的目的都是為了讓PRD的受眾理解產(chǎn)品使用的主線和分支。既然本文的核心在于“簡練”，那么如何畫出即簡單但又滿足需求評審要求的流程圖呢？

下面分ToC和ToB兩個場景來討論：在ToC產(chǎn)品中，產(chǎn)品的使用對象往往為單一的個體，產(chǎn)品不涉及多個用戶時，它的故事線和流程圖往往比較簡單，只需按照時間維度，按產(chǎn)品使用流程的主線來整理即可，同時在主線上注明不同分支。

下圖就是一個很簡單的例子:

但在TO B的產(chǎn)品中，產(chǎn)品的使用步驟通常涉及到多個身份的人員，不同人員之間的操作還有時序依賴關(guān)系。

在這種情況下，如何“簡練”地將時間維度和人員維度囊括在一張圖里呢？大家可以參考下方流程圖的畫法——按時間維度+參與人員兩個維度，畫一份“泳道”流程圖。

上面兩張圖提供了兩個簡單的例子，可以作為模板衍生、表達(dá)大部分的產(chǎn)品流程。

5）產(chǎn)品原型

最后，在一份PRD文檔中不可或缺的就是產(chǎn)品原型了。產(chǎn)品經(jīng)理在PRD需求評審時花往往花費(fèi)大部分時間溝通產(chǎn)品原型。通常產(chǎn)品原型可分為高保真原型和低保真原型，具體采用何種形式其實(shí)取決于產(chǎn)品經(jīng)理與UI/UX設(shè)計(jì)師之間的分工邊界。

在分工極度明確的大廠，一般鼓勵產(chǎn)品經(jīng)理提供低保真原型即可。因?yàn)榇髲S的UI/UX部門對產(chǎn)品的風(fēng)格調(diào)性、交互邏輯有著極為清晰的規(guī)定，產(chǎn)品經(jīng)理在原型圖上投入太多精力反而會事倍功半。

但是一些中小型公司人員分工不那么全面，產(chǎn)品經(jīng)理與UI/UX的邊界較為模糊，往往由產(chǎn)品經(jīng)理本人輸出高保真的原型圖。

所以產(chǎn)品經(jīng)理在輸出PRD時原型到底畫到怎樣的精細(xì)度是因公司、因項(xiàng)目組而異的。筆者建議能輸出低保真原型時盡量以低保真交付，但如果產(chǎn)品已經(jīng)處于后期迭代時，用現(xiàn)有的真實(shí)界面進(jìn)行P圖改造也不失為一種“簡練”的方法。

下圖是筆者在產(chǎn)品迭代過程中，利用原有界面和新增備注快速迭代出的原型圖（部分截圖）：

三、結(jié)語

結(jié)合上述對BRD、MRD、PRD分工的探討，以及PRD的各個章節(jié)如何撰寫的介紹。

本文的目的其實(shí)就為了表達(dá)一個核心觀點(diǎn)——PRD可以寫的很簡練，初入職場的產(chǎn)品經(jīng)理無需對PRD的撰寫過分焦慮，尤其是在正確理解PRD在一個產(chǎn)品生命周期中所發(fā)揮的核心作用后，我們會發(fā)現(xiàn)其實(shí)它并不復(fù)雜。

作者：Amy有只藍(lán)貓，百度高級產(chǎn)品經(jīng)理，熟悉B端產(chǎn)品、AI產(chǎn)品、產(chǎn)品商業(yè)化、人機(jī)交互與內(nèi)容策略產(chǎn)品，歡迎交流。

本文由 @Amy有只藍(lán)貓 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自?Unsplash，基于 CC0 協(xié)議