One-Page Project Brief

Why now, what ships, and how success is measured

Turn the background below into a one-page project brief. Order: 1) the problem — who, in what situation, and the cost in numbers; 2) what happens if you do nothing; 3) goals and non-goals, three or fewer each; 4) approach in five steps or fewer, plus the biggest risk; 5) success metrics as baseline to target with a measurement window; 6) resources needed and decision points. One page, no vision statements or adjectives, and no unverifiable goal like “improve the experience”.

[Background]
[Resource constraints]

How to use

The two questions a brief must survive are “what is out of scope” and “what would count as failure”. Without them, one page is just a wish list.

Good for

Quarterly planning is allocating scarce engineering time, and you need one page before the review that explains why this is worth doing and what success looks like.
A cross-team project needs product, engineering, and legal aligned; everyone has a different picture of “done” and the meetings keep getting longer.

Not for

Exploratory research where the direction is still open — fixed metrics and non-goals leave no room to experiment; run a small validation first.
It is an approved, in-flight iteration — another brief is duplicate process; write the schedule and acceptance criteria instead.

Example

Input

Support handles about 600 “wrong invoice” tickets a week at 18 minutes each; finance says 30% come from customers picking the wrong tax ID at submission. We want a self-service edit page. Engineering can spare two people for six weeks.

What you get

Open with the problem and its cost alone: 600 tickets a week times 18 minutes is about 180 hours a week, and 30% trace to a wrong tax ID. Set the goal as “60% or more self-service edits, tickets down to 240 a week, measured four weeks after launch”, and state as non-goals that you will not touch the invoicing flow or tax-authority integration. Keep the approach to five steps, name the biggest risk — tax-ID validation depends on an external API — and write the resourcing as two people for six weeks, with the decision point that finance must confirm the rules within two weeks.

Common mistakes

Opening with “as the business grows rapidly” — reviewers cannot see the problem, only someone filling in a template.
Writing success as “improve efficiency, reduce complaints” — no baseline, target, or measurement window, so nobody can tell after launch whether to keep funding it.

Try tweaking it like this

Add “if we only get half the resources, which half do we cut?”, which is more persuasive in review than “we need more people”.
Add “what signal after launch would tell us to stop”, giving the project a loss condition before it becomes a sunk cost.