寫PRD，不用糾結MRD、BRD｜PRD文件才是產品經理的核心任務

PRD 文件是什麼？PRD 的全名是 Product Requirement Document，也就是產品需求文件。這是一份由產品經理負責撰寫的核心文件，詳細描述了產品的功能、特性、行為以及使用者界面設計，是整個產品開發過程中的「藍圖」。PRD 的目的是幫助工程師、設計師以及測試人員清楚理解產品需求，確保開發方向與目標一致。

雖然 MRD（市場需求文件）和 BRD（商業需求文件）同樣重要，但它們的撰寫並不一定由產品經理主導。BRD 通常由高階主管或商業分析師負責，專注於商業目標；MRD 則由行銷經理（Marketing Manager）撰寫，聚焦市場需求和用戶行為，相比之下，PRD 更偏重產品落地執行，是產品經理每天要專注的主要工作。

註冊頁PRD範例，你能找到問題嗎？

下圖是一張「註冊頁」的PRD產品需求文件，你有沒有發現什麼問題？仔細想一想。

1. 重覆性資訊：電子郵件和密碼的提示標題（2號和4號標注）重複了，這會導致閲讀者的混淆，例如，工程師就會跑來跟你講，你是不是寫錯了。
2. 本地化與國際化：這份PRD是否已經考慮到多語系的支援？因為從提示文字來看，目前似乎只有繁體中文的版本。
3. 用戶場景定義：從這個PRD來看，無法得知這個界面是在APP上，還是在網頁上，而且，若是網頁，是否只針對小網設計？還是是自適應網頁，也就是常聽到的RWD（Mobile Web或Responsive Web Design）。

除了上述所說，其實還有好多好多問題……，因為，這只是「一頁的註冊頁PRD範例」，並不是完整的PRD文件，所以你能看出的問題，別人也能看出來。

因此，整份的PRD文件會需要各個單位的人一起確認規格內容才能完成，不過不必擔心，一旦經過幾次的經驗，產品經理就會對這個「流程」熟悉了，自然就會理解該怎麼規劃出一份「完整」的PRD文件，因此，在產品需求說明會議之前，建議先找其他單位的人溝通，以避免在正式會議上變成批鬥大會。

PRD 是什麼？它為什麼重要？

PRD就像產品的說明書，把產品的目標、使用者、功能、介面、數據等等都寫得清清楚楚。一份好的PRD 不只會說產品要做什麼，還會解釋為什麼要這樣做，甚至告訴你怎麼判斷產品做得好不好。

寫PRD的目的，就是要讓所有參與產品開發的人，不管是設計師、工程師還是產品經理，都能對產品的樣子有清楚、一致的理解。這樣大家就能提高工作效率，減少誤解和重複工作，做出真正符合市場和使用者需求的好產品。

而我習慣用Axure來寫PRD，但最近也在學Whimsical這個工具，但它主打Low-fidelity，不過上手速度很快，操作也很順。但不管用什麼工具，寫PRD的重點就是要讓團隊成員對產品有共識，減少溝通上的障礙，做出真正符合市場和使用者需求的好產品。

PRD 的核心概念與用途

定義與基本功能。PRD 在產品開發生命周期中的角色和重要性。

PRD 的結構與組成

PRD 文件的核心要素：產品目標、需求細節、優先級設定等。結構範例與實踐指引。

如何撰寫 PRD？步驟與實操技巧

以下，只是一個範例，請依照自己的狀況來寫，基本上就是有多少時間做多少事情，雖然老闆、主管不願意聽這些理由，但實際上也是實話。

修訂追蹤表

為了保持PRD文件的清晰和準確性，對文件的每次修改都需要記錄，而這樣的表格是向團隊展示更改發生的具體位置，避免他們每一頁都要看到底改了哪裡，同時，此記錄對於回顧和自我檢討也非常有幫助。

背景簡介

撰寫PRD中的背景簡介有助於明確界定產品的發展緣由、與公司業務的關聯，並呈現對市場的深入理解。

背景部分說明了產品構思的來源和必要性，價值部分展示了產品在市場中的定位和其實現的可能性，而目標則提供了一個清晰的視野，確立了產品發展的方向和遠景。

這些元素合在一起，為團隊提供了共同的理解基礎，增強了團隊對專案的承諾和方向感，這有助於凝聚團隊目標

