template · feature brief

Feature Brief template

Copy-paste skeleton. Two pages maximum. Trio sign-off required before first story.

How to use

Replace every [...] with concrete content. Read through once before writing — the order matters. The experience snapshot is written first, the prediction last. If a section resists, see What to do if a section resists at the foot.

# Feature Brief — [name of the feature]

## Experience snapshot   (150–200 words)
[A specific moment in a specific named person's day. Time, place,
 what they are doing, what is going wrong, what they would
 normally do at this moment, what they have stopped noticing.
 No UI language. No feature names. No "the user". Begins with
 "It is [day, time]. [Named person] sits at…"]

## Purpose   (one sentence)
[The change in the world. Bound to the named person. Measurable.]

## In scope   (concrete capabilities, not features)
- [Capability 1 — names a thing the named person can newly do]
- [Capability 2]
- [Capability 3]

## Out of scope (this cycle)   (with rationale)
- [Excluded capability 1]
  Reason: [why this is deferred — usually risk-to-prediction or
  not on the journey step we are changing]
- [Excluded capability 2]
  Reason: [...]

## Prediction
Baseline:     [Number, sample size, date, witnessed how]
Target:       [Specific number / range / threshold]
Check date:   [Calendar commitment]
Check method: [Specific. Same shape as baseline. No
               "we will ask".]
Owner:        [Named person. Not a role.]

## Success signal
[One sentence the trio can recite. Restates the prediction
 in human terms.]

## Sign-off
PO:        [Name] · [date]
Designer:  [Name] · [date]
Tech Lead: [Name] · [date]

## Linked artefacts
- Initiative Brief: [/briefs/initiative/...]
- Technical Design Brief: [/briefs/tdb/...]
- Journey map: [link]
- Observation notes: [link]

Worked example — the Grading Shortcut brief

# Feature Brief — Grading Shortcut

## Experience snapshot
Gal sits down at 3:15pm on Friday with 30 exams to grade. The
class submitted yesterday morning; she has marked nothing yet.
She opens the first exam in the dashboard, scans, types her
score, clicks Submit. The screen reloads to the dashboard list.
She finds the next exam, clicks in, scans, scores, submits.
Each cycle takes about 90 seconds — most of it the navigation,
not the grading. By 4:00pm she has done eight; she has 22 left.
Her hand has lifted from the keyboard to the mouse forty-seven
times. She knows the shape of the next two hours, and she has
already made her after-work plans contingent on it.

## Purpose
Let Gal grade through her exam batch without losing the keyboard.

## In scope
- Keyboard shortcut (⌘+Enter) to submit and advance to next exam
- Preservation of the grader's place in the batch
- "Next exam" navigation surfaced as a named state in the UI

## Out of scope (this cycle)
- Multi-section grading — deferred to release 2 (smaller pilot)
- Statistics view — out of this initiative; separate brief
- Bulk-import grading from a spreadsheet — not yet witnessed need

## Prediction
- Change:    Gal completes the grading cycle without lifting
              hands from the keyboard for navigation
- Baseline:  47 min mean (n=12, captured 2026-04-22 → 04-26 via
              observation; navigation accounted for 31 of 47 min)
- Target:    <15 min mean across n≥8 cycles
- Method:    Three observation sessions across three Fridays
              + product analytics on shortcut usage
- Check:     2026-06-25

## Success signal
Pilot schools' median grading session time drops from 47 min
to <15 min, observed in three sessions on three Fridays,
without an increase in helpdesk "wrong score" tickets.

## Sign-off
PO:        Alex · 2026-05-04
Designer:  Maya · 2026-05-04
Tech Lead: Esti · 2026-05-04

## Linked artefacts
- Initiative Brief:        /briefs/grading-initiative.md
- Technical Design Brief:  /briefs/grading-shortcut-tdb.md
- Journey map:             /journeys/teacher-grading.md
- Observation notes:       /observations/gal-2026-04-22.md

Where this lives in your project

The Feature Brief is paste-loaded into the cycle's brief location (Confluence space, Notion page, Linear project — wherever the team holds cycle artefacts). The signed-off brief is the gate condition for execution.

The trio sign at the bottom. No signature, no story-writing. See What We Shape · Story Mapping.

What to do if a section resists

Resistance	What it means	Where to go
Cannot name a person for the snapshot	Discovery is incomplete	Before We Build · Observation — schedule a session
Purpose is a category, not a change	The brief is solution-first	Clinic — A brief written from the solution backwards
Out-of-scope is a single line	Scope has not been fought yet	Walk Slicing & Prioritization — what is the team not doing?
Prediction fields will not fill	The change is not specific enough	Practice — Writing predictions
Only one signature on sign-off	The brief is not yet a brief	Checklist — Trio sign-off
The brief grew to ten pages	Edges have leaked into scope	Move detail to the Technical Design Brief or to stories

See also

• Practice — Writing feature briefs · Writing predictions
• Template — Prediction — the five-field skeleton this brief's Prediction section uses · Story — what this brief decomposes into
• Checklist — Trio sign-off · Prediction five fields
• Canon — Before We Build · Feature Brief · Prediction writing
• Clinic — A brief that didn't witness · A brief written from the solution backwards