BRD是一個在企業商業戰略層面撰寫的文檔，在文檔中分析大環境和市場前景，得出產品的商業目標，并核算投入產出等。對于小團隊而言……好吧，我認為這篇文檔的實用價值不太大。
1． 市場環境分析
2． 問題分析
3． 我們的優勢
4． 結論和商業目標
5． 收益與成本
6． 風險與對策
嘿~你在我的文件夾中找不到這篇文檔，它的所有內容都在boss的腦子里。
策劃中期（產品目標、用戶需求、內容與功能需求）
?MRD市場需求文檔
這篇文檔說明“怎么做產品”，以達到（BRD中的）商業目標。它會是未來所有文檔的參考源頭。
1. 文檔說明
a) 文檔基本信息（公司名稱、產品名稱、文檔創建日期、創建人和聯系方式、部門職務）
b) 文檔修改記錄
2. 市場說明
a) 市場問題（產品、技術、運營、用戶、商業模式等）
b) 針對大市場中的目標市場（市場規模、特征、發展趨勢等）
c) 結論（市場定位）
d) 團隊目標（我們要從這個產品中得到什么）
3. 用戶分析
a) 目標用戶群體（年齡、收入、學歷、地區等）
b) 目標用戶特征分析（特點與共性）
c) 用戶角色卡：
假設真實存在的用戶Gara，為他設計年齡性別、生日、收入職業、居住地、愛好、性格等
根據他的背景推理他的技能情況（熟練使用電腦辦公等）
推理與產品相關的特征（使用微信，單身，喜歡皮膚白長頭發的女孩子）
針對用戶群可以虛擬多個用戶角色
d) 用戶使用場景
用戶Gara如何使用我們的產品，講一個完整的故事（時間、地點、人物、任務等）。
周五下班途中，在公交車上，無聊又寂寞的Gara打開了微信看看周圍有美女在線，加了對方好友，快樂地聊起來……
a) 用戶需求和用戶的真實需求
用戶需求：在旅途中方便地充電。
用戶的真實需求：手機電池更耐用。
b) 可能影響用戶的因素（設備、網絡、速度、信息等）
不僅要羅列因素，還要詳細分析這些因素如何影響用戶使用產品的過程。
4. 產品說明
a) 用戶定位
簡單描述產品的目標用戶群體。
b) 產品定位
我們將用什么樣的產品滿足用戶需求。
c) 用戶需求、產品核心目標
我們的目標用戶要從這個產品中得到什么。
我們的產品幫助目標用戶解決什么問題。
d) 產品結構
我們需要哪些類型的內容。
我們需要什么樣的功能去支撐這些內容。
5. 產品路線
成功標準：了解我們的開發過程，知道我們什么時候到達終點。
產品路路線經常被誤解為方向，實際上，成功的標準不見得是以方向衡量的，我們通常告訴自己“滿足哪些條件，我就成功了”而不是“向著哪個方向走，我就成功了”。
因此在規劃中，我們設定里程碑（需要完成的任務），制定可追蹤的指標（需要滿足的條件），來評估我們的工作。
一般會以項目甘特圖的形式體現，包含時間、任務、說明等內容（如下圖）
放松的小劇場：
BRD：嗨~為了放松心情~我們出去玩吧~
MRD：那我們就來商量下去哪里玩，幾個人，完成什么任務，空出多少時間，準備多少錢…
B、M：小P快去干活！
接下來我們一起來了解下這個小P
策劃后期（界面交互與設計、信息架構、布局與導航設計）
?PRD產品需求文檔
有時候也叫做產品說明書，最細致也最繁瑣的文檔，開工之前一定要深呼吸，擺好姿勢。這個文檔會是所有項目成員做事的直接依據，描述要低調膚淺簡單粗暴，這樣大家才能愉快滴繼續玩耍。
1. 文檔說明（略）
2. 語言說明
a) 溝通語，明確與目標用戶溝通的語言風格，使用與用戶合拍的溝通方式。這是為了避免一些我們自以為很了解的專業術語妨礙了用戶的閱讀。
b) 命名，在用戶溝通方式的基礎上，為前臺的主要功能進行命名。
如果可能，我們也可以為后臺功能做命名。這樣前臺語言是給用戶看的，后臺語言是給我們自己看的，把兩者對應起來以防錯誤。這樣程序員的溝通壓力就不會太大（設計人員更加喜歡使用用戶語言，導致程序員的理解困難）。
c) 解釋幾個重要功能的命名，它們會在以后的文檔中被使用，現在就需要統一概念。
3. 產品說明
a) 產品結構
b) 任務流程圖
4. 全局說明
全局是指可以被套用在大部分的頁面或操作中的一些通用的規則，如果某個內容或功能與全局情況不同，就在細化中另外說明。
以下舉例兩種全局說明：
a) 設計規范
i. 布局
ii. 圖片
iii. 文字
iv. 色彩
v. 按鈕
vi. 控件
vii. 元素……
b) 交互規則
i. 頁面和元素的切換
ii. 退出軟件
iii. 被打斷
iv. 不同網絡情況
v. 常用手勢
vi. 加載方案
vii. 錯誤處理
viii. 反饋提示……
（退出軟件、打斷、切換、手勢等內容經常使用在APP產品中）
5. 細化說明
接下來我們就要描述清楚產品細節：
i 頁面布局和顯示規則
ii 頁面元素
iii 交互和操作
iv 錯誤和反饋
v 網絡異常
vi 重復點擊
viii 操作中斷……
除了描述清楚正常情況下的所有內容，還要考慮到特殊場景。
這里占了PRD文檔百分之九十的內容，需要點耐心。
我經常使用和上文中“產品結構”相同的順序來進行說明，從頻道、頁面、模塊、元素進行描述。這種方式適合對技術不太了解的小伙伴，描述的重點是用戶看到的部分。
原型
嚴格來說原型是為了更形象地說明PRD中所描述的頁面布局信息，它在需求傳遞中扮演了重要的角色，并且我們可以讓用戶使用原型提早進行可用性測試。
它會隨著需求的逐漸明確，變得更加精致：
1.低保真：表達布局和重點
2.中保真：表達動態和細節，
3.高保真：仿真產品。
避免常見的錯誤
客觀
主觀：“這里要使用第一人稱”
客觀：“參考文案規范”
避免使用主觀的內容，用客觀事物做參照可以避免反復修改。
具體
“具體”而不是“詳細”。
確保文檔中不要出現漏洞，清楚明確。
但是不要追求描述每一個細節。
應該包含設計或開發過程中存在的可能會產生混淆的功能定義。
記錄
不是“展望未來”，是“記錄”當下的決議。
所以我們要小心文檔中出現一些不確定的“想象”。
靈活
你完全可以把文檔內容拆分開來，或者合并，或者重組，或者刪減。你只要確保以下幾點：
1. 你想要的內容沒有遺漏
2. 你不需要的內容可以沒有
3. 你的文檔閱讀流暢，邏輯可以被理解
Ps：聽說點“很好看”那個方塊，天上會掉金磚……
第一篇：嗨！菜鳥~我們來談談你的新工作（習慣篇）
第二篇：嗨！菜鳥~我們來談談你的新工作（流程篇）
第四篇：嗨！菜鳥~我們來談談你的新工作（產品思維篇）
#專欄作家#
GaraC，知乎賬號：GaraChenV，人人都是產品經理專欄作家，專長研究用戶體驗，虐待各種形式的鍵盤。關注物聯網、互聯網金融、LBS等相關領域產品。專業掃描各種書籍，愛好：收集各種樂譜和奇怪的書。
本文系作者獨家授權發布，未經本站許可，不得轉載。
起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識
很好看~
學習進階ing
學習了。
好文章，得好好學習啊
新手助理學習了
lz寫的太精彩了 ，多問句您那招助理不[陰險]