PRD vs BRD vs MRD vs SRD: which document you actually need

The alphabet soup of requirements documents confuses more than it clarifies. Here's the honest map, from broadest to most specific.

MRD — Market Requirements Document

The market need. Who the customers are, the problem in the market, the opportunity size, the competitive landscape. It answers "is there a market here, and what does it want?" Written early, often by product or product marketing.

BRD — Business Requirements Document

The business goals. What the organization wants to achieve and the high-level requirements to get there — revenue targets, strategic fit, success criteria from the company's point of view. It answers "what does the business need from this?"

PRD — Product Requirements Document

What to build. Translates the market and business needs into product functionality: problem, users, requirements, metrics, scope. It answers "what should this product do, for whom, and how will we know it worked?" This is the PM's central document.

SRD — Software Requirements Document

The technical how. Functional and non-functional specifications, architecture-level detail, the engineering view. It answers "how will we build what the PRD describes?" This is what Cadenly calls a spec.

Which do you actually need?

The hierarchy is market → business → product → software, broad to specific. But you rarely write all four. In most modern software teams, the MRD and BRD context folds into the front of the PRD (problem, market, business goals as sections), and you write two real documents: a PRD (the what) and a spec (the how). The four-document stack still appears in regulated enterprise and agency settings where legal, compliance, or client contracts need each layer separated.

The mistake is writing documents out of ceremony. Write the ones your decisions require: if no one will read a standalone BRD, put the business goals in the PRD and move on.