Phase 2 of 6

Run /visionaire:start

This is the hour that prevents the month of building the wrong thing.

Convert vague intent into a precise, validated definition. Specific problem. Real user. Measurable success. Explicit scope — before any building begins.

Start my spec session — $297
$297 early access — first 100 builders  ·  Becomes $447 after
See how it works  →
One payment. Keep it forever. Runs locally. No telemetry.
02
Product Brief
BRIEF.md
Definition before design. Clarity before code.
BRIEF.md
MARKET-analysis.md
UIUX.md
1# BRIEF.md — ScopeGuard
2
3## Problem Statement
4Design agencies lose ~15% of project revenue to scope
5creep. Client change requests aren't tied to approved
6specs — no one can say no with documentation.
7
8## Target User
9Sarah Chen · Creative Director, 12-person branding
10agency. She's the one fielding client requests at 11pm.
11
12## Success Criteria
13Out-of-scope work: 15% → under 5% of project hours
14within 90 days of adoption.
15
16## Scope
17In: change tracking, spec linking, approval flow, audit trail
18Out: project management, invoicing, time tracking
19
20✓ Problem clarity — PASS
21✓ Target user specificity — PASS
22✓ Measurable success criteria — PASS
23✓ Internal consistency — PASS
24✓ Stability for design — PASS
25→ BRIEF.md APPROVED · Market Validation ready
If you skip this phase
  • You will define the problem as the first version of it you thought of, not the real one.
  • You will write requirements around the solution you already want to build.
  • You will not discover you solved the wrong problem until someone uses it and doesn't care.

None of this is theoretical. These are the patterns that show up every time.

Skip this, and you'll build something technically correct that nobody wants.

The Product Brief is where you find out you were solving the wrong problem — before you've written a line of code. Skip it, and every downstream phase executes with conviction on a definition nobody wrote down and everyone interpreted differently.

Feature soup
Without a problem statement, every feature sounds reasonable. "Collaboration" can mean anything. Eight months and six features later, launch day: 47 signups, 3 active after a week. The product tried to serve everyone and served no one well.
"Everyone" is your target user
A 3-person studio: "doesn't fit our workflow." A 50-person agency: "we need enterprise features." A freelancer: "too complex." Abstract personas allow vague thinking. Design decisions had no anchor. Tradeoffs had no arbiter.
Success is undefined
Nine months in, your investor asks: "How do you know if this is working?" You don't have a number that means we succeeded. You can't pivot because you don't know what's failing. Every decision becomes political.
Scope creep with no tiebreaker
Four months in: "Why not add custom reports?" Two months later: "Multiple workspaces." Then SSO. Your 8-week MVP is 11 months in, still not shipped. Without explicit scope, the answer to "should we add X?" is always "well, maybe."
Assumptions built into architecture
You built real-time collaboration because remote teams obviously need it. Your target users work across timezones and find real-time notifications stressful. They wanted async. The architecture you chose now constrains every feature that follows.
Design starts before direction is settled
Your designer has built 40 screens. Then the Product Brief interview reveals the primary user isn't who everyone assumed. Design starts over. Six weeks of work, accumulated context, team morale — gone. Product Brief ambiguity is cheap to fix before design starts.

CB Insights analyzed 101 startup failures. 42% cited "no market need" — not bad execution, but building the wrong thing because the problem was never precisely defined.

From vague intent to validated clarity — before a line of design or code.

The Product Brief Phase takes what lives in your head — specific, contextual, complete — and extracts it into a written definition everyone can execute on.

Before the Brief
project management tool for teams more productive collaboration features everyone will want this better search faster somehow real-time
BRIEF.md
Problem — agencies lose 15% revenue to undocumented scope
User — Sarah Chen, 12-person branding agency
Success — 15% → under 5% out-of-scope, 90 days
In scope — change tracking, spec linking, approval flow
Out of scope — PM tools, invoicing, time tracking
Stage gate — all 5 criteria PASS before design begins

What the interview enforces — and why it can't be fooled by confident answers.

The adaptive interview doesn't follow a script. It follows what you reveal — and it keeps asking until the gaps are closed.

