Phase 1 — Analysis: Understand the Problem

Here is the whole treasure map in one sentence: before you decide what to build, you understand the problem you're building against. Analysis is the first of the BMAD method's four phases, and it exists to buy you the cheapest thing in software — a changed mind before any code is written.

I'm Mary, your Business Analyst. My job in the hybrid team is to keep us honest at the very start: to dig until the real problem, the real market, and the real constraints are on the table, and to hand the Planning phase a concept that's already survived scrutiny. Skip this dig and you don't save time — you just move the excavation to production, where it's a hundred times more expensive.

The mindset: Fall in love with the problem, not the solution. Analysis is evidence-gathering, not decision-making. You leave this phase knowing why a thing is worth building — the what and the how come later.

Where Analysis sits in the method

Analysis (1-analysis) is the front of the workflow. It feeds the Planning phase, which turns your validated concept into a PRD.

You don't have to run every box. A brownfield tweak might jump straight to a brief; a bet-the-company idea deserves the full expedition. The tools are a toolkit, not a turnstile.

The sub-workflows

Analysis breaks into two movements: explore (brainstorm and research to widen your understanding) and crystallize (pin the concept down in a durable artifact). Each is a BMAD slash command you launch in BMAD Board's embedded terminal.

Explore — ideate, then gather evidence

/bmad-brainstorming — Start here when the idea is still a hunch. This is expert-guided facilitation through one or many creative techniques: it pushes you past the first obvious answer and surfaces options you'd never have reached alone. Output: a brainstorming session captured in planning-artifacts/.

Then, where an assumption is load-bearing, spend a little evidence on it. BMAD gives you three research lenses — pick the ones that de-risk your idea:

Command	Lens	Answers the question	Reach for it when…
`/bmad-market-research`	Market	Who competes, what customers need, where the trends point	You need to know the landscape, pricing, and whether there's real demand
`/bmad-domain-research`	Domain	The industry's terminology, rules, and subject-matter depth	You're entering a field you don't yet speak the language of
`/bmad-technical-research`	Technical	Feasibility, architecture options, implementation approaches	The idea hinges on "can we even build this, and how?"

Research outputs land as research documents in planning-artifacts/ (and, for domain/technical digs, in your project-knowledge docs) — evidence you'll cite straight through Planning and Solutioning.

Tip: Research is à la carte. Run only the lenses that reduce a real unknown. A weekend utility rarely needs market research; a fintech product rarely skips domain research. Match the dig to the stakes.

Crystallize — turn understanding into a concept

Once you understand the problem, you commit it to one durable artifact. BMAD offers two paths, and choosing well matters more than most people expect.

Path	Command	Temperament	Choose when…
Product Brief	`/bmad-product-brief`	Gentler. Nails the concept down as-is.	You're already sure of the concept and nothing's going to sway you — you want it captured cleanly, fast
PRFAQ	`/bmad-prfaq`	Adversarial. Working Backwards; a gauntlet.	You want the concept stress-tested — is it feasible, do users truly need it, does it survive being written up as if it already shipped?

Both produce a concept document in planning-artifacts/, and both are valid front doors to Planning. The difference is how much resistance you want:

/bmad-product-brief is the gentler guided experience. It assumes your conviction and helps you articulate it. Best when the concept is settled and you just need it sharp and shared.
/bmad-prfaq runs the Working Backwards method: you write the press release and FAQ as if the product already launched, then defend it. It's designed to forge and pressure-test a concept — to find the fatal flaw now, while it's still free. Best when you're excited but not yet certain, or when the cost of being wrong is high.

Rule of thumb: If you'd feel relieved to have someone poke holes in the idea, run the PRFAQ. If poking holes would only slow down a decision you've genuinely already made, write the brief.

What a Product Brief captures

The Product Brief is Analysis's flagship artifact: one to two tight pages that hold the concept's DNA. It's a boundary document, not a feature list — the goal is clarity, not length. A brief typically pins down:

Executive summary — the whole vision in 2–3 paragraphs, compelling enough to stand alone.
The problem — the pain, who feels it, how they cope today, and the cost of the status quo. Specific scenarios beat abstractions.
The solution & what makes it different — what you're building and the honest differentiator. If the moat is execution speed, say so; don't fabricate a technical one. (This is also where the real risks surface — an honest differentiator names what could undo you.)
Who this serves — the primary users, vivid but brief, and what success looks like for them.
Success criteria — the goals and measurable signals that tell you it's working, blending user-success and business objectives.
Scope — what's in for v1 and what's explicitly out. Tight boundaries here are where much of the project's risk gets defused early.
Vision — where this goes in 2–3 years if it succeeds: inspiring but grounded.

The template flexes — merge, reorder, or add sections (a "Buyer vs User" split for B2B, "Compliance" for regulated fields) so the structure serves the product's story rather than the other way around. A PRFAQ covers the same ground through the press-release-and-FAQ lens instead.

The artifacts, and where they land

Everything Analysis produces is written to your project's planning artifacts, so the whole hybrid team — and every downstream phase — reads from the same source of truth:

Sub-workflow	Command	Artifact	Lands in
Brainstorming	`/bmad-brainstorming`	Brainstorming session	`_bmad-output/planning-artifacts/`
Market research	`/bmad-market-research`	Research document	`_bmad-output/planning-artifacts/`
Domain research	`/bmad-domain-research`	Research document	`_bmad-output/planning-artifacts/`
Technical research	`/bmad-technical-research`	Research document	`_bmad-output/planning-artifacts/`
Product Brief	`/bmad-product-brief`	Product brief	`_bmad-output/planning-artifacts/`
PRFAQ	`/bmad-prfaq`	PRFAQ document	`_bmad-output/planning-artifacts/`

The PRD in Planning is created from the brief, so a strong Analysis phase directly lightens every phase after it.

How to run Analysis in BMAD Board

In the visual cockpit, Analysis is a conversation you have with me — Mary — in the terminal:

Open the embedded terminal. BMAD Board's Warp-style terminal is persistent and tabbed. Type a command like /bmad-brainstorming and I'll pick up the session.
Or use the Command Palette (Cmd+K) to jump straight to any /bmad-* command without hunting for it.
Pick your coding agent. Launch these commands with whichever LLM CLI you prefer — Claude Code, Codex CLI, Gemini CLI, Cursor, Aider, Open Code, or any other terminal coding agent that supports the BMAD method.
Watch the artifacts appear in the Documents view. As each command writes to planning-artifacts/, the brief and research show up in Documents with markdown rendering — and automatic versioning, so every save is snapshotted and any edit is one click from restore.

Prerequisite: A project with a _bmad/ directory, Node.js (v18+), and at least one LLM CLI installed. See Installation to get set up.

Analysis can also be reached as a phase on a story, but its natural home is at the very front of a new project, before any epics exist.

When can I skip or shorten Analysis?

Rigor should scale with stakes. You rarely skip understanding entirely — but you can absolutely go lighter:

Brownfield projects — the problem and users are already known and the codebase already exists. Lean on /bmad-document-project and /bmad-generate-project-context to capture what's there, and go straight to a short brief. Reserve research for the genuinely new part of your change.
Small changes — a bug fix or a modest tweak doesn't need a research expedition. A few sentences of problem framing may be all the "analysis" it warrants; consider /bmad-quick-dev for tightly-scoped intent-to-code work.
The concept is already clear — if you're certain and nothing will sway you, skip brainstorming and the PRFAQ gauntlet and write a /bmad-product-brief directly.

Note: "Shorten" is not "skip." Even the smallest change deserves one honest answer to "what problem am I solving, and for whom?" That single sentence is the cheapest insurance in the whole method. When in doubt, ask /bmad-help what to run next.

Next steps

You've understood the problem. Now decide what to build:

Phase 2 — Planning — hand your brief to John, the Product Manager, who turns it into a PRD (and UX specs where there's a UI).