Preview — full styling will appear after the next deploy completes.

bmad-method

The One-Page PRD

Constraints force clarity

The PRD is the first artifact in every BMAD project. Its one-page constraint is not a formatting choice — it is a forcing function that prevents work from beginning until the problem is genuinely understood.

flowchart TD
    PRD[One-Page PRD]
    PRD --> P[Problem Statement<br>one or two sentences]
    PRD --> C[Constraints<br>time · cost · tech · regulation]
    PRD --> U[Target Users<br>who is affected and how]
    PRD --> S[Success Criteria<br>measurable, not directional]
    PRD --> O[Out of Scope<br>explicit exclusions]

A PRD that cannot fit on one page is a problem that hasn't been understood yet. This is the central discipline of the BMAD PRD format. Teams that resist the constraint are usually carrying hidden scope ambiguity — requirements that sound clear until you try to write them in two sentences and discover they are actually three different requirements that don't agree with each other.

A BMAD PRD has five sections: the problem statement (what is actually broken or missing, in one or two sentences), the constraints (hard limits on time, cost, technology, regulation), the target users (who is affected and how), the success criteria (measurable outcomes that define done), and the out-of-scope list (explicit exclusions that prevent scope creep). Every item must be verifiable. "Improved user experience" is not a success criterion. "Users complete onboarding without contacting support" is.

The out-of-scope list is the most overlooked section and often the most valuable. It tells the AI — and the team — what not to build. Without it, every ambiguous requirement resolves toward doing more. An explicit out-of-scope list also serves as the PM's first reference when a new story is proposed: if it's on the out-of-scope list, it becomes a new PRD, not an addition to the current one.