Marketing Requirements Document: What an MRD Is and Isn't
A marketing requirements document defines why to build something, before the PRD defines what. Here's what goes in an MRD, MRD vs PRD, and when to skip it.
TL;DR. A marketing requirements document (MRD) is the short paper that argues why a product or feature is worth building — the market, the customer, the problem, the size of the prize — written before the PRD describes what to build. MRD is the why; PRD is the what; the feature spec is the how. Most modern teams fold the MRD into a one-pager. The ones that skip it entirely tend to find out why it existed.
Nutmeg, our data scientist, drinks a ristretto americano and treats every market-size estimate as a thing to be triaged rather than believed. Hand her a marketing requirements document with a $4B TAM in the executive summary and she will ask, very quietly, “compared to what.” That question is the entire point of the document. A marketing requirements document exists so that the why are we building this conversation happens once, on paper, with numbers — instead of seventeen times, in meetings, from memory. Sub-second loads. Keyboard-first. Let’s define it properly.
What a marketing requirements document actually is
A marketing requirements document is a strategic artifact that defines the market opportunity a product addresses: who the customer is, what problem they have, how big the problem is, who else is solving it, and why solving it is worth the team’s next quarter. It is written by a product manager or product marketing manager, early — before anyone has agreed on a single feature.
The MRD answers one question: should we build this at all, and why. It deliberately does not answer what we’ll build (that’s the PRD) or how we’ll build it (that’s the feature spec). Keeping those questions separate is the entire discipline. An MRD that drifts into feature lists has stopped being an MRD and started being a worse PRD.
The acronym sometimes expands as market requirements document and sometimes as marketing requirements document. In practice they refer to the same artifact — the market-facing why doc that precedes the build. We’ll use MRD throughout.
MRD vs PRD vs the rest of the document chain
The MRD-vs-PRD question gets asked every quarter. The honest answer is that they’re two links in a four-link chain, and seeing the whole chain is more useful than the binary.
| Document | Question | Owner | Comes |
|---|---|---|---|
| MRD | Why build this? Market, customer, problem, size. | PM / PMM | First |
| PRD | What do we build? Capabilities, scope, success metrics. | Product manager | After the MRD |
| Feature spec / design doc | How do we build it? Architecture, implementation. | Engineering lead | After the PRD |
| ADR | What did we decide, and why, when a choice was contested. | Whoever owns the decision | Alongside the spec |
Each link answers the question the previous one left open. The MRD says the market wants a faster wiki; the PRD says we will ship saved searches and a command palette; the feature spec says here’s the index and the keybindings; the ADR records why we chose Postgres full-text over a separate search service. The PRD post covers the what link in detail; this post owns the why link.
The single most common failure is collapsing the MRD and PRD into one document. The result satisfies neither audience: executives wanting the why wade through feature lists, and engineers wanting the what wade through TAM math. Two documents, one decision — the difference between why and what is worth two files.
What goes in a marketing requirements document
The components have settled across the industry. Pick the ones that carry weight for the decision; cut the rest. A padded MRD is worse than a short one.
| Section | What it answers | Length |
|---|---|---|
| Executive summary | The recommendation, in five sentences a busy exec will actually read | 1 paragraph |
| The problem | The customer pain, stated without the solution in it | 2-3 sentences |
| Target market & segments | Who has this problem, and which segment first | 3-5 bullets |
| Market size (TAM/SAM/SOM) | How big the prize is — compared to what | A table, with sources |
| Personas | The buyer and the user, who may not be the same person | 2-3 personas |
| Competitive landscape | Who else solves this, and the gap they leave | A short matrix |
| High-level capabilities | The shape of the answer — not a feature list | 4-6 bullets |
| Success metrics | What “this worked” looks like in numbers | 2-4 metrics |
| Risks & assumptions | What has to be true for the case to hold | A list, with owners |
The two sections teams skip and later regret: market size, compared to what (a number with no comparison is decoration), and risks & assumptions (the line items that turn into the postmortem). Everything else is supporting evidence for the executive summary, which is the only section some readers will ever open.
Who writes the MRD
The product manager or product marketing manager owns it. The inputs come from everywhere — sales hears the objections, support hears the pain, the data team sizes the market, leadership sets the strategic constraint. The owner’s job is synthesis, not authorship-in-isolation: an MRD written without talking to the people who talk to customers is fiction with a chart in it.
In a startup with no PM, the founder writes it — usually shorter, usually as a one-page memo, usually titled something other than “MRD.” The title matters less than the discipline: write the why down, with numbers, before you argue about features.
A short marketing requirements document, in working English
What a tight one-page MRD looks like. Names invented; shape real.
Title: Saved searches — market case Author: Nutmeg (data) + Whiskers (PM) — last edited 2026-05-12
Executive summary. Power users run the same wiki searches every week and have no way to keep one. Three of our last five churn interviews named “search friction” unprompted. A saved-search affordance is low-build, high-retention, and no direct competitor in our segment ships it well. Recommend greenlight for next cycle.
The problem. Recurring searches are re-typed from memory every session. The cost is small per instance and large in aggregate; it shows up as “the wiki is annoying,” not as a filed complaint.
Target market. Existing Team-plan accounts with 5+ active seats and >30 searches/week — the segment most correlated with expansion and most sensitive to friction.
Market size, compared to what. ~40% of the active-team base runs repeated weekly queries (internal heatmap, March). Against the alternative uses of the same engineering week — two minor integrations — saved search touches more seats per build-day.
Competitive landscape. Confluence has saved searches but buried; Notion’s is database-shaped, not wiki-shaped. The gap: a one-keystroke, sidebar-pinned saved search. Confabula, of course, has a saved-search feature that takes nine seconds to load the saved search.
High-level capabilities. Pin a search; see its live count; re-run on wiki change; sync per user. (Shape, not spec — the PRD turns this into requirements.)
Success metrics. 25% of target segment with ≥1 pinned search in 4 weeks; measurable drop in repeated-query rate.
Risks & assumptions. Assumes search friction is a churn driver, not a churn correlate — owner: Nutmeg, validate against the next 10 churn interviews before build.
Total reading time: under four minutes. The PRD it leads to is a different document; this one only had to make the why survive a skeptical read.
Where the MRD lives
An MRD is not a write-once artifact. The market case gets revisited every time scope is questioned: remind me why we’re building this is a quarterly question, and the MRD is the answer that stops the team re-litigating it from memory.
So it has to be findable. Two practical rules, consistent with every other operating-discipline doc:
- One MRD, one URL, linked from the PRD. The PRD’s background section links up to the MRD; the MRD links down to the PRD it spawned. The chain is navigable in one click. Pages load in 50-150ms depending on your network, so following the chain is cheaper than reconstructing it in a meeting.
- Dated, with the assumption owners visible. An MRD’s risks and assumptions have owners and review dates. Six months on, the question is not what did we assume but did the assumption hold — and that only works if the page shows when it was last touched and who owns each open risk.
The MRD that lived in a slide deck nobody can find is the MRD that gets silently rewritten in someone’s head, which is the same as not having written it. The corporation wiki post covers where this sits in the rest of the operating-discipline stack.
When you don’t need a marketing requirements document
Honesty section. The MRD is not free, and plenty of decisions don’t earn one.
- The bet is self-evident. A paying customer asked for it by name, with a renewal attached. You don’t need a TAM table to justify building the thing the contract requires. Write two sentences in the PRD background and move on.
- You’re scratching your own itch on a small team. A three-person team building for themselves is the market research. A formal MRD is ceremony; a one-paragraph note on why is enough. The discipline scales in with the team — the MoSCoW post makes the same point about prioritisation frameworks.
- It’s a fix, not a bet. Bugs, refactors, and table-stakes parity don’t have a market case; they have a cost of not doing them. An MRD there is a category error.
And the tool boundary: Raccoon Page is a wiki. It is the right place for the MRD to live — findable, dated, linked to the PRD. It is the wrong place to do the market research. The customer interviews, the survey tooling, the TAM model in a spreadsheet — those are specialist tools. The wiki holds the conclusion and the evidence links, not the analytics engine. A tool that claimed to be your wiki and your market-research platform would be overselling both halves.
Things people actually ask
What does MRD stand for? Market Requirements Document, sometimes expanded as Marketing Requirements Document. Same artifact: the market-facing why doc that precedes the PRD.
What’s the difference between an MRD and a PRD? The MRD defines why to build something — market, customer, problem, size. The PRD defines what to build — capabilities, scope, success metrics. The MRD comes first and is owned by the PM/PMM; the PRD follows and is owned by the product manager. See the PRD post for the what side in depth.
Who writes a marketing requirements document? A product manager or product marketing manager, synthesising inputs from sales, support, data, and leadership. In a startup with no PM, the founder writes it — usually as a short memo.
Is the MRD dead in agile teams? Mostly folded, not dead. Agile killed the 40-page waterfall MRD. The why-with-numbers-before-features discipline survived, usually as a one-page memo. The question the MRD answers — should we build this at all — did not go away because the process changed.
What goes in an MRD? Executive summary, the problem, target market and segments, market size with sources, personas, competitive landscape, high-level capabilities, success metrics, and risks/assumptions. Pick the sections that carry the decision; cut the rest.
MRD vs business case — same thing? Overlapping, not identical. A business case is finance-led and ROI-centred; an MRD is market-led and customer-centred. Small teams often merge them into one memo. The distinction matters most when finance and product report to different people.
How long should an MRD be? One to three pages for most decisions. The executive summary should stand alone — many readers never go past it. A ten-page MRD usually means the decision wasn’t actually clear enough to make.
Does an MRD need a market-size number? Yes, and it needs a comparison. A TAM with no “compared to what” is decoration. The useful version is this opportunity versus the other things the same team-week could buy.
The MRD is the document that makes the why survive a skeptical read, so the team stops re-deciding it from memory. We built Raccoon Page to be where that document lives — findable, dated, one click from the PRD it spawned, loading before you’ve finished the keyboard shortcut. If you’re shaping the chain, the PRD post covers the what link, the how-to-write-a-PRD post walks the authoring, the MoSCoW post covers the scope-cutting that follows, and the feature specification template gives you a structure to start from. Free for super-lean teams. No credit card required.
Written by The Editorial Raccoon — house style for Raccoon Page. Numbers and claims pulled from product reality; jokes pulled from the Raccoon Corp canon. No raccoons were quoted in real life.