01
One question at a time
You're never handed a questionnaire. Each answer shapes the next question. Vague answers trigger follow-ups that force specificity. Concrete answers unlock the next layer. The interview adapts to you.
02
Ideation context without ideation constraints
IDEA.md is read before the interview begins — full context on what you explored and what you assumed. None of it is binding. The Product Brief can deviate completely. Context-aware and direction-free.
03
Misunderstandings caught early
After the interview, an outline is generated — not the full document. You review the structure before any prose is written. Correcting an outline takes two minutes. Correcting a full document takes twenty.
04
Every assumption you'll see
The outline includes an explicit "ASSUMPTIONS I AM MAKING" section listing what the agent inferred. You review and correct before any assumption becomes embedded in the document. Hidden beliefs don't survive this.
05
Nothing from ideation falls through
Before generating the outline, the agent reviews IDEA.md again — checking whether assumptions you flagged were addressed, open questions answered, variations accounted for. Gaps surface before the document is written.
06
A real person, not a persona
Abstract personas allow vague thinking. The interview keeps asking for a real name and a real scenario until you have one. Real people force specificity. Design decisions become obvious when optimizing for Sarah, not "developers."
07
Clarity enforced, not assumed
After BRIEF.md is written, an autonomous review agent evaluates it against eight criteria. If any fail, the verdict is REJECTED and the phase doesn't advance. Human approval isn't enough — the standard is mechanically enforced.
08
Scope is explicit — in and out
BRIEF.md requires both "In Scope" and "Out of Scope" with reasons. Six months later when someone proposes a new feature, the Product Brief either includes it or excludes it. The debate ends. The document answers.
Every phase that follows executes on this

Misalignment at this phase costs 3–8 weeks per downstream phase.

Market Validation validates what the Product Brief defined. UI/UX designs for who the Product Brief specified. Architecture builds what the Product Brief scoped. Ambiguity here multiplies through everything that follows.

Start my spec session — $297
$297 early access — first 100 builders  ·  Becomes $447 after

Brief to document in 5 steps.

The outline-first pattern separates understanding from writing. The structure is reviewed and approved before any prose is written.

01

Idea Comprehension Review

The agent reads IDEA.md and presents its understanding of what was explored — what excited you, what you assumed, what you decided not to build. You confirm or correct. The interview starts from shared understanding, not the agent's interpretation.

02

Adaptive Interviewing

One question at a time, drawing from six categories: Problem & Motivation, Target User, Desired Outcome, Market & Alternatives, Differentiation, Success Criteria. Vague answers get follow-ups. Concrete answers unlock the next layer.

03

Pre-Outline Gap Check

Before writing anything, the agent reviews IDEA.md again — surfacing assumptions not yet addressed, open questions unanswered, variations unaccounted for. Gaps are resolved here, not discovered in the Brief Review stage gate.

04

Outline Approval

BRIEF-outline.md is generated showing what was understood, what assumptions the agent is making, and what's missing. You approve, request corrections, or keep refining. This loop repeats until the structure is right — before a word of prose is written.

05

Full Document + Stage Gate

Once the outline is approved, BRIEF.md expands it into 2–4 pages — problem, users, use cases, goals, success criteria, constraints, scope in and out. Then Brief Review evaluates it against eight criteria before any design work begins.

Stage Gate

Unlike the Idea Phase, the Product Brief has a formal stage gate. An autonomous review agent evaluates BRIEF.md against eight criteria — problem clarity, target user specificity, desired outcome, internal consistency, business model presence, evidence basis, founder context, and stability for design. APPROVED only if all eight pass. REJECTED triggers revision before design begins.

The adaptive interview in practice

When your answers are vague, the interview keeps asking. This is what that looks like:

You say
What follows
"We want to make developers more productive."
"Describe a real developer who has this problem. What is their name?"
"Everyone will want this."
"Narrow it. Who specifically? Who has this problem most acutely?"
"Users want better search."
"How do you know that? What tells you search is the problem and not something else?"
"It should be faster."
"What metric improves and by how much? What does 'faster' mean, measured?"
"We'll build a dashboard that shows..."
"What problem does that solve? What's breaking down today without it?"

The phase doesn't assume your idea arrived fully formed.

Three ways the Product Brief Phase finds its footing — including when the interview is over and the document comes back wrong.

Scenario 01

The agent misunderstood your answers

The interview felt productive. Then the outline arrives and it's not quite right. The problem statement focuses on time savings when you meant something about trust. The use case misses the key context. You'd need to rewrite half of a full document.

The outline-first pattern catches this at minimal cost. You review the structure — not prose, just what was understood — and correct it before any writing happens. Two minutes, not twenty.

What you walk away with

A revised outline that correctly captures what you meant — before any prose investment. The document that emerges reflects your actual intent, not the agent's first interpretation.

Scenario 02

Brief Review rejects your document

You approved the outline. You approved the full document. Brief Review comes back: REJECTED. "Problem statement conflates two different problems. Success criteria undefined. Scope unclear between v1 and future." You're frustrated — you thought you were done.