當然，你要寫的有引人入勝有故事性一點、讓人覺得做開發這個產品是有價值的，不要讓人覺得開發這個到底要衝三小。

功能清單

功能清單是PRD的核心部分，因為這裡能明確定義產品必須具備的功能和特性，用列表呈現時有助於確保開發團隊理解產品的需求和期望。

功能流程

在PRD中放置流程圖能夠直觀討論、思考工作流程或用户操作流程，幫助團隊成員理解產品的功能結構和交互邏輯，且還能能夠使複雜的過程一目了然，這有助於確保開發過程中的各項功能和需求得到完整實現，某種程度還能讓某些單位畫押同意、認同、吞下去這一段流程他們要協作。

流程圖不會畫？請參考我這篇「流程圖｜產品經理必學的流程圖畫法與應用」文章。

功能結構

功能結構圖依功能的不同，用視覺化的方式呈現出來，這樣做有助於團隊對產品有一個整體的理解，還能確保在開發過程中不會漏掉任何功能或頁面。

你需要畫出讓人清晰識別出各功能模塊之間的邏輯關係，因為這可以為所有團隊評估所需工作量提供了參考。

頁面設計（wireframe）

Wireframe的用途主要是在產品開發早期階段，為網站或APP界面提供一個基本的結構視覺化概念，它專注於排列頁面的功能元素，包括頁面的布局、功能分布和用戶如何與界面互動，且不涉及具體的設計細節如顏色或圖形。

要注意的是，因為這裡你動到設計師的工作範圍，一些設計老屁股會在需求會議上狂電你為什麼要這樣設計，而你只要進行產品的基本架構設計，並在設計和開發過程中促進團隊成員間的溝通和協作即可。

最終設計師產出來的UI稿，你的Wireframe也要一起同步更新，以免工程師跑來問到底要看誰的。

記住！wireframe（線框圖）要去掉Look and feel（視覺和感覺），重點是確認產品邏輯。別被外面那些乙方公司用Axure做的漂亮demo給騙了，那是他們用來營造懂高層需求、要確認現在的UI高層買不買單，跟產品經理實際開發產品不一樣。

Wireframe 的定義與重點

定義

清晰描述功能是什麼，例如搜索按鈕的位置與行為。

資料來源

指出資訊從哪裡來，可能是用戶上傳或後台提供等。

交互

涵蓋各種互動方式，如點擊、長按等（UI/UX的範圍一定要和設計師討論）。

邊界

描述特殊情況下的表現，如無內容時的顯示方式（總之要想到各種Corner Case，因為好的QA工程師一定會測到）。

驗收標準

設定標準，因為好的QA工程師一定會「正面測一次、反面測一次」找出你的邏輯問題。

生成 wireframe 工具介紹

Banani

Banani 是一家利用 AI 技術幫助設計自動化的公司，讓 UI 設計變得更輕鬆。只要輸入一些文字描述，就能快速生成 wireframe 和介面，省下設計師和產品經理在初期設計時耗費的時間和精力。

這很適合那些需要快速原型設計的團隊或新創公司，即使你沒有專業的設計背景，只要有個大概的想法，Banani 就能幫你把它變成視覺化的成果。對於想要簡化流程、加速產品開發的人來說，這真的是個好幫手。

不過，一次只能一頁，而且沒辦法一口氣生成山所有的流程。

Banani | AI Copilot for UI Design | Generate UI from Text

Uizard

Uizard 也是一個基於 AI 的設計工具，能快速生成 UI 設計和 wireframe 而設計。這個工具也是讓用戶輸入文字描述，就能迅速轉化為 wireframe，真的節省了大量的時間和人力。

但是產出的 UI 和我輸入的文字描述差距很多，可能還需要花不少時間和 Uizard 好好「溝通」。

Uizard: UI Design Made Easy, Powered By AI

Visily

Visily 這個工具的特色是簡單易用，結合 AI 技術，讓用戶只需拖放元件、下些文字描述，就能迅速設計出 wireframe，Visily 支援團隊協作，讓多個成員能夠在同一專案中即時進行編輯和反饋，非常適合跨功能團隊使用。

目前看起來它蠻適合多人一起討論和協作的，文字描述下好之後產出的 wireframe 也不會離我想像中的差太多。

Visily – AI-powered UI design software

Relume

Relume 也是一家專注於設計和開發工具的公司，能提供更高效率的去建立網站或是APP，它們主要是透過 Webflow 的組件庫，讓使用者能快速拖拉設計元素，簡化整個網頁設計的流程。

