Product brief — one-page templateReference Doc· 2 min read
Product brief — one-page template
Align problem, users, metrics, and explicit non-goals on a single page before anyone draws a diagram or books a sprint.
Use this outline in Confluence, Notion, or a Markdown file in the repo. The goal is a shared vocabulary and testable assumptions before architecture or sprint commitments.
If two readers disagree on what "success" means, stop. Clarify the brief first.
The one-page outline
- Problem statement — user pain + business pain in one paragraph. No solution yet.
- Target users — personas or segments + primary jobs-to-be-done.
- Success metrics — leading (activation, retention) and lagging (revenue, NPS) with rough targets.
- Constraints — regulatory, SLA, budget, timeline, dependencies on other teams.
- Non-goals — what is explicitly out of scope for this phase. Say no to scope creep early.
- Risks & open questions — what must be validated before build; who owns each discovery item.
How to use it in practice
| Anti-pattern | Better move |
|---|---|
| Brief is already a slide deck with diagrams | Write the problem in one sentence everyone can quote |
| Metrics are vanity counts | Pair leading + lagging with owners |
| Non-goals section empty | List the three tempting features you will refuse this phase |
| Risks owned by "the team" | One name per open question |
Quality bar before kickoff
- Problem sentence fits in a Slack message without losing meaning
- At least one leading and one lagging metric named
- Three non-goals written (not implied)
- Each open question has an owner and a "decide by" date
- Constraints include the boring ones: compliance, settlement, support load
Bottom line
Architecture without a brief invents requirements in the pull request. A one-page brief is cheaper than a quarter of thrash.
If you cannot say what you are not building, you have not decided what you are building.