Feature Brief

WHAT'S INCLUDED

Template sections

• Feature context — feature name, product area, initiative owner, and strategic alignment
• Problem statement — the specific user problem this feature solves, validated by evidence
• User stories — three "As a… I want… So that…" statements scoped to this feature
• Success metrics — primary KPI, secondary KPI, and anti-metrics (what must not degrade)
• Scope definition — explicit in-scope and out-of-scope items to prevent feature creep
• Dependencies & risks — technical dependencies, design system requirements, and identified risks
• Timeline & milestones — discovery, design, review, and engineering handoff dates

HOW TO USE

Best practices

1. Write the problem statement before the solution. A feature brief that starts with "We need a dropdown" has skipped the most important step. Start with "Users can't currently…"
2. Include anti-metrics. Defining what must not get worse is as important as defining what must improve. Without them, teams optimise for the KPI and break adjacent experiences.
3. Scope must be explicit, not implied. "We're not building X" needs to be written down. Unwritten scope assumptions become the source of the most expensive engineering debates.
4. Get sign-off from product and engineering before design starts. A brief that only designers have read is a project plan that will change at design review.
5. Revisit the brief after discovery. Research findings often change scope or invalidate assumptions. Treat the brief as a living document through discovery, not a one-time artefact.