目前的感受是，它的指令理解程度蠻好的，大家可以試試！

Relume — Websites designed & built faster with AI | AI

要用什麼工具寫PRD？

根據我的經驗，在各家公司大部分的單位，都會告訴你，你用什麼工具、文件、呈現方式寫PRD文件都可以，只要相關的協作人員可以看懂就好。

但是，就是這個但是，你最好看看在你前任的產品經理是用什麼工具、方式、格式來寫PRD的。

為什麼？前面的產品經理如果有留下「大量」的規格，你真的會想要因為換工具而重寫一份規格嗎？或是改寫現在所有團隊都能夠看懂的格式嗎？

就算你有時間、有能力重寫，那麼，你的時間是公司的資源，你的老闆會同意嗎？

如果可以，先看看前任產品經理，以及現在的產品經理同事，他們都用什麼工具來寫PRD文件，是比較好的第一步。

正常的公司，規格通常是會有「延續性」的，每一個階段都會紀錄下來，留給「後人」去做產品規格的瞭解，而不該是讓人「考古」公司的產品應該是什麼樣的。

如果有一個系統，是公司服務中斷後才會提供，你真的會要求公司中斷這個系統給你試試看這個功能嗎？這就是很多公司做產品但拿不出來規格文件的問題，甚至還有老闆會說：「之前團隊跑敏捷跑太快了，所以PRD規格來不及寫」這種幹話，有這樣的老闆，你試著想一下一家公司的新人，要怎麼來理解現在產品的規格呢？

另外，建議新到職的新人們，選擇公司裡大家都在用的工具是比較好的方法，也是一個能讓其他同仁可以「快速上手」的好方法，總不能全公司的產品經理有人用Axure、有人用墨刀，還有人用Figma吧？

其他單位怎麼看PRD？

在任何產品開發過程中，溝通總是一個挑戰，尤其團隊規模很大的時候，如何確保每一個成員對產品的目標和需求有一致的理解就顯得很重要了，這也是PRD文件最有價值的地方。

為設計師提供明確方向

UI設計師和UX設計師是產品開發過程中不可或缺的角色，他們根據產品經理提供的PRD，進行互動設計和視覺設計，透過深入理解PRD中的流程與邏輯，設計師能夠設計出較符合產品需求的方案，還能避免在設計過程中偏離預定目標。

當然，你的PRD文件主要是產出之後，先和UI/UX設計師討論之後，才會形成較為具體的PRD文件版本，千萬不要自以為是的覺得這個界面就應該要這樣設計，要記得，要取得大家討論中的平衡點來規劃，也不是要你什麼不合理的規劃都要吞下去。

開發工程師的邏輯參考

對於開發工程師而言，PRD不僅是他們的指南針，還是他們的字典，從技術評估到開發途中的全部過程，開發團隊依賴PRD的產品框架、邏輯流程、頁面細節、資料呈現等細節，以確保開發過程中都能有效執行，符合產品目標和品質要求。

當然，你也可能會遇到自走砲型的工程師，完全照著自己意思去開發，完全不看PRD的，通常有這種情況，就是公司沒有制度、沒有養成「職能分工」的文化，主要的問題，還是在老闆身上。

確保測試工程師的準確驗收

測試工程師在產品開發中扮演著守門員的角色，也是公司品質的最後一道防線，他們需要確保產品在正式推出前的每一項功能都能正常運作，那麼，他們的根據來源是什麼呢？那就是要符合PRD的定義。

在前期，測試工程師會仔細分析PRD文件，接著，測試工程師可以開始寫Test Case，當開發完成可以進入測試階段時，能以此PRD基礎進行功能、邏輯上的驗證。

PRD還能做什麼？

記錄變更

需求管理，在產品開發過程中，需求的變更是不可避免的，PRD作為一個動態的規格文件，能夠幫助團隊追蹤需求的變更，並確保所有成員都能夠及時獲得最新的資訊，從而減少因溝通問題更而導致的混亂和誤解。

累積知識

如同之前提到的，可以讓新人快速上手，對於新加入團隊的成員來說，PRD提供了一個快速了解產品的途徑。通過閱讀PRD，新人可以迅速掌握產品的目標、功能需求和設計原則，從而更快融入團隊並開始貢獻，而不是自己摸索產品有什麼功能、用猜的、用口耳相傳的。

