MVP：詳解產品商業文檔、市場文檔、設計文檔、功能文檔

編輯導語：在產品進入生產性開發之前，產品文檔是其中的重要流程。其中，產品文檔包括商業文檔、市場文檔、設計文檔、功能文檔等，每種文檔都有其意義及注意事項。本篇文章里，作者對產品文檔進行了較為詳細的總結，一起來看一下。

在產品未進入生產性開發之前，所做的所有工作成果都是以文檔的形式進行體現的，是新產品開發最重要、也是價值最大的工作內容，包括商業文檔、市場文檔、設計文檔及功能詳述，如圖5-11所示。

從廣義上來講，產品文檔內容包含有產品的戰略和戰術，戰略是指：目標市場、客群定位、競爭對手、產品概念、價值主張、產品定位、商業模式等；戰術是指競爭策略、產品創意、創新設計、產品結構、核心業務流程、具體用例描述、功能及內容描述等。

圖5-11 產品設計相關四大文檔

一、商業文檔

BRD商業需求文檔是指基于商業目標或價值所描述的產品需求內容文檔（報告），其核心的用途就是用于產品在投入研發之前，由企業高層作為決策評估的重要依據。

作為報告的撰寫者，你必須讓高層明白，你的報告中將展現出怎樣的商業價值，如何用有力的論據來說服企業對你這個項目的認可，并為之慷慨地投入研發資源及市場費用。

如果說PRD的好壞，直接決定了項目的質量水平，那么BRD的作用，就是決定了你的項目的商業價值。

優秀的BRD文檔，可以讓決策層充分被你的報告觀點所吸引，或許財務主管會因為報告呈現的低投入高產出的經濟效益預測而蠢蠢欲動；或許技術主管會因為項目的牽涉面廣泛而頭疼不已；又或許公司的VP之流因之報告而看到了未來一年業績的飛速發展的廣闊前景……

BRD需要產品經理（產品設計師）像對待PRD一樣，充分應用市場調查、用戶研究、需求分析等各種設計手段來充分闡述報告, 內容和格式要求夠直觀、精煉，要點突出，一般比較短小精煉，沒有產品細節。產品經理通常需要向上匯報商業文檔，供決策層們討論，匯報會議主要內容如下。

• 會議開始，產品經理首先要給與會的領導介紹一下產品要做什么吧（解決什么問題或滿足什么用戶需要）？
• 為什么要做談談背后的原因（背景、市場空間、競爭對手、環境）？
• 打算怎么做（產品規劃、模塊規劃、研發計劃、運營計劃）？
• 需要多少資源（人力成本、軟硬件成本、運營成本）？
• 最終能獲得什么收益（帶來收入、帶來用戶、擴大市場、占有市場先機、滿足未來三年戰略規劃等）？
• 做這個有沒有風險（開發失敗？失去市場機會？失去先機？競爭不過對手？沒有帶來收入？沒有帶來用戶？與公司戰略背道而馳？）？

二、市場文檔

MRD市場需求文檔是產品項目由“準備”階段進入到“實施”階段的第一文檔，其作用就是“對某個產品進行市場層面的說明”。

該文檔中，側重的是對產品所在市場、客戶、購買者、用戶以及市場需求進行定義，并通過原型的形式加以形象化。

這個文檔的質量好壞直接影響到產品項目的開展，并直接影響到公司產品戰略意圖的實現。該文檔在產品項目中是一個“承上啟下”的作用，“向上”是對不斷積累的市場數據的一種整合和記錄，“向下”是對后續工作的方向說明和工作指導。文檔包含主要內容如下。

1. 市場說明

目標市場、市場規模、市場特征、未來3~5年的發展趨勢，現在市場存在的問題和機會。一般來說，這里會得到一個比較有市場商業價值的結論。

2. 用戶說明

