How to write a one-page product brief

Long specs get skimmed. A one-page brief gets read, argued with and remembered. Here is a structure that fits on one page and still forces the hard thinking.

The five sections

1. Problem: who has it, how you know (name the evidence: interviews, support tickets, usage data), and what they do today instead.
2. Goal: one measurable outcome, with a number and a date. If you have three goals, you have none.
3. Non-goals: what this work will deliberately not do. This section prevents most scope arguments later.
4. Proposed solution: the smallest thing that could meet the goal, in a few sentences or one sketch.
5. Risks and open questions: what could make this wrong, and who is finding out by when.

A quick example

Problem: New users abandon setup at step 3 (41% drop-off, 8 of 12 interviewed users said they didn't know what to connect first). Goal: Raise setup completion from 59% to 70% by the end of next quarter. Non-goals: Redesigning the whole onboarding flow; adding new integrations. Solution: A default "connect your first source" suggestion at step 3, with a skip option. Risks: The suggestion may bias users toward a source that isn't right for them. We will check activation at day 7, not only completion.

How to use it

Write the draft alone, then share it with engineering and design before a meeting, not in it. Ask one question: "What is missing or wrong?" Revise once, then commit. If the brief won't fit on a page, the problem is probably still too big.

Pair it with a scoring pass: our RICE scorecard helps decide which brief to write first.