Most MVP briefs collapse under their own weight before a single line of code is written. The doc gets longer, the wishlist grows, the deadline drifts, and eight weeks in nobody can remember what “minimum” was supposed to mean.
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.
”Find the leaks” doesn’t fit on two pages
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.
This is a real engagement. The full case study is on /work for anyone who wants the detail. 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. 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. They’ve been deferred to later, which means they’ll surface 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 yes, the brief is pointed at the right end of the problem. If the answer is “well, we’d need three more iterations to know”, the MVP is too big or the thesis is too vague.
What we don’t recommend
Templates. Frameworks. The “lean canvas” and any of its cousins. Not because they’re wrong, but because they’re a workaround for the actual problem, which is that someone has to make decisions about what the product is. A canvas doesn’t make decisions. People do. The brief is the record of those decisions, and a canvas with empty boxes is a brief that hasn’t done the work yet.
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.