[Product or Feature name] — One-Page Brief

The brief carries the why. It is the artifact you reread at every major decision, which is the whole point. A document you reread is memory. A document you do not is an archive. One page, hard cap.

Owner: Date / version: Status: Draft | Committed | Shipped

---

Problem

Who has it, how often, and how much it costs them today. One paragraph. No solution language. If you find yourself describing a feature here, stop and move it to the prototype.

Who it is for

The specific user or segment. If the answer is "everyone," you have not defined it yet.

Why now

What changed that makes this worth building today and not last year. New constraint, new capability, new competitor, new data.

The bet

The outcome we believe this produces. One sentence, in "if / then" form.

If we do this, then [measurable change in user or business behavior].

Success metric

The one number that tells us we won. One primary metric, one guardrail metric. Not a list.

• Primary: [metric] from [baseline] to [target] by [date].
• Guardrail: [metric we must not harm] stays above/below [threshold].

Non-goals

What we are explicitly not doing, so scope does not creep silently. Three to five lines.

Open questions

What we do not know yet, and how we will resolve each one: prototype, eval, or research.

• [question] → resolve via [prototype / eval / research]
• [question] → resolve via [prototype / eval / research]

---

Rules for this document

1. One page, hard cap. If it does not fit, you are describing the solution. The solution belongs in the prototype, not here.
2. No solution language above. The what and how live in the prototype.
3. Reread it at every major decision. That is the entire job of this page. Put it at the top of the ticket, the PR description, the launch doc.
4. Version it. When the bet changes, bump the version and note what changed. A brief that silently drifts is worse than no brief.