practice · briefs & discovery

Writing Feature Briefs

The artefact that names what one cycle will change. A Feature Brief begins with a named person's moment, contains a five-field prediction, and is signed by the trio. Without it, scope is hope.

TL;DR

A Feature Brief contains six things: an experience snapshot of a named person's moment (150–200 words), a purpose (one sentence), in-scope capabilities, out-of-scope with rationale, a prediction with five fields, and a success signal with check date. Two pages maximum. The trio sign it before any story is written. If you cannot fill any of the six, the brief is not ready and the cycle is not ready to start.

What it is

A Feature Brief is the contract between a Feature and a cycle. It scopes one initiative-step into one cycle of work. It is what Before We Build · Feature Brief describes, and what After We Build · Signal and the Prediction checks at the end.

Distinguish from

Initiative Brief — multi-cycle, scopes the bet itself. Technical Design Brief — the TL's translation of feasibility, sequence, schema, API. Story — the slice the developer takes; a Feature Brief contains many stories. See Confusable with at the foot.

Why it matters

The Feature Brief is where the chain learns to disagree with itself. Without it:

• Scope drifts — the team builds until it stops, not until the change lands.
• The prediction is never made — the cycle runs blind. Not checked is the only worthless outcome.
• The trio cannot refuse the work — without an artefact to read, resistance becomes a hallway conversation, not a signed disagreement.
• The cycle has no memory — without the brief, the model update has nothing to amend.

The brief is short on purpose. Two pages forces clarity. Five pages allows hiding.

How to do it

Step 1 — Write the experience snapshot first

Not last. The snapshot is the seed of the brief; everything else derives from it. Sit next to the named person; write what you witnessed in 150–200 words. Specific time, specific moment, specific friction. No UI language. No feature names. No "the user".

The corpus standard from Before We Build · Person & Moment:

It is Wednesday morning. Gal sits down at 08:50 with her coffee and opens the LMS to grade the morning's batch of CS101 finals…

If you cannot name the person, the snapshot is not ready. Read Observation. Schedule a session.

Step 2 — One-sentence purpose

What change in the world does this brief make? Bind it to the named person.

Purpose: cut Gal's grading-cycle time from 47 minutes to under 15
         so she can grade an afternoon batch without losing the
         day to it.

If your purpose contains the word enable or improve without a measurable change, it's a category, not a purpose. Rewrite.

Step 3 — In scope: concrete capabilities

What this brief commits the team to build. Not features in the marketing sense — capabilities that change what the named person can do.

In scope:
  - Hebrew-name rendering in the grader's queue and detail view
  - One-click feedback templates (3 most-common)
  - Grader queue ordering by deadline

Step 4 — Out of scope, with rationale

Out of scope without rationale is a backlog. Out of scope with rationale is a scope.

Out of scope (this cycle):
  - Multi-language feedback (English + Hebrew only)
    Reason: every additional language risks invalidating the
    prediction's check method; revisit after one cycle of signal.
  - Grading rubric editor
    Reason: not on the journey step we are changing.

Step 5 — Prediction (five fields)

Use the prediction template. Walk the Five Fields checklist. The prediction lives inside the brief; the brief is unfinished without it.

Step 6 — Success signal & check date

The success signal restates the prediction in one sentence the trio can recite from memory. The check date is the calendar commitment.

Success signal: Gal grades an afternoon batch in under 30 minutes
                of focused time on 2026-06-15.

Step 7 — Trio sign-off

PO, Designer, Tech Lead. Three signatures. If only one signs, the brief is unfinished. Walk the Trio Sign-Off checklist.

A complete Feature Brief

Feature: Hebrew-name grading flow

Experience snapshot:
  It is Wednesday morning. Gal sits at 08:50 with coffee, opens
  the LMS, and starts the morning's CS101 finals. Of the seven in
  front of her, four have Hebrew names. Each one she opens, she
  reads, then alt-tabs to a spreadsheet to copy the name with
  diacritics, then back to the LMS. By 10:00 she has graded four.
  By 10:30 she stops for water. The morning is gone.

Purpose:
  Cut Gal's grading-cycle time from 47 minutes to under 15 so she
  can grade an afternoon batch without losing the day to it.

In scope:
  - Hebrew-name rendering in the queue and detail view
  - One-click feedback templates (3 most-common)
  - Queue ordering by submission deadline

Out of scope (this cycle):
  - Multi-language feedback. Reason: every additional language
    risks invalidating the check method. Revisit after one cycle.
  - Grading rubric editor. Reason: not on the journey step we
    are changing.

Prediction:
  Baseline:     47 min mean, n=12, observed 2026-04-22
  Target:       <15 min mean across n>=8 observed cycles
  Check date:   2026-06-15
  Check method: Three observation sessions, three named graders,
                in the field. Time-on-task log as cross-check only.
  Owner:        Alex (PO)

Success signal:
  Gal grades an afternoon batch in under 30 minutes of focused
  time on 2026-06-15.

Sign-off:  PO ✅  Designer ✅  Tech Lead ✅

Copy the template →

Evidence

Across our cycles, briefs that survived contact with reality shared three properties.

1. The experience snapshot was rewritten at least once before sign-off. Briefs whose first-draft snapshot survived unedited shipped with a Level 2 (Discovery) defect 3× more often than briefs whose snapshot went through ≥1 trio-rewrite cycle.
2. Out-of-scope was longer than in-scope. Cycles where the scope was held tight shipped on the predicted date 80% of the time; cycles whose out-of-scope was a single line or absent slipped 70% of the time.
3. The trio signed before the first story landed. Briefs whose sign-off came after the first PR shipped a feature that did not change the success signal in 1 of 3 cases.

Anti-patterns

Pattern	What it looks like	Where to fix
No named person	Experience snapshot starts with Graders today are…	Clinic — A brief that didn't witness
Solution-shaped brief	The in-scope is the feature; the purpose was reverse-engineered to fit	Clinic — A brief written from the solution backwards
Vague out-of-scope	We will not boil the ocean	Replace with explicit capabilities + rationale
Prediction in a separate doc	Brief links to a sheet	Predictions live inside the brief; otherwise sign-off fragments
Trio sign-off as a single PO signature	"I'll get the other two later"	The brief is not signed
Two pages becomes ten	Edge cases, rollout plans, risk matrices added	Move into Technical Design Brief or stories; the Feature Brief is short

Confusable with

This	Not this	Difference
Feature Brief	Initiative Brief	Feature = one cycle. Initiative = a multi-cycle bet.
Feature Brief	PRD / spec doc	A Feature Brief begins with a moment; PRDs begin with requirements.
Feature Brief	Technical Design Brief	TL writes the TDB after signing the Feature Brief. Feasibility, not problem.
In-scope	Backlog	The backlog is everything we might do; in-scope is what this cycle commits to.

Further reading

• Canon — Before We Build · Feature Brief
• Canon — Before We Build · Person & Moment
• Template — Feature Brief skeleton
• Checklist — Trio sign-off
• Practice — Writing predictions · Writing initiative briefs · Writing technical design briefs
• Clinic — A brief that didn't witness · A brief written from the solution backwards
• Skill path — PO foundations · Step 5
• Reference — Area · Feature Brief