MRD和PRD的寫作真的是仁者見仁智者見智，沒有固定的格式，只要能說明清楚問題就行。
我本人是不想講這部分內容的，但是為了體系的完整，暫且簡要講一下，本文的內容基本是我以前學習時記錄的，沒有太多的修改。
本文結構如下：
一、MRD
MRD（Market requirements document，市場需求文檔）。
獲得老板們的支持后，產品進入實施階段，需要寫出MRD，要有更細致的市場與競爭對手分析，包括可通過哪些功能來實現商業目的，功能、非功能需求分哪幾塊，功能的優先級等等。實際工作中，PM在這個階段常見的產出物有產品的feature list、業務邏輯圖，這是從商業目標到技術實現的關鍵轉化文檔。
MRD到底要干什么?
用繞口的方法來說：如果說BRD是你拋出的論題，那么MRD就是要你用論點來支撐你的BRD，同時通過論證來得出你采取什么方式獲得BRD里面的商業目標（講究邏輯性）。
用大白話來說：MRD就是經過一系列的分析后，拿出一套你認為最合理的干某個事情的方法與指導實施的文檔。
1、匯報對象
未來參與產品的各個層級的同事，都有可能要閱讀MRD，包括產品經理自己。
MRD是最完善的產品誕生分析描述文檔，以后的一段時間，產品的各種衍伸文檔、產品依據、團隊判斷，都可能參考MRD文檔。
產品參與成員需要了解產品的各種背景、數據、方法依據。
2、MRD內容結構
1.文檔說明
1.1 文檔基本信息
公司名稱；產品名稱；文檔創建日期；創建人；創建人聯系方式；部門；職務。
1.2 文檔修改記錄
日期；版本；修改人；修改內容；審核人。
1.3 文檔目的
用于說明相關市場，用戶，產品規劃，核心目標，產品路線圖，項目規劃等。
1.4 文檔概要
文檔說明；市場說明；用戶說明；產品說明。
2.市場分析
2.1摘要（可選）
2.2現有市場存在的問題與機會
就互聯網而言，可以從以下（但不限于）幾方面來選擇性表述：
- 產品方面（例如：產品形態復雜，用戶體驗差）
- 技術方面（語音壓縮技術不成熟，外資搜索引擎對中文理解不夠深刻）
- 運營方面（產業鏈偏下游，重實體，輕線上，造成瓜分線下旅行社利潤，形成對立）
- 用戶方面（用戶需要可替代產品尚未出現，需求明顯）
- 商業模式方面（金山毒霸和360安全衛士的商業模式對比）
由于在以上的分析說明中，可能會涉及到用戶分析相關的內容，可以先提用戶分析的結果并說明詳見用戶分析章節即可，這樣可以保證文檔的完整連續性，也能簡明扼要。
2.3目標市場分析（基于該機會點下的市場分析說明）
- 市場規模：多少錢，成功可能大不大，往往是正比，但不絕對是，具體問題具體分析
- 市場特征：現有市場表現出的典型特征
- 發展趨勢：未來2-5年的發展評測，搜索市場的語音搜索，蘋果的Siri，體感便攜設備：谷歌眼鏡，蘋果iwatch）
- 時間邊界：這個市場的持續時間預估
2.4 市場分析結論
一般來說，這里會得到一個比較有市場商業價值的結論，否則，這個文檔就沒有存在的意義了
3.用戶分析
3.1 目標用戶群體（找準）
一般劃分維度：年齡段，收入，學歷，地區
3.2 目標用戶特征
所謂特征，及時在這個群體下面的共性特點與非共性特點（分析）
3.3建立虛擬用戶角色（形象化）
- 常用用戶特征（年齡；性別；出生日期； 收入；職業； 居住地；興趣愛好；性格特征）
- 用戶名稱(張三，李四，王麻子)
- 用戶技能（熟練使用電腦辦公，對常用的智能手機應用諳熟于心）
- 與產品相關特征
- 電子商務產品：購物習慣，年度消費預算等
- 交友類：是否單身，擇偶標準
- 游戲類：是否喜愛3D游戲，是否有同類型游戲經驗等
3.4用戶角色卡片
針對目標用戶群體進行歸類劃分，抽取典型樣本，數量不限，帶需要能代表目標用戶。
3.5 用戶使用場景
建立了用戶卡片以后，把這些典型用戶放到實際的使用場景中去。
此處的用戶使用場景更多是產品經理在分析完成用戶使用場景后的演示性場景。
注意分析場景與演示場景的區別：
用戶使用場景就是描述用戶在某個環境中完成某個了某個任務的故事。類似小學學習的八股文中的記敘文三要素：時間，地點，人物+干了什么事情+干事情的步驟。
3.6 用戶動機總結（讀懂表象）
線下的在線商品比較與查詢渠道等
3.7 用戶目標總結（明確實質）
獲得性價比最高的購物體驗，完美主義者會因此很得瑟，哪怕是便宜了1元錢也很得意
3.8 影響用戶使用的主要因素（重要，分析）
- 是否隨身攜帶接入設備
- 網絡是否通暢
- 查詢速度
- 設備對商品信息的獲取是否會對用戶造成不便
4.產品說明
4.1 產品定位
產品有越做越復雜的可能，但在一定時間內，定位決定了產品的一切。
產品定位與市場定位是有區別的，但經常容易混淆:：
- 市場定位：我們對用戶或者用戶市場的選擇，例如:手機發燒友，白領，或者移動通訊設備市場
- 產品定位：我們用什么樣的產品滿足用戶或用戶市場，例如：
- 陌陌：一款基于地理位置的移動社交工具
- 飛聊：興趣社交APP
用戶定位的描述：針對什么目標群體，做什么事情，用最本質的，無修飾的語言表述。
4.2 產品核心目標（產品本身要達到什么一個目標）
互聯網產品的核心目標，往往表現為要解決目標市場（目標用戶）一個什么問題。這個問題分析的越透徹，產品的核心目標也就越準確 ，確立好核心目標，不會使我們產品推進的過程中迷失。
例如：
360安全衛士：解決用戶使用電腦的安全問題
微信：在最早的階段，微信的核心目標是工具類的，為用戶提供流暢語音溝通的移動應用
通常來說，解決核心目標的工作優先級是最高的。產品任務，很多應該是圍繞核心目標來開展的。所以，產品經理對于用戶需求與產品核心目標關系的拿捏是個很重要的工作。
4.3 產品結構（注意，不是功能結構，是產品的整體結構）
產品的市場定位，產品定位，核心目標的直接表現。
4.4產品路線圖
產品路線圖是產品成長中的每個任務節點組合而成，是以任務為導向的時間節點圖。
應注意一下，任務一定是和產品定位，核心目標等相符合的，是達到這些目標的任務分解。
4.5產品功能性需求
在線留言板舉例：
- 注冊與登陸（直接注冊，第三方注冊，直接登陸，第三方登陸）
- 交流（留言，回復，圖片上傳，文字發布）
- 管理（查看，刪除，修改）
4.6產品非功能性需求
- 埋點需求：為了便于數據分析需要做相應的埋點
- 性能需求：產品流暢、不卡頓等
- 擴展性需求：產品與技術架構都要可擴展
- 安全性需求：做好各種攻擊、爬蟲的防范
- 健壯性需求：產品要足夠健壯，不崩潰、不宕機，可以算入性能需求
- 兼容性需求：要兼容各主流瀏覽器、手機系統、屏幕尺寸等
- 可用性需求：產品的基本需求要滿足可用性原則
- 運營需求：運營的一些數據統計、活動運營等需求
- 用戶體驗需求：好的產品一定用戶體驗好
3、產品結構與功能結構的區別
這里我們把整個產品看成是一桌菜。
產品結構講的為了讓客人吃的舒服同時又要完成我們的核心目標，我們需要哪些菜品，而這些菜品與菜類需要我們事先規劃出來：
- 涼菜：涼拌則耳根，夫妻肺片等
- 熱菜：佛跳墻，麻辣雞絲等
- 主菜：宮保雞丁 蒜蓉蝦 烤扇貝
- 甜點：地動山搖，巧克力布丁
- 飲料：酸奶，玉米汁
功能結構：我們如何實現上述的各種菜品？
- 加熱：熱菜
- 爆炒：主菜，熱菜
- 材料：則耳根，肺片
- 人員：廚師，墩子
產品結構說明的注意事項：
這里不是扣細節的時候，主要產品結構表述到位即可。
因為你之后肯定會非常苦逼的做非常細的產品說明與線框圖、流程等。
- 一些無法歸類的，放到其它里面
- 如果能配合流程圖與簡單的主要頁面線框圖就更好了，更清楚，更明了
4、優秀MRD的特點
- 邏輯性強：有論點，有論據，有論證
- 把抽象的東西形象化的講出來
- 數據可靠，分析有理
- 有把握的主觀，無把握的客觀
- 惜字如金，能把問題表述清楚，絕不多寫一個字
- 合理的產品進度分配更有利于研發人員工作（人有九等，不是所有人的人都是打了雞血的產品經理）
- 重視非功能需求
- 如果方案中出現很多專業名詞，記得在文章的開通呈現給閱讀者一個名字解釋表
5、小結
二、PRD
1、匯報對象
匯報對象：老板、開發、設計、測試、運營等。一般我們在做出比較大粒度的PRD之后就會做一次評審，以便盡早發現問題。
我這里還是特意把匯報對象單獨提出來，因為你的匯報對象決定了你應該把文檔寫成什么樣，評審的時候你該怎么講。
你要匯報的對象涉及到多個部門，這些部門的人員素質都不一樣，怎樣有效的把PRD描述出來，讓各方都能夠聽懂，是一個很考驗產品經理功力的事情。
2、PRD內容結構
PRD包括但不限于以下這些內容：
1. 文檔說明
1.1 產品說明
- 背景描述：為什么要做這個產品、市場行情
- 業務目標
- 產品定位
- 用戶群體及其特征
1.2 更新記錄
序號、文檔版本、修訂日期、修訂人、修訂章節即內容、修訂原因、審核人
產品版本的命名：
以產品版本1.2.6為例，1為主版本號，2為子版本號，6為修正版本號。
主版本號通常是重大調整升級、產品結構功能等都有調整時，進行修改。
子版本號通常是在原有基礎上對局部功能進行了升級或調整時，進行修改。
修正版本號通常是局部小范圍優化與bug修復時，進行修改。
歸零原則：前一個數字增加一位，后面的數字都歸零
1.3 溝通意見
主要記錄與各部門溝通的歷史，包括溝通部門、溝通人員、溝通內容描述、溝通結果、溝通日期
1.4 名詞術語表
對于文檔內的各個名詞術語進行解釋，包括詞匯名、對應的別名、具體的說明。
1.5 數據字典
數據字典就是數據庫各個表結構的描述，用于文檔內需求的精準描述。
1.6 開發排期
產品經理需要把控開發進度，直接在PRD里記錄是其中一個方法。以下是一個示例。
1.7 交互自查表
交互自查表是產品經理用戶檢查自己產品設計的工具。
2. 產品概念設計
2.1 產品概念圖
產品概念圖描述產品的大致思路。以下是一個簡單的產品概念圖示例：
2.2 功能結構圖
功能結構圖描述產品有哪些功能。
2.3 信息結構圖
也稱信息架構圖，我的理解是產品內字段的分類整合，這些信息是研發人員建立數據庫的參考。
我推薦先思考功能結構圖，在做信息結構圖。
2.4 產品結構圖
產品結構圖是按照產品的邏輯與表現方式，結構化的表現產品構造的一種示意圖，可以說是產品的頁面功能與信息拆解。
2.5 Feature List
即需求列表。以下是一個簡單的示例：
2.6 業務流程圖
根據上述各種結構圖，畫出產品內業務的流轉過程，是從產品角度來講的。
畫流程圖的技巧：
從主線，到支線
從正常流，到異常流
不要把整個流程畫到一個頁面里面，可以使用分頁來進行調整，這樣更清晰更易于講解和使用與傳遞。
有自己的圖示，表明清楚每個圖示的意思。
2.7 任務流程圖
任務流程圖就是產品內完成各項任務的流程圖，是從用戶角度來講的，通過用戶行為串聯信息結構與產品結構，閱讀者通過閱讀用戶使用流程，能更好的理解產品經理設計的用戶行為。。以下是一個小程序登錄的流程圖：
2.8 頁面流程圖
主要是頁面之間的跳轉關系。
3. 全局說明
3.1 功能權限
后臺/B端產品和部分用戶端產品會設計到用戶使用權限的管理，此時需要在這里進行全局性的說明。
對于復雜的權限，也要在相應原型旁邊注明權限。
3.2 全局交互
3.3 鍵盤說明
輸入特定的內容時，彈出特定的鍵盤面板。如輸入銀行卡密碼時，彈出亂序的數字鍵盤等。
3.4 toast提示
一般設置1-3秒后消失。
3.5 dialog彈層
涉及到需要用戶確認的場景，屬于強制中斷用戶操作的行為。
3.6 加載方式
全屏加載
對整個頁面進行加載，可以保證內容的完整性，但會讓用戶產生強烈的等待感，3s以上會有焦躁情緒。
所以全屏加載最好要配合上有明確進度表示的進度條。
上拉加載
常用于信息流、長列表形式的產品，用戶可以一直沉浸在內容里。
下拉刷新加載
更多的是承載刷新的功能，比如新聞APP里下拉可獲取更新的信息。
優先加載
對于重要內容進行有限加載。
占位加載
如果網速狀況不好的話，先進行占位性的展示。
加載都是需要一定的時間的，為了減少用戶的等待感，我們可以使用非模態的加載方式，適當的給一個取消的選項；也可以使用情趣化的加載動畫；或者提前預加載，對內容進行緩存；還有就是告知加載進度。
更詳細的加載方式，可以參考這篇文章《常見的七種app加載樣式設計》
3.7 啟動頁
啟動頁是展示我們產品的信息，還是展示產品的初步引導，又或者是展示廣告，是需要我們綜合考慮產品目標、產品生命周期等因素的。
3.8 異常
異常有很多種，網絡異常、服務器異常、加載超時等等，但通常我們都把它們當做網絡異常來展示給用戶，并提供說明引導和解決方案。
展示的方式可以使用toast提示、全屏提示、dialog提示等。
3.9 常用字段說明
這些和數據字典和信息結構圖息息相關，我們需要對產品中相關模塊（如表單填寫、信息展示等）內的元素定義格式，比如字段的長度、數據類型、是否必填等。這個東西非常重要，是開發設計表結構的重要參考。
4. 詳細功能說明
詳細功能說明是整個PRD文檔里占比最大也最核心的部分，我們之后講的內容也基本都是這里的東西，現在大家只要了解PRD的內容結構是什么樣的就行了。
PRD如果是直接寫在Axure文檔里的話，詳細功能說明基本就是原型+標注了。
標注一般就是在原型旁邊寫上視覺說明、交互說明（給開發看到，最重要）、運營說明等一系列說明。
以前很多人說用Axure寫PRD不方便進行版本管理，其實是不對的。我們有三種方式對版本修改進行管理：
- 直接在相關頁面記錄歷史的修改：好處是能看到自己每次修改的演變過程，壞處是文檔會越來越龐大。
- 每次修改都存成一個文件：更好的存檔，但不方面查看。
- 使用Git/SVN等版本管理工具：可以看到查看之前的版本，Axure自帶有SVN。
事實上，我會三個方法同時用。
現在小一些的公司有時是不會做在原型上做完整的交互的，一般會在原型上標注交互的規則。
如果是用Word來寫的話，就要復雜一些。我就一開始的時候用過Word等文本型的文檔寫PRD，但現在發現用Axure寫真的很爽。當然還有一些產品會用墨刀這樣的快速設計原型的工具，也是不錯的選擇。我沒怎么用過這種方法，在這里也就不分享了。
5. 非功能性需求說明
在MRD中，非功能性需求是不用詳細說明的，但在PRD里就需要產品經理根據具體的產品設計，詳細說明非功能性需求。這部分內容是開發、運維、測試的重要參考。
6. 上線核查表
這里主要寫明上線需要的各種東西，如：申請App Store賬號、宣傳物料的準備。
這些都是固定性的東西，我們把它當成每次上線前的產品核查表。
7. 運營計劃
產品上線后的運營方案。產品可以先列出一個簡要計劃，然后和運營討論出一個完善的方案。
8. 效果審核表
我們的每一次改版上線，都是基于業務目標的，所以產品上線后，我們需要追蹤產品是否達到既定業務目標。這里會提供上線效果的審核表，包括產品版本、上線日期、預期結果、實際結果等。
3、優秀PRD的特點
- 正確 ：確保文檔中的表述與產品經理的思路是對應且正確的
- 無歧義 ：文檔的表述方便閱讀理解，不會產生歧義
- 完備 ：MECE原則盡量保證對產品功能需求表述的系統完整
- 一致 ：文檔中用詞用語一致，對于同一事物的表述應該一樣，避免混用同義詞
- 具有優先級 ：產品的功能性需求是有先后主次的，對于一次性規劃叫多功能的PRD，應該注明功能性需求的先后主次
- 可驗證 ：對于功能性的描述，是可以進行測試的，而不是不發測試，無法定性的東西，例如：效率高，交互完美等詞語，都是無法驗證的
- 可修改 ：PRD文檔利于后期的修改與升級
- 可追蹤 ：每個功能性需求的來源應該是清楚明白的
4、小結
我這里提供的僅僅只是模板，大家要根據實際情況進行增減。
三大文檔總結
回顧我們所講的3個文檔（BRD、MRD、PRD），可以發現三者是一個層層遞進的關系。
MRD可以說是BRD的進一步細化文檔，BRD更多是以PPT的形式呈現，MRD可能就需要用文檔形式呈現了。PRD可以說是對MRD的進一步進化，PRD可以用Word、Axure等各種形式呈現。
上面的PRD我真的只是在列一個模板，很多細節不好講述，如果大家有不明白的可以在評論區提出來，我會進行一一解答。
產品經理平時工作中涉及到的文檔還有很多，但都沒有固定性的標準。如果之后我無聊的話，會進行一個匯總。
預告：下一篇將會講《交互設計與用戶體驗》