同時，PRD文件，還能確保產品知識的傳承，當產品經理或其他關鍵角色離職時，PRD成為了知識傳承的重要工具，讓後續接手的團隊成員可以依賴PRD快速熟悉產品的歷史和迭代過程，確保產品開發的連續性。

PRD工具與PRD實操案例：我的經驗分享

我自己的PRD範例分享

1. PRD範例一：https://bit.ly/44g8wyU
2. PRD範例二：https://bit.ly/3OIJgff
3. PRD範例三：https://bit.ly/3r5RZ39

Hustle Badger 提供的公司 PRD 資源

例如Asana、Amazon、Figma、Square，可以在這裡找到所有PRD範例。

我比較喜歡使用Wireflow方式

我真的很感激當年遇到的工程師，他們認為規格要畫出來，要畫到「點擊了什麼之後，要出現什麼畫面」的程度，所以，光是那一個APP，我至少畫了上百張的規格，那段時間奠定了我能快速產出規格的基礎。

在那個時候，各家公司的文件寫法我大概都已經參考過了，最終，看到了Nielsen Norman Group (NNG)公司所寫的一篇文章「Wireflows: A UX Deliverable for Workflows and Apps」，讓我接下來幾乎都是用這種方式和團隊來溝通。

科普一下：

Nielsen Norman Group (NNG) 是一家專注於用戶體驗設計和研究的公司，由Jakob Nielsen和Don Norman兩位大神創立，什麼？這兩位大神沒聽過？

十大易用性原則聽過吧？Jakob提出的，Don Norman door是指那些設計不良的門，讓人們不容易理解該如何打開或操作的門，這個名稱來自於Don Norman的書。

而他們兩創立的NNG，提供用戶體驗（UX）培訓、諮詢服務以及產出實證研究的文章、影片，他們在UX領域的深度研究和洞見著稱，許多文章經過多年之後仍然非常值得一看再看。

Wireflow是什麼？

Wireflow是一種結合了Wireframe和流程圖的設計方法，它用來幫助團隊更好理解一個步驟或是流程，你可以把它想像成每一張圖就是一張UI，點擊了什麼功能之後，它會告訴你每一步該怎麼走，並且用圖片來展示每一個畫面和交互邏輯。

Wireflow的用途

1. 視覺化流程：它可以顯示從一個畫面到另一個畫面的過程，並且標示出每一步的互動。
2. 簡化複雜性：當有很多步驟時，Wireflow可以把這些步驟用圖示和箭頭清楚連接起來，讓大家很容易看懂。
3. 協作工具：團隊可以用Wireflow來討論和改進用戶體驗，確保大家對流程的理解是一致的。

Wireflow實際案例分享

假設你正在設計一個購物網站，Wireflow可以幫助你展示用戶如何從首頁開始，點擊產品、加入購物車、進行結帳，直到最後完成購買的整個流程……。

每一個畫面都會被畫出來，並且用箭頭連接，告訴你用戶在每一步會看到什麼。

簡單來說，Wireflow就是用圖來告訴你「當用戶做了這個動作後，接下來會發生什麼」，這對於設計複雜的系統或服務非常有用，尤其是有閱讀障礙的工程師。

PRD 的文化差異與影響

從Hustle Badger所提供的PRD範本來看，這些公司的產品經理在寫PRD時，似乎是傾向於使用大量的文字來詳細描述內容，我判斷這與文化背景、工作習慣以及專業標準有關，我「個人猜測」以下是幾個主要原因：

文化和溝通習慣

美國的商業文化強調清晰和詳細的溝通，文字描述被認為是表達複雜思想和概念的有效方式，通過文字，產品經理可以清楚傳達背景、目標、需求以及預期的結果，確保所有相關方對文件的理解是一致的。

法律和合規要求

PRD需要符合嚴格的法律和合規要求，詳細的文字描述有助於避免歧義，提供一個清晰的紀錄，以便在必要時用於法律或合規審核。

專業標準和行業慣例

文字形式的PRD已成為一種標準做法，因為他們認為文字能夠更精確描述技術細節、需求規範和功能預期。

亞洲國家寫PRD的特點

大量使用圖片和圖表

尤其在中國的互聯網公司當中，產品經理寫的PRD裡，會看到大量的圖片、流程圖、線框圖和表格，主要是要用這些視覺元素用來簡化文字傳達定義，幫助團隊更快速理解需求。

