產品新手上路：BRD、MRD、PRD的差異
前言
產品開發中的三個關鍵文件：BRD、MRD和PRD，是產品新手常常混淆的文件。當我還是產品小白的時候，也常常在產品文件中迷路，因此花了一些時間去探索文件的製作方法及架構，這邊把我所知的部份整理出來，希望能幫助跟我一樣在產品路上的旅人們。
文章重點目錄
> BRD、MRD、PRD的差異
> 簡易的產品發想流程
> BRD 文件架構
> MRD 文件架構
> PRD 文件架構
> 快速產出文件的小撇步
這篇文章適合誰讀
新手導向，這篇文章只針對MRD、BRD、PRD差異作基礎說明。 比較適合產品小白、新手產品運營人，任何想搞懂產品PRD等文件製作方法、開發流程的人。如果你本身已是資深產品人，這篇文章對你而言可能過於淺顯。如果你對文章有任何建議或指教，隨時歡迎底下留言交流，或者與我聯繫，我會很開心的。(我真的很想認識產品大神)
由誰來製作文件呢？
通常是由PM (Product Manager) 進行產品梳理以及需求排序等的工作後，逐一將文件彙整製作成型，並且向各單位及利益關係人等討論溝通，最終決定產品的執行與否。但在資源比較精簡的公司中，也有可能是UI或UX設計師兼任PM，又或者是企劃、業助等職務來兼任文件製作的任務。
但不要忘記，文件的主要目的，是為了幫助團隊溝通釐清產品的方向與執行方法，不論由誰來寫，都不會脫離溝通這個主要目的。
那不寫文件會怎樣
溝通當然要保持彈性，最難的部分就是要針對團隊規模與溝通、工作習慣，去產出一份大家都能清楚明瞭的產品文件。
當然也可能有些團隊是不寫文件的，不寫文件的團隊，或許只是有非常多不同的文件散落各地，又或許是因為真的忙到沒有時間、沒有人可以寫。
不寫文件的話，可能會發生以下三種狀況：
- 沒有明確方向
文件可以幫助團隊釐清產品方向，避免大家對產品的概念、功能、需求等等，存在模糊空間，導致理解不一致，進而產生許多溝通上的落差。 - 缺乏可追朔性
產品開發的時程是很長的，執行內容也很繁瑣。文件記錄可以把確定的需求通通白紙黑字列出來，當產品走偏、或是執行中有些細節忘記時，就可以用文件去做功能細節的回顧。如果沒文件，團隊可能就會出現各種「我記得當初⋯⋯」，最後也吵不出誰對誰錯，變成所有細節都要再花時間重新討論一遍的窘境。 - 無法同步協作
文件同時也是個產品的佈告欄，當有些功能做修正時，修改文件可以讓各執行單位了解修改的細節，並且一起進行評估與討論。所以這個環節如果脫節了，就有可能各單位執行方向都不一樣，最終串接時會出現非常多BUG，交付時程又得往後延。
為了能順利推進專案，還是建議產品人盡量找到自己的文件梳理方式，如此一來就能幫助團隊釐清產品，也能減少時程延宕、溝通不良等問題。
BRD、MRD、PRD的差異
為了避免溝通落差，確保團隊成員們都有好好走在同一條產品路上，因此產品開發的過程，PM會需要製作許多文件來輔助團隊溝通。
其中有三項文件在產品開發時常用到的：
- BRD (Business Requirement Document) 業務需求文件
- MRD (Market Requirement Document) 市場需求文件
- PRD (Product Requirement Document) 產品需求文件
要分辨這三個文件很簡單！只要看開頭的英文名稱就知道了！ 人如其名，分別是Business、Market、Product，只要看英文開頭就知道了。
文件功能說明如下：
- BRD (Business Requirement Document) 業務需求文件
有承上啟下的作用，幫助我們釐清商業模式的可行性，也是我們說服老闆或投資人，投入資源，確認專案執行與否的關鍵文件。 - MRD (Market Requirement Document) 市場需求文件
確認產品的市場定位，找到市場區隔與潛在客戶，讓營運與行銷單位清楚產品定位及任務。 - PRD (Product Requirement Document) 產品需求文件
開始執行開發，透過PRD文件讓所有執行開發人員了解開發需求。文件會隨著每次開發進度會議，在產品開發進行中，不斷修正再修正。(部分公司可能是用spec文件，不過文件的功能與內容大同小異)。
我畫了一張圖來幫助大家釐清這三個文件之間的關係：
產品發想流程
BRD、MRD和PRD，這三個文件貫穿了整個產品的開發流程。
產品通常都是由發散的想法，慢慢地聚焦、取捨、融合⋯⋯最終才會變成一個產品。我非常簡易的用下圖，來表示這三種文件在一個新產品的發想過程中所擔任的位置。
上面這張圖只是個概觀，而且是單向軸。但實際上在產品的發想及開發過程中，這些流程可能是環狀的，必須經過不斷來回討論、修正，才會走到最後的「交付」階段。然而，想做一個產品，當然沒有這麼容易。通常在產品「交付」以後才是重頭戲的開始，後續的產品運營、行銷廣宣、優化迭代等還有很多眉角，不過這些都是後話了。
回歸正題，每家公司可能都有自己習慣的產品發想流程、文件撰寫格式、內容規範⋯⋯等，因此文件的部分，說是一回事，但在實際撰寫時，還是要針對文件的溝通對象或開發流程，做內容調整。
畢竟文件的最終目的，還是要達到「溝通」成效。當我們搞清楚這三個文件的差別後，接著就來列出BRD、MRD、PRD的大致內容架構，給各位參考。
以下三種文件可能有部分單元重複，又或者功能性差不多，因此架構會以本身經驗撰寫，不一定符合每一個專案及每家公司的撰寫習慣，大家需要根據狀況與需求自行調整。
BRD 業務需求文件
Business Requirement Document
- 也有人稱作「商業需求文件」
- 主要觀看對象：老闆、投資人、股東
在開啟一個新業務內容時，BRD文件的用途是找資源、拉投資，或者得到老闆、主管、股東認可開發，因此要強調產品優勢、發展可能性與預估目標等。
BRD的製作重點
- 產品發想源自於哪裡？我們預計將產品做成什麼樣子？
- 為了做這個產品，我需要哪些資源？
- 這個產品的潛力，以及我如何用這個產品賺錢？
BRD文件也可能包含這些項目
有可能發生的狀況
我自己有遇到過的狀況是，有些公司在評估一個新項目的開發時，可能是以「老闆需求」為準。因此新業務的展開，也是可能在不做任何市場分析與問卷調查的情況下勢在必行。這時候，市調與問卷的環節就會被刪掉。(當然，假如你的狀況允許，也可以先做調研，然後說服老闆放棄、或者改變作法。)
有些老闆日理萬機，可能會推崇說他只看一張A4的極簡報告。這時候PM就要把繁瑣的部分省略，擷取出老闆最想看、或者最在意的部分(通常是成本與未來預估收益的部分)，等老闆有興趣想了解更多或是有詢問時，才去提供其他部分的細節。
遇到以上幾種狀況時，BRD的內容就會有刪減。
MRD 市場需求文件
Market Requirement Document
- 也可能被稱作「市場報告」、「運營規劃書」等
- 主要觀看對象：營運單位、行銷、業務、合作夥伴
文件用途是讓團隊的成員們清楚了解，這個產品要做什麼(幫助用戶解決哪些問題)、運營的方向、TA是誰等⋯⋯，讓參與專案的成員們清楚了解產品定位，未來的營運方向，以及各自肩負的任務。
MRD的製作重點
- 產品的功能、用途、定位及願景。
- 競品分析、市場區隔，主打客群(TA)是哪些人。
- 潛在的客戶(TA)，產品未來可能的發展方向等。
MRD文件也可能包含這些項目
有可能發生的狀況
MRD的文件看起來洋洋灑灑，不過有些部分還是要看公司的職務內容，產品經理在撰寫MRD時，可能涉及或涵蓋行銷或更詳細的營運面事務。
以我自己為例，PM的功能主要是針對「產品本身」的生命週期，以及產品各階段任務做規劃。也會需要針對預期目標與營運方向去做執行階段的拆解。但針對「用戶」獲取的行銷規劃，則不會特別列入MRD文件中。
假如公司分工較細的話，像是「STP分析」、「行銷4P+4C」，可能是由行銷單位進行規劃與執行；另「用戶誌」、「用戶旅程」的部分，若公司有專責的UX/UI，也可能是由設計單位來執行規劃。這時候，PM在這之中所扮演的角色，則是確認各單位製作出來的產品方向一致，並將內容整合。
文件內容需要涵蓋哪些內容，除了公司原本的習慣與文化差異以外，也可能因為職務內容的不同而有所差異。最主要還是要考慮到該份文件的觀看對象是誰，再去決定文件內容。如果文件觀看者其實不需要這些內容，資訊太雜反而會造成對方還要另外花時間去篩選內容，在溝通效率上就有可能產生反效果。
PRD 產品需求文件
Product Requirement Document
- 也可能被「SA文件」、「Spec文件」等文件取代 (視公司文化與工作習慣而定，有時候資料會拆得比較零散，以便各個協作單位能快速執行。)
- 主要觀看對象：開發、測試、技術員、驗收單位等
文件用途是讓團隊的成員們清楚了解功能列表，及這個產品的開發細節，如：功能性需求、非功能性需求、需哪些欄位、如何操作、安全性、產品運作邏輯等⋯⋯
PRD的製作重點
- 文件修正版本紀錄 (修改日期、版本等等)
- 產品用途說明
- 產品功能目錄，針對各個功能做簡述說明。
- 針對更詳細的「產品功能說明」的補充資料。各單位協作時，可能會有不同的資料溝通需求，如API文件、Flow chart、Prototype、字元定義表等⋯⋯各式各樣的延伸文件。
PRD文件也可能包含這些項目
有可能發生的狀況
有些公司會做PRD，但有些公司則是用Spec文件，又或者是「產品規格書」、「開發計畫書」等等。不論是文件名稱為何，這份文件的目的，都是為了讓開發團隊清楚了解產品執行時的細部需求。
當然我們很難一口氣，就將一份開發文件寫到100%完整。在執行過程中，可能會遇到各種不同的資料需求狀況，比如我們在討論A文件時，又另外延伸出各種B、C、D文件，來輔助更細節的狀況說明。
假如你所處的單位，在開發時有多份文件，或是有頻繁的異動修改時，就要特別注意「文件版本管理」，確保工程、開發單位在製作時，所參照的資料都是正確的版本、正在執行的項目都是最新的需求規格。
如我所待的單位，時常在時程緊湊時，直接省略掉wireframe規劃，與可用性測試環節，直接製作高仿真Prototype(交互原型)，請前端工程師刻板。(Prototype製作的完成度要多高，也會因工時、公司文化等而有不同程度的變化。)
針對圖片上所列出的「數據需求」的部分，在這邊特別說明一下。
不一定每個專案的開發都需要用到「數據」，如單純的形象網站開發，可能就不一定會用到。但如果產品有牽涉到購物車功能、或數據分析時，用戶就會有運算或者資料分析的需求。這時候PM就需要針對資料欄位，提供一些參考的Excel表格，或是各單位所需的過往表單等資料(比如訂單格式、公司內部表單等)，作為產品執行開發的參考。
補充一下，有些公司也會把「專案時程」、「驗收標準」等環節列入PRD中，但我這裡並沒有特別列入。我在製作PRD文件的習慣是，只列「產品本身」的規格需求，像「時程」的部分，會因為開發過程中所遇到的各種開發狀況，如時程delay、人員異動、技術執行有難度等各種狀況的發生，而需要頻繁調整。
因此時程管理，通常都會拉出來用Asana或Trello等專案管理工具進行。而「驗收」的部分，因為驗收與測試過程中，會需要頻繁溝通，因此通常習慣使用Google sheet、Notion等工具以利溝通協作。
快速產出文件的小撇步
文章前段有提到，我們從BRD文件中取得開發核可，在MRD制定營運戰略，而PRD就是將產品實踐出來。
從上面三種文件中，我們可以發現三個文件的組成，或多或少有一些重疊的部分，因此當所處的單位需要同時製作這三種文件時，
這些內容就會像下圖這樣子呈現：
我們也可以預先將內容整理出來，這樣在製作文件時就能清楚知道，有哪些內容是重疊的，又或者有哪些部分是可以快速修改、延伸成另一份文件的。如果單位的專案開發原本就已有既定模式在運行，那麼預先製作好文件模板，也是個加快自己產出的好方法。
我後來寫了產品發想的分享文章，裡面有提供「市場調查」、「價值主張圖」、「商業模式圖」、「人物誌」的模板給大家參考，也有提供我編輯好的模板，大家可以下載來修改與延伸：
結語
之前看過前輩們是用這麼一句話，來形容這三個文件的關聯性：
BRD 是產品的 Head (或是 Why)
MRD 是產品的 Body (或是 What)
PRD 是產品的 Heart (或是 How)
我認為這三個文件就像是專案從不確定到確定，逐漸收斂成形的過程。產品文件在經歷無數次的「溝通+修改」中，變得越來越明確。(雖然也有是可能大家討論完後，發現完全不可行)。
以上概略的PM文件整理說明，希望有幫助各位釐清各個文件的差異，但願同在產品路上迷途的新朋友們都能順利找到方向。