目標客群的共性分析，常用用戶特征（要求準確：年齡段、收入、地區、學歷），通過用戶畫像建立虛擬用戶角色：形象化，用戶名稱，用戶技能、與產品相關的用戶特征，演示性的場景，用戶在時間、地點，完成的某個事的故事。

從技術層面剖析市場，洞察用戶心理案例分析（動機和目標是不一致的）影響用戶使用的主要因素。

3. 產品定位

我們用什么樣的產品滿足用戶或用戶市場；針對什么用戶，做什么事。

4. 產品價值

解決目標市場、用戶的核心需求（核心價值優先級最高）。

5. 產品架構

整體結構，不是功能結構。是產品的核心目標、市場定位、產品定位的直接體現。

6. 產品路線圖

以時間為節點，任務為導向。

7. 產品功能性需求

用戶注冊、留言等等。

8. 非功能性需求

有效性、性能、擴展性、安全性、健壯性、兼容性、可用性、用戶體驗等。

三、設計文檔

PRD產品設計文檔是把我們想做的東西變成一張清晰明了的“圖紙”，讓研發人員看到這張“圖紙”就知道我們要做啥，需要做到什么程度，大概需要什么技術，并能對成本進行一個預估。

不同平臺和不同行業的產品的設計文檔有所區別，但思想都差不多。

這里以網站為例，設計文檔一般包括網站結構圖、線框圖和網頁描述表。產品設計文檔伴隨著產品整個生命周期，幫助產品團隊與研發團隊和高層領導達成共識，進而明確研發計劃和指導研發過程。不同的公司、不同的產品會有自己不同的要求和模板，但在這里我想提醒一些大家需要注意的地方。

1. 保持簡短

對于產品設計文檔，保持簡短很重要，因為越是簡短，包含的錯誤越少，同時更容易閱讀，同時也越可能帶來簡潔的設計。

但是一定要在窮盡的基礎上簡短，不要為了最求簡短而忽略一些細節，在產品設計中，每一個小細節對產品的質量來說都很重要。所以一定要仔細思考，認真推敲。

2. 消滅錯誤

錯誤的文檔會花費研發團隊大量的時間，甚至會導致大規模的改動，這時對研發來說沒有誰會很爽，一個個都恨不得把你給撕了。有點夸張了。但心里面絕對是一萬個“操尼瑪”！同時也會讓產品團隊在研發團隊面前抬不起頭。

當然，也不用太想不開，畢竟沒有錯誤的文檔和沒有錯誤的代碼一樣，都是不存在的，我們需要做的是盡可能地消滅錯誤，讓錯誤能在可承受范圍內。

錯誤有很多種，有產品邏輯錯誤（最致命的），有多個需求相互矛盾的錯誤，還有錯別字等層面的低級錯誤。在撰寫產品設計文檔的時候，產品團隊因對應產品邏輯進行充分的討論和測試，最終要組織評審會議，采用審核通過的方式把關。

3. 別對他人（主要是研發人員）的工作指手畫腳

也就是說在設計文檔中不要提一些技術性的東西。

比如：將其存入數據庫的一個新表中，連續存放，以優化查詢效率。別提之類的需求，你很可能犯一些細節上的錯誤。己所不欲，勿施于人，別人在你的領域內指手畫腳你也會感到很煩。如果你是個技術專家，可以私下溝通，別把應該寫在技術文檔中的內容寫在設計文檔里。

4. 用適當的方式表述需求

選取適當的方式展現特定的信息，是產品經理的一項重要技能，面對研發團隊的時候要用到，面對最終用戶的時候也會用到，怎樣去表現我們的需求讓研發或客戶能快速有效的理解是相當重要的，不僅可以提高工作效率，還可以避免很多因理解不當造成的錯誤。

因理解不一致這種錯誤是很常見的，和不同領域類的人提需求理解不當更是家常便飯了，選用適當的表述方式是相當重要的。比如，用敘述性文字說不清楚我們就用表格或其他的，有時候還需要選擇一些圖形工具。

5. 使用肯定的語言