協作工具的影響

大量使用各種線上遊協作工具，而這些工具鼓勵使用視覺化、模塊化的溝通方式，因此，PRD經常與這些工具整合，並採用簡單、明瞭的格式，方便快速分享和反饋。

速度和靈活性

亞洲國家公司，其工程團隊和產品團隊，往往都在極高的速度下進行，因此，會要求PRD能夠快速迭代和更新，所以PRD會更加模塊化、增加靈活性，這種方式比較允許團隊在開發過程中迅速適應需求的變化。

為什麼PRD會有這種不同？

我個人猜測，這些不同的格式主要來自於文化和工作方式的差異，美國人喜歡把事情講得很清楚，確保每個細節都不會被忽略，所以他們會寫很多文字來解釋。

而亞洲更喜歡直接用圖片和簡單的說明來告訴大家該怎麼做，這樣可以更快行動，遇到有問題的地方，再進行快速的溝通。

就好比講故事一樣，有的人喜歡仔仔細細描述每個場景，而有的人喜歡用圖片來幫助大家更快理解故事，這兩種方式各有各的好處。

產品經理的救星 AI 生成 PRD

目前為止，除了透過傳統的 LLM 例如 chatGPT 來協助生成部分的 PRD 之外，還有特別為了 PRD 而推出的 AI 工具，它們分別是：

• PM-AI：https://www.pm-ai.cn
• ChatPRD：https://app.chatprd.ai

這兩個工具，都是專為產品經理設計的人工智慧工具，主要都是在提升 PRD 的撰寫效率和品質，以下我簡單的說明它們的差異。

1. 功能範圍：
   • PM-AI 主要專注於 PRD 的自動生成，透過 AI 技術快速產出完整的需求文件，適合需要快速產出標準化文件的產品經理，而且生成出來的內容比較貼進台灣人常見的格式和圖表。
   • ChatPRD 除了 PRD 的生成外，還提供策略建議、指導和團隊協作等功能，適合需要深入產品策略規劃和團隊協作的產品經理。
2. 自定義程度：
   • PM-AI 提供固定的文件生成格式，靈活性相對較低。
   • ChatPRD 提供可自定義的模板，使用者可根據公司需求調整文件格式，靈活性較高。
3. 協作功能：
   • PM-AI 側重於個人使用，缺乏團隊協作功能。
   • ChatPRD 支援團隊，具備共享模板和協作功能，適合團隊共同編輯和管理文件。
4. 安全性與私密性：
   • PM-AI 未明確提及數據安全措施（中國的服務商）。
   • ChatPRD 強調數據隱私和安全，確保使用者輸入的資料不被用於訓練或出售，強調可讓使用者信任。
5. 使用者導向：
   • PM-AI 更適合需要快速生成標準化 PRD 的產品經理，特別是針對常見功能的需求文件。
   • ChatPRD 除了協助撰寫 PRD，還提供策略建議和指導，適合希望提升產品管理技能的使用者。

總結來說，PM-AI 和 ChatPRD 都是為產品經理設計的 AI 工具，但各有所長。

PM-AI 強調快速生成標準化的 PRD，適合需要快速產出的人，而 ChatPRD 提供更全面的功能，包括策略建議、自定義模板和團隊協作，適合需要深入規劃和團隊合作的產品開發專案。

產品經理可根據自身需求和專案特性，選擇最適合的工具。

PRD、MRD 與 BRD 的差異

這三個文件是產品開發過程中，你「可能」會遇到的文件，它們分別對應商業目標、市場需求和產品設計的不同層面，分別是：

• BRD: Business Requirement Document
  • 商業需求規劃書
• MRD: Market Requirement Document
  • 市場需求規劃書
• PRD: Product Requirement Document
  • 產品需求規劃書

那麼，PRD、MRD 與 BRD 的差異到底是什麼？

我們用一個簡單的例子來說明。

假設你和朋友要一起組裝一個樂高城堡，這三個文件就像是組裝過程中的計劃書，它們負責不同的事情：

BRD：為什麼要建城堡？

• 像是在說故事：為什麼我們要蓋這個城堡？
• BRD 就是商業需求規劃書，告訴所有人這個城堡要解決什麼問題、為什麼重要。

BRD 用途舉例：

• 這個城堡能讓小熊和玩具住得很安全。
• 我們需要多少樂高零件？需要多長時間？有誰來幫忙？
• 如果建好了，小朋友們會更開心，因為他們可以一起玩。

