In one line: The business-side description of what the market needs and why. It is the document engineering’s specifications must answer to.
Core idea
Before engineers write specifications, someone has to state the market case. A Market (or Marketing) Requirements Document captures the opportunity in business terms: who the customers are, what problem they have, what they need the product to do, how it will compete, and what success would look like. Some organizations call it a customer requirements document or product proposal. The engineering response is the specification (see Product Specifications), which turns these requirements into metrics and values.
How it works
A typical MRD covers:
- Market problem and opportunity: the need, its size, and why now.
- Target customers and users: segments, personas, buying process.
- Requirements: what the product must do, phrased as needs and use cases, ranked by priority (must-have, should-have, nice-to-have).
- Competitive landscape: alternatives and positioning.
- Business goals and constraints: pricing, timing, channels, regulatory needs.
- Success measures: how the business will judge the outcome.
Modern software practice often replaces the long MRD with lighter forms, such as product briefs, user stories and backlogs, kept up to date as the team learns. The content is the same, but the document lives and changes.
In practice
Engineers rarely write the MRD but are always affected by it. Reading your organization’s version (or a public example) shows what the business actually promised, and where requirements are vague enough to cause later arguments. A good habit is to trace each top-level specification back to an MRD requirement. Specifications with no traceable requirement are candidates for removal; requirements with no specification are risks.
Questions to ask yourself
- Does my project have an MRD (or equivalent), and have I read it?
- Which requirement is too vague to test?
- Are the priorities in the MRD the ones the engineering team is actually working to?
Connections
- The engineering answer: Product Specifications. The research behind it: Identifying Customer Needs.
- Its one-page cousin: Product Mission Statement. Software practice: Software in Engineered Products.
- Capabilities exercised: Communicating and Advocacy, Connecting Across Disciplines, Vision.
Sources
- Course reading: an example marketing requirements document from a university software product-marketing course.
- Ulrich and Eppinger - Product Design and Development [1]