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.

Go deeper — the canonical method. This page explains how to run Analysis inside Dybs.it. For the BMad Method itself in depth — every technique, option, and the reasoning behind them — the source of truth is the official docs: Analysis phase → docs.bmad-method.org.

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 Method slash command you launch in Dybs.it'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. The method 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. The method 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 or two tight pages that hold the concept's DNA — the problem and who feels it, the solution and its honest differentiator, who it serves, the success criteria, the scope, and the vision. It's a boundary document, not a feature list, so the goal is clarity, not length. A PRFAQ covers the same ground through the press-release-and-FAQ lens instead.

For the full anatomy of a brief — every section, when to merge or add them, and the reasoning behind each — see the canonical Analysis phase docs.

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 Dybs.it

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

Open the embedded terminal. Dybs.it'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).