Why we start every Project with a one-page brief

Every project we have rescued had the same problem: two smart people, each holding a different picture of the finished product. Nobody was careless. The picture just never made it onto paper.

So before we write a line of code, we ask for a one-page brief. It is deliberately short, because a short document gets read, argued over and updated.

What goes on the page

1. The problem, in plain words. Who is stuck, and what does it cost them today?
2. The outcome. What will be true when the work is done that is not true now?
3. The boundaries. What is explicitly not part of this release?
4. The risks. The two or three things most likely to hurt us.

If you cannot explain the project on one page, you are not ready to build it yet.

Why one page works

A long specification feels safe, but nobody reads it twice. A single page forces trade-offs early, when they are cheap. It also gives everyone the same sentence to point at when a new idea shows up halfway through: does this serve the outcome, or is it a new project?

We revisit the brief at the end of every sprint. Sometimes we change it. That is fine, as long as we change it on purpose and everyone sees the edit.

If you are planning something and want to try this, get in touch. We are happy to share our template.