MRD：怎麼設計出最棒的城堡？

• 像是在問：大家喜歡什麼樣的城堡？
• MRD 是市場需求規劃書，幫助你確定城堡需要什麼功能，讓大家都喜歡。

MRD 用途舉例：

• 小熊喜歡有一座滑梯，所以城堡需要滑梯。
• 玩具車想要一條跑道，那我們要多加一條路。
• 其他朋友的城堡都有大門，我們的城堡也需要一扇特別的大門。

PRD：這座城堡的每一塊積木怎麼放？

• 像是在畫圖：具體告訴你每一塊樂高零件要怎麼裝。
• PRD 是產品需求規劃書，詳細說明城堡的每個部分怎麼建。

PRD 用途舉例：

• 滑梯用藍色樂高零件拼成，長 5 格，高 3 格。
• 跑道要用灰色樂高零件，寬 2 格，長 10 格。
• 大門要能開關，門把用黃色的。

PRD、MRD 與 BRD 怎麼一起合作？

我們可以這樣理解：

• PRD 是「是什麼」讓城堡變成現實：具體描述怎麼建出城堡。
• BRD 是「為什麼」要蓋這座城堡：告訴大家建城堡的目標和價值。
• MRD 是「怎麼」設計城堡：根據小朋友的需求來規劃功能。

PRD 在整體開發過程中的定位

PRD 是整體開發過程中的橋樑與核心指引，PRD 將高層的商業需求（BRD）和市場需求（MRD）轉化為具體的產品需求，這是用來解答「這款產品到底是什麼？該怎麼解決用戶需求？」，例如：

• BRD 提出「我們需要一個讓用戶能快速訂餐的產品」。
• MRD 確定「目標用戶需要點餐方便，市場希望提升餐廳曝光」。
• PRD 描述「這款APP需要有菜單展示、快速下單、訂單追蹤等功能」。

簡言之，PRD 將商業需求 (BRD) 和市場需求 (MRD) 轉化為具體的產品需求，解答「這款產品是什麼？」以及「該怎麼實現？」並且提供詳細的功能描述、技術規範和驗收標準。

PRD 作為產品經理、設計師、工程師和測試人員之間的溝通工具，確保所有團隊對產品的理解一致，從概念落地到實際開發，並在變更發生時提供調整依據。

此外，PRD 也是產品驗收的參考標準，確保交付的產品符合既定的品質與目標，並且在敏捷開發模式下，PRD 還能幫助團隊進行持續迭代，確保產品的需求與市場變化保持一致，是一份貫穿產品開發全流程的關鍵文件。

PRD、MRD 與 BRD 到底誰要寫？

我從沒寫過 MRD與 BRD，難道我寫的文件還不夠多嗎？連這個也要產品經理來寫？其實也不是的，一間有制度的公司通常會有不同的職能分工，不過，這件事情沒有絕對的標準答案，要看公司的規模、組織架構還有產品開發流程等等。

以下是大多數公司的分工情況，提供一個參考方向：

PRD（產品需求文件）

主要負責人：產品經理 (Product Manager)
PRD 通常是產品經理的主要工作，因為他們需要清楚了解產品的功能、特性和使用者需求，並將這些資訊整理成規格說明，確保每個人都能理解。

其他可能參與的人員：
產品設計師 (Product Designer)：有些公司會讓設計師參與撰寫 PRD，特別是涉及使用者介面 (UI) 和使用者體驗 (UX) 的部分，他們的專業能讓文件更完善。
開發團隊 (Development Team)：開發團隊通常不負責撰寫，但會參與審核 PRD，確認需求清楚且技術上可行，並給出實現建議。

MRD（市場需求文件）

主要負責人：市場研究員 (Market Researcher) 或 行銷經理 (Marketing Manager)
MRD 的內容以市場需求為核心，通常由市場研究員或行銷經理負責。他們需要調查市場趨勢、分析競爭對手、了解用戶需求，並將這些資訊整合進文件。

其他可能參與的人員：
產品經理 (Product Manager)：在產品定位和目標用戶決策上，產品經理可能會協助完善 MRD 的部分內容。
行銷團隊 (Marketing Team)：行銷團隊會檢視 MRD，確保市場需求與實際的行銷計劃能對得上，進而制定推廣策略。