The rejection isn't failure, it's precision. The review found what would have caused problems in design: a designer would have guessed which problem to solve. The rejection includes exactly what to fix and why. Answer three specific questions, the agent revises the document, the second review returns APPROVED.

What you walk away with

BRIEF-v2.md that passes all eight criteria — a document that provides design stability, not one that looks complete but leaves fundamental questions open.

Scenario 03

The Product Brief reveals the idea needs rethinking

Brief Review rejects with a finding you didn't expect: "The brief conflates three different problems — search, trust, and learning. These may be separate products." You look at the rejection and realize the reviewer is right. You've been conflating three ideas.

The orchestrator offers to return to the Idea Phase with the Brief Review feedback as input. The Idea Phase re-opens, this time focused on which of the three problems to pursue. A refined IDEA-v2.md emerges. The Product Brief Phase restarts from the clarified foundation. The iteration loop worked exactly as designed.

What you walk away with

A Product Brief built on a genuinely clarified idea — not one that tried to specify its way through an ambiguous foundation. The review loop caught what would have caused problems for every phase that followed.

Phase 2 of six. The strategic anchor of the workflow.

Creative exploration ends here. Disciplined definition begins. Every phase that follows executes on what the Product Brief establishes — not their own interpretation of what you said in a kickoff meeting.

Phase 01
Idea
IDEA.md
Phase 02
Product Brief
You are here
Phase 03
Market Validation
MARKET-analysis.md
Phase 04
UI/UX Design
UIUX.md
Phase 05
Architecture
ARCHITECTURE.md
Phase 06
Features
F-001...F-N

The Product Brief is the first phase with a formal stage gate. If Brief Review rejects, the workflow halts. Nothing advances on an ambiguous foundation.

You can skip this and move straight to design.

Teams do it. The tradeoffs are the same every time.

Without Product Brief Phase

Faster start, unpredictable cost

  • Designers optimize for the user they imagined, not the one you specified
  • Hidden assumptions get built into architecture before anyone names them
  • Success criteria defined retroactively — after the product ships
  • Scope creep has no tiebreaker — every feature request restarts the debate
  • Six months in, your team is building three different products in their heads
  • Pivots feel like starting over because there was nothing concrete to change from
With Product Brief Phase

Clearer start, compounding clarity

  • Design has a specific user and a documented problem — no guessing
  • Assumptions become explicit validation targets in Market Validation
  • Success is defined before building begins — evaluation is objective, not political
  • "Out of scope" in BRIEF.md ends debates — documented, not debated
  • Every phase executes on the same definition, not their interpretation of your intent
  • When direction changes, it changes from a documented foundation
The Reframe

Product Brief clarity compounds. Market Validation validates what the Brief defined. UI/UX designs for who the Brief specified. Architecture builds what the Brief scoped. Features implement what the Brief committed to. Ambiguity in the Product Brief multiplies through every phase that follows. Clarity in it does too.

Two principles that shaped every decision in this phase.

"People don't want to buy a quarter-inch drill. They want a quarter-inch hole."

— Theodore Levitt · Marketing Myopia (1960)
Most product specs describe the drill. The Product Brief forces you to define the hole — the specific outcome the user is trying to achieve, the progress they're trying to make. A brief built around the drill produces a product with features. A brief built around the hole produces a product with purpose. The difference shows up in every design decision, every scope boundary, every success metric downstream.

"Clarity is a prerequisite for execution, not a luxury that comes after it. Teams move slowly not because they're bad at execution, but because they lack a shared mental model of what success looks like."

— Michael Ashford · Founder Mode: From Operator to Architect
The Product Brief Phase builds that shared mental model — explicit, documented, reviewed against objective criteria, and approved before any design or architecture work begins. Not a kickoff deck that everyone interprets differently. A precise written definition that serves as the single source of truth for everything that follows.

I built the outline-first pattern after watching teams approve interviews that felt right but produced documents that missed the point. The adaptive interview doesn't follow a script — it follows what you reveal. And the stage gate isn't courtesy. It enforces what your intuition alone can't.

— Robert Evans

This is the hour that prevents the month.

Product Brief misalignment is cheap to fix before design starts. After architecture and features build on it, it costs weeks — not a conversation.

$297 < 1 design sprint · saves 6+ weeks of misaligned work per project
Start my spec session — $297
$297 early access — first 100 builders  ·  Becomes $447 after
One payment. Yours forever. Runs locally in Claude Code. 30-day guarantee.