在產品設計文檔中，使用肯定的、確切的語言，切勿出現“也許，可能”這類詞語。我們最終提交的文檔內容都是確切的，可被執行的，含糊不清的東西一定要全部消滅掉。如果有吃不準的東西，就放在內部充分討論后在做決定。

6. 切勿忽視溝通

很多產品新人在寫產品設計文檔的時候，獨自埋著頭寫，寫好了之后再出去溝通，這樣文檔有99%的概率會被大幅度修改，這等于是在做無用功，所以在寫設計文檔的時候千萬不要忽略和團隊溝通。

四、功能詳述

FSD功能詳細說明定義產品功能需求的全部細節，這是一份可以直接讓工程師創建產品的文檔。

FSD建立在BRD、MRD和PRD的基礎上，從這步就開始往開發銜接了，產品UI、業務邏輯的細節都要確定，細化文檔并保持更新。功能需求是所有的產品功能的描述和規劃，以互聯網產品為例包括以下內容。

1. 簡要說明

介紹此功能的用途，包括其來源或背景，能夠解決哪些問題。

2. 場景描述

產品在哪種情況下會被用戶使用，就是用戶場景模擬。這也是產品經理講“好”故事的必備條件。

3. 業務規則

每個產品在開發時都有相應的業務規則，將這些規則清晰地描述出來，讓開發、測試人員能夠直觀的明白該規則，且沒有產生歧義。業務規則必需是完整的、準確的、易懂的。

業務規則的描述上如果涉及到頁面交互或者頁面的修改，建議給出頁面的草圖或者頁面截圖在圖上說明要修改的內容。

另外也建議對頁面的輸入框、下拉框的內容格式、長度、控件之間的關聯性做出說明，什么時候可見、不可見、灰掉或點亮的條件在文檔中都給出說明，方便閱讀者理解業務規則。

4. 界面原型

如前所述，涉及到頁面交互的部分，產品經理需要設計頁面原型。

原型設計通常需要產品經理和UI設計師一起來完成。建議的做法是，產品經理可設計一個頁面框架，將該頁面要呈現的字段及其特征以及頁面要使用的場景向交互設計師解釋清楚，之后交互和視覺設計師完成產品的原型設計。

5. 使用者說明

對產品使用者做出說明，可融入簡要說明中。

6. 前置條件

該需求實現依賴的前提條件。比如，上傳照片時，需要存有圖像的文件。

7. 后置條件

操作后引發的后續處理。

8. 主流程

把主流放在最后是有道理的，結合上面所說的，做出主流程說明，對每個功能流程走向分點說明（這是非常重要的）。

看過很多的PRD（包含FSD），文檔中對既沒有前提條件，也沒有后置條件，只對主流程做了說明，但是在描述主流程時卻沒有描寫主流程中每個功能流程的各種走向，只有一個主走向，讓人感覺PRD成了操作手冊。

事實上，對分支的介紹是非常重要的，開發和測試中提出的各類問題均與對分支的定義不明有關。一個合格的PRD不僅要描述主流程，同時對分支流程所出現的各類問題都要做詳細闡述并給出解決辦法。

PRD的特征一定是明確的、全面的闡述需求及各類異常情況的處理而不是等到開發和測試階段發現問題后再給以答案（雖然PRD不可能百分之百地覆蓋所有的可能，但是最大化的思考所有的業務問題是編制PRD時必須遵守的原則）。

另外，在描寫功能需求時給出的辦法中不能出現“可能”、“或者”等詞，一定是明確的、準確的描述。如果有別的方案，建議寫入“可選方案”，在產品構建的早期可選方案可以為功能實現提供更多的選擇，當方案確定后可在文檔中注明本次使用了哪種方案。

 

作者：長乘，公眾號：MVP-PM，歷任兩家世界500強企業產品專家！內容摘自：人民郵電出版社《獨具匠心：做最小可行性產品（MVP）方法與實踐》

本文由 @長乘 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議