BRD（商業需求文件）

主要負責人：商業分析師 (Business Analyst)
BRD 是從商業角度出發，描述公司的目標和產品如何實現這些目標，通常由商業分析師負責撰寫。他們需要分析公司資源、流程以及商業模式，並提出建議。

其他可能參與的人員：
老闆或高層主管 (Senior Management)：高層主管可能參與制定公司策略，並提供關於商業目標的方向性意見。
產品經理 (Product Manager)：產品經理需要參考 BRD，確保產品需求與公司的商業策略保持一致。

需要注意的情況

在小公司裡，可能所有文件都由同一個人或同一個小團隊完成，例如產品經理身兼多職，負責撰寫 PRD、MRD 和 BRD。

所以，某些公司會將 MRD 和 PRD 合併成一份文件，因為市場需求與產品需求在流程中緊密相連。

結論：沒有所謂標準答案，因地制宜最重要！

無論是 PRD、MRD 還是 BRD，誰來撰寫主要取決於公司的情況。最重要的是，這些文件要能清楚描述產品需求、市場需求和商業目標，確保每個人都能理解，進而打造出符合市場與用戶需求的優秀產品！

但再次強調，我待過的公司，從沒有需要讓產品經理寫過 MRD 還是 BRD。

文件類型	主要負責人	輔助角色	核心內容
PRD	產品經理 (Product Manager)	產品設計師 (Product Designer)、開發團隊 (Development Team)、測試人員 (QA)	定義產品功能、使用者體驗、技術需求、驗收標準，確保團隊對產品需求的理解一致。
MRD	市場研究員 (Market Researcher) 或行銷經理 (Marketing Manager)	產品經理 (Product Manager)、行銷團隊 (Marketing Team)	分析市場趨勢、用戶需求、競爭對手，確定目標市場與產品定位，提供市場需求參考。
BRD	商業分析師 (Business Analyst)	高層主管 (Senior Management)、產品經理 (Product Manager)	從商業角度描述公司目標、產品策略、資源需求，確保產品開發與公司長期目標一致。

PRD 與敏捷開發

這題問我就對了，我可是經歷了 Scrum 三天開發、一天測試、一天上線，六日看數據長達兩年的 PO 呢！可以參考我的 Scrum 相關文章。

我認為，將 PRD 調整為適合敏捷方法的工具，需要將傳統的詳細件文件轉化為靈活、輕量化且能快速迭代的形式，以適應敏捷開發的核心理念。以下是具體方法：

拆分大而全的文件，而是聚焦「當前需求」

傳統的 PRD 通常是一份完整的詳細規範，適合瀑布式開發，但在敏捷環境下，需求可能會頻繁變更。所以，要將 PRD 拆分為每個 Sprint 的目標需求，僅記錄當前需要開發的功能細節，以 User Story 替代冗長的功能描述，專注於最小可行產品（MVP）的實現。

例如：

• 傳統 PRD：「需要開發一個支援用戶下單、付款、查看訂單的購物車功能。」
• 跑 Scrum 的方式：「作為一個用戶，我希望能將商品加入購物車，並能修改數量，以便完成購買。」

轉向模組化結構，支援可隨時更新

傳統的 PRD 常為線性結構，不適合快速變更，所以，把 PRD 按功能模組劃分（例如：用戶管理、訂單系統、支付系統），便於增量開發，並且要利用共享和協作的工具（如 Axure ），確保文件即時溝通與同步。

例如：

• 建立模組化：
  • 用戶註冊與登入
  • 商品展示
  • 購物車功能

利用視覺化工具，加速團隊溝通

敏捷強調團隊快速理解和行動，繁瑣的文字可能降低效率。可以利用的方式有：流程圖、顧客旅程地圖、Wireframe 等視覺化表達工具，替代純文字描述。

利用敏捷開發工具，實現文件與任務同步

傳統 PRD 是「靜態」文件，而敏捷要求「動態」更新與透明化管理，因此，要善用工具整合 PRD 與開發任務（例如：JIRA），利用可追蹤的任務卡片，讓開發進度與需求一一對應 PRD。

例如：

在 JIRA中建立需求時，原本 User Story 是「作為用戶，我希望能夠重設密碼，以便在忘記密碼時仍能登入。」，而 JIRA 單上則寫著「開發重設密碼的電子郵件驗證功能。」。

定義靈活的驗收標準，適應變更

