定義
Market Requirements Document，簡稱市場需求文檔。市場需求文檔的主要功能是描述什麼樣的功能和特點的產品（包含產品版本）可以在市場上取得成功。產品進入實施，需要先出MRD，具體來說要有更細緻的市場與競爭對手分析，通過哪些功能來實現商業目的，功能/非功能需求分哪幾塊，功能的優先權等等。實際工作中，這個階段PD可能的產出物有Mind Manager的思維圖，Excel的Feature List等。
產品市場經理（PMM，Product Marketing Manager）負責分析市場變化，通過對市場的分析，MRD指出什麼樣的新產品、方案和服務可以更好的開拓市場。
延伸
通常情況下，產品經理或者技術產品經理會將在MRD的基礎上完成PRD（Product Requirements Document），技術團隊套用PRD開發產品。技巧
從用戶角度的編寫
從用戶角度編寫需求內容。使用“用例(Use Case)”和“用戶角色（User Personas）”來達到這個。考慮用以下兩種方法來詳細說明你們公司正在開發的SFA（sales force automation）軟體的“Login”的功能性。方法A：
用戶通過一個要求用戶提供證書的登入界面，然後軟體允許用戶帶著特定的許可權進入系統。軟體鑑別這些證書，在鑑定通過的基礎上允許用戶訪問那些他們有許可權訪問軟體的功能部件。
方法B：
Mike是一個銷售經理，Cathy是一個銷售代表。當他們打開軟體，他們看到登入界面。他們通過用戶名和密碼進入系統。如果用戶名和密碼是正確的，他們能登進系統。一旦登入進系統，Mike能訪問軟體所有的功能部件。Cathy只能訪問那些對銷售代表有有效的功能部件。
哪個方法更加容易閱讀和理解?就我的看法,毫無疑問，”方法B”。還有，它同時減少了令人煩惱的閱讀！\”\”
使用Screen Shot
使用Screen Shots或者mockup來你的想法。我們中很多人都聽說過“一張圖片好比一千個文字”。當提到寫MRD的時候，一個screen shot好比一千個文字！舉個例子,看看下面這個screen shot，你需要多少字來描述？我想可能不只一千個字。
用簡單的語言編寫
在我超過11年的行業中，我通常注意到的（更多是令我懊惱）一件事是用很做作的語言來寫的MRD。我想這個主要是因為MRD聽起來是正式的和專業的原因吧。相反，想像你寫的MRD是寫給你的在工程師團隊工作的朋友。你的目標是幫助他理解你需要什麼，以便於他能開發產品實現這些需要。這個將有助於你避開陷入那些令讀者人厭煩（有時他們會把MRD撕碎然後再碎片餵給碎紙機）的用做作的語言的陷阱。
還有：
a)保持簡短的語句，把長的語句分解成多個小的語句。
b)避免大篇幅的連續文本，把他們分解成多個小的章節。
c)把大塊文本內容分解成，screen shots，表格、重點列表等等。
小心的使用模板
我發現MRD模板非常有用。他們的幾個好處包括：a) 模板提供了一個標準的格式，使那些不得不閱讀大量MRD的讀者更加容易閱讀。
b) 模板讓新的產品經理快速的寫MRD變得容易，因為公司與公司之間的MRD內容是不同的。
c) 模板確保你不會忘記所有需要在MRD中覆蓋描述的部分；
然而，一些公司過分的使用模板。一個矽谷最大的公司之一有一個所有部分被強制使用的近60頁的模板。我覺得這個讓人覺得非常難以忍受並且有幾個負面的作用：
a) 產品經理害怕但又不得不寫MRD – 幾乎和不得不和Dick Cheney去南德克薩斯打獵一樣（譯者按：美國副總統Dick Cheney在南德克薩斯打獵時意外的打傷了和自己一起去的打獵夥伴）。
b) 工程師團隊害怕但又不得不閱讀MRD。
c) 寫MRD和讀MRD都需要花大量的時間。
我推薦你使用MRD模板，但確保他們不要過分的長。還有如果需要，確信產品經理可以靈活的跳過模板某些部分和創建新的內容。
區分需求的優先權
在這些年裡，我從來沒有碰到一個工程師團隊實現了MRD里包括的所有特性的沒有刪減的項目-通常由於那些我們控制之外因素！這就是說作為MRD作者的產品經理，當出現需要決定取捨的時候，應該提供一個辦幫助讓他們決定那些特性要實現那些可以推遲。
區分需求的優先權是一個最好的能幫助完成這個事情的辦法。我發現把需求分等級就像P1，P2，P3…這樣工作的剛剛好。在這個分類中-P1是最高優先權，P2是第二高優先權等等。
最好的決定一個已經明確的需求的優先權方法這個需求實現後的好處-包括你的客戶和你的公司。在實際實踐中，最好是和其他多種因素一起綜合決定。
我推薦你只要包括P1，P2，P3的需求在你的MRD中，在多數的項目中更低的優先權可能未必會實現。還有這樣也讓MRD變得更加容易讀。
說明”是什麼”和”為什麼”
產品經理為理解客戶的需求負責，然後基於這些理解定義什麼和為什麼需要開發.有一件比任何事情讓開發者發瘋就像在幾英里外都能聽到的汽笛在他們耳邊尖叫一樣的是一個令人痛苦的詳細描述了怎樣實現每一個需求細節的MRD。
考慮你們公司正在開發的以下兩種描述CRM“Login”功能的方法。
推薦-描述“是什麼”
Mike是一個銷售經理，當他打開我們的CRM軟體，他會看到一個登入界面…登入界面建議提供“記住我”複選框。如果Mike在點擊登入按鈕之前選擇了該複選框，我們的軟體將記住並且在他下次來到登入界面時自動填寫他的名字。
不推薦-描述“怎么樣”
Mike是一個銷售經理，當他打開我們的CRM軟體，他會看到一個登入界面…登入界面建議提供“記住我”複選框。如果Mike在點擊登入按鈕之前選擇了該複選框-將通過Javascript 保存他的名字以cookie的方式寫到他的硬碟。當cookie寫到硬碟後，用戶名和密碼將被傳送到伺服器。下一次Mike來到登入界面時，Javascript 將讀取他的cookie，成功讀取後，Javascript 將是適當的DOM命令填充登入頁面上的用戶名。好的產品經理擅長理解用戶的需求和描述什麼需要實現，好的工程師擅長決定怎么樣實現它。好的工程師希望能自由的決定怎么樣最好的實現用戶希望得到的東西。
我注意到有技術背景的產品經理尤其喜歡描述“如何實現”。如果這些描述的就是你，應該從現在開始不要再做這樣的事了。工程師們將會感謝你。
附：這裡有一些例外的情況-當在描述“是什麼”中描述“怎么樣”是必要的，當描述“是什麼”的最好的方式和/或唯一的方式就是描述“怎么樣”的情況。
覆蓋非功能性需求
儘管功能性需求描述產品的功能，非功能性需求描述系統特性，如：a)性能
b)可伸縮性
c)可用性
d)國際化
e)等等…
我注意到因為許多產品經理和產品市場人員認為這些是“技術細節”，而在MRD中被忽略。我發現這些是我的MRD中非常重要的一部分，工程師們會非常感激在MRD中定義這些需求。
要點：當寫非功能性需求的時候，儘可能的是使他們可度量（可測試）。否則，QA不能測試它們，你將沒有辦法知道完成的產品是否已經實現了這些非功能性需求。
評審&修正
我有一個朋友-我們叫他Matt（他的真名叫Steve）。Matt在矽谷一家成功的公司做產品經理工作。最近我在午餐的時候碰到他是告訴我一個非常有趣的故事。他們雇用了一個有三年經驗的產品經理。在他被雇用的幾個月里，不知何故他讓他的產品經理同事和工程師一樣疏遠他。
他是罪犯？他基本上認為他的MRD就像一個法令。他寫了它，但不想和任何人評審或在反饋的基礎上修改它。他僅僅想工程師團隊沒有問任何問題的拿著它並實現它們！
不要像Matt的同事那樣。確信做到和你的產品經理夥伴和工程師團隊評審你的MRD。保持一個敞開的思想然後在評審反饋的基礎上更新MRD。這將幫助你寫出更好的MRD，工程師將喜歡你（或者至少少恨你一些），你的團隊也將創造更好的產品。
定義市場目標和定位
大部分我看到過MRD在覆蓋了市場目標（誰將買和使用戶你的產品）和定位（與競爭對手的產品比你的產品定位怎么樣的）的方面做的很好。我還看到過一些沒有描述市場目標和定位的MRD，他們通常會這樣爭辯：“為什麼工程師們需要知道這些？拿到定義了什麼是需要的還不夠嗎？”
這些問題（誰將買和使用戶你的產品和與競爭對手的產品比你的產品定位怎么樣的）的確有一些正面價值，我發現許多工程師想知道為什麼一個產品或特性要開發，誰將使用他們，什麼是他們可以另外選擇辦法。
這些信息幫助他們和產品組的其他成員想像最終用戶並從而更好的為創造成功的產品工作。我的建議的儘可能的（在MRD中）包含這些信息。- 它們不一定要很詳細，只要包含幾個段落就足夠了。
包含一個術語表
如果你的MRD使用了新術語或在非通用的地方是使用了常用術語-確保在MRD後面包含一個術語表。當你像這樣說“我們的軟體將提供SME用戶通過選擇WAP或PSMS開MRC帳單”時，術語表將確保你的所有讀者（有些可能不是技術人員）理解你的意思是什麼。
規範
作為產品經理，市場需求文檔和產品需求文檔肯定是寫過不少。市場需求文檔關鍵點是建立在對某個產品或行業領域熟悉的情況下，有一定數據調研基礎上進行撰寫的。主要做市場需求分析，和簡單描述產品功能與用戶需求的切合點，整個文檔需要表達的是：你看到了市場，看到了用戶需求，告訴上司做一個具備XX功能的產品能切入到市場並且前景廣大。1、文檔介紹
1.1 文檔目的
1.2 內容概要
2、市場問題和機會
2.1 本章摘要
2.2 市場問題
2.3 市場機會
2.4 產品問題和機會
2.5 技術問題和機會
3、市場概述
3.1 本章摘要
3.2 目標市場描述
3.2.1 目標市場特徵
3.2.2 目標市場趨勢
3.2.3 目標市場區隔
3.2.4 目標市場時間約束
4、客戶和購買者
4.1 本章摘要
4.2 目標客戶描述
4.2.1 目標客戶細分
4.2.2 客戶動機
4.2.3 影響因素
4.2.4 客戶目標
4.3 目標購買者描述
4.3.1 業務決策購買者
4.3.2 技術決策購買者
5、使用者和用戶原型
5.1 本章摘要
5.2 原型特徵
5.3 現實需要
5.4 原型聯繫
6、市場需求
6.1 本章摘要
6.2 功能分類
6.3開發環境說明
6.4兼容性說明
6.5性能說明
6.6國際性說明
6.7文檔說明
6.8外觀說明
6.9發布說明
6.10支持和培訓說明
6.11其它說明
6.12 方案概述
6.13 技術概述
6.14 市場需求概要表
7、支持信息
7.1 本章摘要
7.2 文檔假設
7.3 參考資料
7.4 產品體系
