Planning — Phase 2 of the BMAD method

Planning is where you decide what to build.

Analysis left you with understanding — a Product Brief, some research, a clear read on the problem. Planning turns that understanding into a plan a team can actually build against. The output of this phase is a PRD (Product Requirements Document) and, when there's a user interface, a UX design to go with it.

Note: Planning is Phase 2 of four. See the method overview for how all four phases fit together, and Analysis for the phase that feeds this one.

The goal: a plan you can test

Here is the trap this phase exists to avoid: template-filling. A PRD written to satisfy a template is a document nobody trusts and nobody reads twice. The section headings are all present; the thinking is not.

Plan for the job to be done instead. Every requirement should trace back to a real user outcome. Every success metric should be something you could actually measure. The test of a good plan is not "did we fill in the template" — it's "could a developer, or a coding agent, build the right thing from this, and could we tell afterward whether it worked?"

Ask the sharp questions early:

Who is this for, and what job are they hiring the product to do?
How will we know it worked? What's the number?
What's in scope — and, harder, what's deliberately out?

A plan that answers those is testable. A plan that dodges them is decoration.

The PRD

The PRD is the source of truth for what and why. It's owned by John, the Product Manager — and it builds directly on the Analysis phase output (the Product Brief or PRFAQ carries forward into it).

You produce and maintain it with one workflow: /bmad-prd. That single command has three intents.

Intent	When to use it	What it does
Create	Starting a new PRD	A coached discovery session that interrogates the idea and writes the PRD with you, section by section.
Update	A change signal arrived	Revises an existing PRD against what changed — new information, a pivot, a cut — without starting over.
Validate	The PRD feels done	Checks the finished PRD against a checklist and returns an HTML findings report of gaps and weaknesses.

Tip: create for the first draft, update whenever reality shifts, validate before you move on to Solutioning. Validation is cheap; discovering a hole in the plan mid-build is not.

What a good PRD contains

A PRD earns its keep when it covers these — not as boxes ticked, but as decisions made:

Vision — the one-liner and the future state you're building toward.
Problem — who hurts, how, and why now. Grounded in the Analysis phase, not invented here.
Success metrics — how you'll measure whether it worked. Real numbers, real windows.
Functional requirements — what the product must do.
Non-functional requirements — how it must behave: performance, reliability, security, and the constraints that shape the build.
User journeys — the paths a real person takes through the product to get their job done.
Scope — what's in, what's out. The out-of-scope list is often the most valuable section on the page.

Prerequisite: The PRD builds on the Analysis phase. If you don't yet have a Product Brief or a clear problem statement, do Analysis first — /bmad-prd is stronger when it has something to build on.

The UX design step

Not every project has a user interface. When yours does, planning has a second beat.

Hand off to Sally, the UX Designer with /bmad-ux. Sally turns the PRD's journeys into concrete UX specifications and detailed user journeys — the design intent the build will later realize. Run it after the PRD; it reads the plan you just wrote and gives the interface a shape.

If there's no UI — a CLI, a library, a backend service — you can skip it and go straight to Solutioning.

Note: /bmad-ux is strongly recommended whenever a UI is a primary part of what you're building. Skipping it on a UI-heavy product means the interface gets designed by accident, during the build, when changing it is expensive.

The planning flow

The Planning commands at a glance

Two workflows carry this phase. Both write to _bmad-output/planning-artifacts/.

Command	Owner	Runs after	Produces
`/bmad-prd`	John, Product Manager	the Product Brief (Analysis)	the PRD
`/bmad-ux`	Sally, UX Designer	the PRD	UX specs + user journeys

The order matters: the PRD reads the Analysis output, and the UX design reads the PRD. Each step stands on the one before it. The full catalog lives in the slash-command reference.

Where the artifacts land

Everything Planning produces is written to _bmad-output/planning-artifacts/ — the PRD (prd.md) and, when you run it, the UX design. This is the same folder that will later hold the architecture and the epics, so the whole "what and why" of the project lives in one place.

In BMAD Board, you read and edit all of it in the Documents view — markdown rendered, with automatic file versioning so an overwrite is always one click from being restored.

How to run it in BMAD Board

Planning is a terminal workflow, and BMAD Board makes launching it a click:

Open your project in BMAD Board.
Launch /bmad-prd from the embedded Terminal, or from the Command Palette (Cmd+K) — and pick the coding agent you want behind it (Claude Code, Codex, Gemini, Cursor, Aider, Open Code, or any other terminal agent that supports the BMAD method).
Work through the coached discovery session. The agent asks; you answer; the PRD takes shape.
When it finishes, the PRD lands in _bmad-output/planning-artifacts/ and shows up in the Documents view, ready to read, edit, and validate.
If your project has a UI, launch /bmad-ux the same way. Sally's UX specs land alongside the PRD.

Tip: Validate before you leave the phase. Run /bmad-prd in its validate intent and skim the findings report — it's the cheapest quality gate you'll get all project.

How you'll know Planning is done

Not "the template is full." Ask yourself:

Could a coding agent build the right thing from this PRD, without you in the room to explain it?
Is every success metric something you could actually measure, with a number and a window?
Does the scope say what's out, not just what's in?
If there's a UI, do the UX specs exist — or did you consciously decide there's no UI to design?
Did you run validate, and are the findings addressed or knowingly accepted?

Five yeses, and you have a plan worth building on. Anything less, and Solutioning inherits the gaps.

Next steps

Solutioning — decide how to build it: the architecture spine, then epics and stories.

See also: Analysis (the previous phase) · The method overview · Slash-command reference