傳統 PRD 驗收標準通常過於固定，無法快速適應需求變化，所以，定義可量化的驗收標準，並允許根據 Sprint 結果進行調整，也就是驗收標準應關注「當前目標是否完成」而非完成所有功能。

例如：

• 傳統驗收標準是：「購物車功能須完成所有支付方式的支援。」
• Scrum 驗收標準：「購物車須支援基本支付方式，未完成的部分可以下一迭代進行開發。」

總結：敏捷化 PRD 的關鍵

1. 拆分需求，關注當前 Sprint：以User Story 記錄當前開發需求。
2. 模組化結構，支援快速更新：將 PRD 按功能模組管理，便於增量開發。
3. 視覺化表達，提升理解效率：使用圖示和工具替代冗長文字描述。
4. 善用敏捷工具，動態同步：將 PRD 與任務工具整合，提高透明度和追蹤性。
5. 靈活驗收，擁抱改變：定義動態驗收標準，保持迭代靈活性。

PRD 與 User Story、Product Backlog 的關係。

在產品開發過程中，PRD 、 User Story 和 Product Backlog 是密切相關的工具，分別扮演不同的角色，但相互補充，共同推動開發流程。

PRD 是「全面規劃」，用戶故事和產品待辦事項是「執行工具」

PRD 是高層次的文件，詳細描述產品的整體目標、功能規範、需求清單等。它涵蓋產品的全局需求，為產品的 「長期目標」 提供指導。

User Story 是從 PRD 中提取出的具體需求單位，以用戶視角描述特定場景下的功能需求，它是 PRD 的細化與分解，便於開發團隊理解與執行。

Product Backlog 是 User Story 和開發任務的集合，按優先級排序，作為每個 Sprint 的執行清單，它動態反映當前的開發狀態，是 PRD 和 User Story 的實際任務單。

PRD 與 User Story：宏觀到微觀的連接

PRD 定義了產品的核心功能和目標，User Story 則從用戶角度將這些功能轉化為具體的操作需求，例如：

• PRD 描述（宏觀）：
  功能名稱：購物車功能
  功能描述：用戶可以將商品加入購物車，修改數量並進行結算。
  技術需求：支援 100,000 筆訂單的並發處理。
• User Story （微觀）：
  作為一個用戶，我希望能將商品加入購物車，以便稍後結算。
  作為一個用戶，我希望可以修改購物車內商品的數量，以便靈活控制購買數量。
  作為一個用戶，我希望能看到結算總金額，以便確認付款金額。

User Story 與 Product Backlog：從需求到執行的橋樑

User Story 被加入 Product Backlog，作為待完成的工作項目，在敏捷開發中，待辦事項會被按優先級排序，並分配到每個 Sprint 進行開發，例如：

• User Story （需求）：
  作為用戶，我希望能看到商品的庫存數量，避免下單失敗。
• Product Backlog（執行）：
  開發「商品庫存查詢 API」。
  設計「庫存餘量顯示」的界面。
  測試「庫存查詢的邏輯和界面正確性」。

PRD 與 Product Backlog 的映射關係

PRD 是產品的全面性規劃，而 Product Backlog 是實現 PRD 的步驟清單，待辦事項的優先級通常由 PRD 定義的目標和需求優先級決定。

流程：

1. 從 PRD 提取需求：PRD 定義產品的整體需求與功能清單。
2. 轉化為 User Story：根據需求拆解出「具體」的 User Story。
3. 加入Product Backlog： User Story 進一步分解成技術任務和執行步驟，並加入Product Backlog。

三者的角色定位與相互關係

工具	角色定位	關係
PRD	全面規劃產品的目標、功能、技術需求，為產品的「藍圖」。	用戶故事從 PRD 提取具體需求，Product Backlog 負責執行 PRD 細化後的目標。
User Story	從用戶的角度拆解需求，聚焦於具體功能和用戶價值。例如：「作為用戶，我希望能修改購物車數量。」	連接 PRD 的高層規劃，並轉化為Product Backlog 的執行步驟，為開發提供具體指引。
Product Backlog	優先級排序的執行計劃，將 User Story 轉化為可落地的開發任務。例如：「實現修改購物車數量的功能。」	具體執行 User Story，逐步完成 PRD 的目標，確保產品的實現符合需求。

PRD 常見問題與解答

要深入了解產品經理的核心技能，請參考我們的詳細指南：產品經理的核心技能