We’ve watched this happen on enough engagements to be able to predict it. The brief reads as a feature catalogue. The team treats it as a contract. Build velocity slows. Discovery never finishes. The first release ships a version of the wishlist that’s late, undercooked, and no closer to the actual goal than the brief was.

The teams whose MVP builds do ship write a different shape of brief. Shorter. Sharper. Built around the question the product is meant to answer rather than the things the product is meant to do.

This is the shape we use, with one example from the work where we last applied it.

Two pages, not twenty

Here’s the rule we hold to. If the brief doesn’t fit on two A4 pages, the brief isn’t done. Not “almost done”. Not “we’ll trim it later”. Not done.

The reason isn’t aesthetic. A long brief signals that the team hasn’t yet decided what the product actually is. The wishlist is in there because nobody’s been brave enough to take things off the page. Two pages forces the conversation about what stays and what goes. That conversation is the work.

A useful two-page brief contains, in this order: the question the product is meant to answer, the customer it’s meant to answer it for, the moment in their day where it has to land, the smallest version of an answer that proves the thesis, and what gets explicitly cut. The cut section often takes more space than the in-scope section. That’s a feature.

From twelve features to four

A few years ago we walked into a FTSE 100 energy network operator with a brief titled something like “Predictive Maintenance Platform”. Twelve features. Three personas. A roadmap stretching to the next financial year. A data team, a hardware team, a regulatory programme, all expecting their requirement to be in the build.

We rewrote the brief on the second day. The new title was the question, not the platform: “Predict the leaks before they happened, on the network we already had sensors on.” Everything not pointed at that question got listed in the cut column. Twelve features became four. Three personas became one (the engineer running the night shift). The roadmap became eight weeks to a working signal.

The signal worked. The team had a working version inside the eight-week window, and the other eight features stayed in the cut column for the rest of the engagement. We’ve published the full case study at reignites.co.uk/work. The point here is what the rewrite did: it gave the team something to say no to. Without that, every meeting was a discussion about which feature to add next, which is a slow, expensive way to discover you’re not building the right thing.

The two-page test

Once a draft brief exists, we run it through three questions. Each one is meant to break the document.

Could a busy non-technical person read it on a Friday afternoon and tell us back what the product is? If not, the brief is too long, too jargon-heavy, or both. Rewrite it before you do anything else. This is the same plain English test we apply to every other piece of writing on this site. It’s not a marketing affectation. It’s the most reliable way we’ve found to surface jargon hiding as substance.

Does the build team know what they’re not building? Cuts beat scope. If the brief lists fifteen things and the team can’t tell you which fifteen things were thought about and rejected, the cuts haven’t happened yet. Make the cuts now, on paper, before the build starts. Cuts deferred to later become arguments in week three when there’s no time to debate them.

If the first release shipped tomorrow, would it answer the question? Not “would it impress someone”. Would the existence of the live thing tell you whether the underlying thesis was right or wrong. If the answer is “well, we’d need three more iterations to know”, the MVP is too big or the thesis is too vague. Cut more, until the thesis fits in one release. That’s the ship-or-don’t-ship line.

What this looks like in practice

A worked example, made up but representative of the shape:

• Question: Can a customer renew their account in under a minute without calling support?
• Smallest answer: A self-serve renewal page for monthly subscribers paying by single card, with one-click confirm.
• Cuts: All annual customers. All bundle changes. All card-on-file edits. All non-card payment methods. Cancellation flows. Upsells. None of it ships in v1.

That’s the entire shape on a napkin. The cuts list is longer than the scope, and that’s why this version has a chance of shipping in eight weeks instead of eight months.

What we don’t recommend

Templates. Frameworks. The “lean canvas” and any of its cousins. Canvases can be useful as input to the conversation, but they’re not the conversation itself. A canvas with empty boxes is a brief that hasn’t done the work yet, because someone still has to make the decisions the canvas is asking about. People do that, not formats.

The thing the brief is meant to do is force the conversation about what gets cut. Two pages, written in plain English, pointed at a single question, with explicit cuts, signed by the person who’ll have to live with it. That’s the shape.

If your current brief doesn’t look like that, the cheapest thing you can do this week is rewrite it. The brief that does the work won’t collapse under its weight, because the weight has already been removed.