Table of Contents
- Why a good MVP brief decides your deadline
- How to write an MVP brief: the four questions that matter
- Question one: what problem are you actually solving?
- Question two: who is the user, exactly?
- Question three: what is in scope, and what stays out?
- Question four: what single metric proves it worked?
- How to write an MVP brief that fits on one page
- MVP, prototype, or proof of concept: brief the right thing
- What a sharp brief does to your build, budget, and risk
- Frequently Asked Questions
- The brief is the cheapest part of the build
Quick answer: Foundry 5 reduces how to write an MVP brief to four questions you answer before day one: the problem, the user, the core features, and the one metric that proves it worked. It fits on a single page. Incomplete and changing requirements rank among the top causes of software project failure (Standish Group CHAOS research), so the brief is what protects your timeline.
Most software does not fail in the build. It fails in the brief, in the quiet gap between what the founder pictured and what the studio actually heard. Learning how to write an MVP brief is the cheapest and fastest thing you can do to close that gap before a single line of code exists.
An MVP brief is not a specification the size of a phone book. Done well, it fits on a page. It answers a handful of questions so clearly that a studio can quote the work, lock the scope, and start on Monday without guessing. Skipped or left vague, it hands the studio silent permission to fill the blanks with assumptions, and you pay for every wrong assumption in weeks and pounds.
The stakes are not abstract. The Standish Group’s CHAOS research found incomplete requirements and changing requirements among the leading causes of software project failure, ahead of the technology itself. A clear statement of requirements is one of the strongest predictors that a project ships at all. That statement is your brief.
This guide walks through the exact questions a studio needs answered before it starts, why each one matters, and how to fit the whole thing on one page. It is written from the other side of the table, so you can see what a good studio is quietly hoping you already know.
Why a good MVP brief decides your deadline
A brief is a contract of understanding, not a wish list. When it is sharp, the studio prices what you actually want and commits to a date it can hold. When it is vague, the studio prices the risk of your uncertainty, which is why fuzzy briefs come back as padded quotes and quietly slip their deadlines.
Think about what a developer does with a blank. They do not stop work to ask about every ambiguity, because there are hundreds. They make a reasonable guess and keep moving. Multiply that across a build and you get a product that is technically finished and subtly wrong, the sum of a thousand small guesses nobody signed off. Every one of those guesses is a change request waiting to happen.
A good brief removes the guesses. It is the difference between a studio saying yes to everything and cheerfully cutting corners you cannot see, and a studio pushing back before code starts because it understands the goal well enough to protect it. The brief is where your deadline is really set. Everything after it is just execution.
How to write an MVP brief: the four questions that matter
Foundry 5 reduces how to write an MVP brief to four questions: what problem you are solving, who the user is, which features are in, and the single metric that says it worked. Answer those four with real specifics and you have a brief. Everything else is detail that hangs off this frame.
The four questions are deliberately ruthless. They force the decisions founders most want to defer: narrowing the audience, cutting the feature list, and naming the one number that defines success. A studio can build almost anything once those four answers are locked. It can build almost nothing useful while they float.
The rest of this guide takes each question in turn, shows what a weak answer looks like next to a strong one, and ends with a one-page structure you can fill in tonight. Work through them in order, because each answer narrows the next.
Question one: what problem are you actually solving?
State the problem in one sentence, from the user’s point of view, with no mention of your solution. “Freelance wedding planners lose hours rekeying supplier quotes into spreadsheets” is a problem. “An app for wedding planners” is a solution wearing a problem’s clothes. The studio needs the first kind, because the problem is the thing every later decision is measured against.
Founders rush this because the problem feels obvious to them. It is not obvious to the team building it. Before you commit to building, the UK government’s own service manual puts an entire discovery phase ahead of writing code, precisely to pin down the problem and the users before anyone builds a service. Your brief is a compressed version of that discipline.
A strong problem statement carries three things: who has the problem, what it costs them today, and how they cope right now. The current workaround matters more than founders expect, because your MVP has to beat a spreadsheet, a WhatsApp group, or doing nothing, not some imagined competitor. If you cannot describe the workaround, you do not yet understand the problem well enough to brief it.
Question two: who is the user, exactly?
Name the user narrowly enough that you could find ten of them this week. “Small businesses” is not a user. “Independent letting agents in London managing five to twenty properties” is. The tighter the definition, the sharper every design and scope decision downstream, because the team can picture a real person instead of designing for an average that does not exist.
Specificity here quietly sets your scope. A user who is a busy non-technical professional needs a different first version than a power user who lives in the tool all day. One needs three obvious buttons; the other needs speed and depth. A brief that names the user lets the studio choose correctly. A brief that says “everyone” forces the team to hedge, and hedged products feel like nothing to nobody.
If you have more than one user type, rank them. Name the single user whose problem version one exists to solve, and note the rest as later. An MVP that tries to serve three audiences at once is three half-products sharing a login screen.
Question three: what is in scope, and what stays out?
List the features, then sort every one into must-have, should-have, could-have, or will-not-have. The last category is the one that saves your budget. A brief that only lists what is in gives the studio no permission to say no. A brief that also states what is out, on purpose, is the mark of a founder who has already made the hard cuts.
Use must-have, should-have, could-have, will-not-have
This simple sort, often called MoSCoW, turns a wish list into a scope. Must-have features are the ones without which the product cannot prove its point. Should-have and could-have wait for later versions. Will-not-have is where you park the login-with-social-and-biometrics-and-account-merging ambitions that quietly turn a four-week build into a four-month one.
Be honest about hidden features. “User accounts” sounds like one item and is really six: sign up, log in, reset password, edit profile, delete account, and the permissions behind them. A studio reads that line and sees the six. If your brief hides them, your quote and your timeline will absorb them anyway, just later and less pleasantly.
The goal is not the shortest possible list. It is the shortest list that still proves the idea. Cut past that and you have a demo. Stop short of it and you have a full product wearing an MVP label.
Question four: what single metric proves it worked?
Name one number that, if it moves, means the MVP succeeded. Fifty planners complete a real booking in the first month. Thirty percent of signups come back in week two. One metric, not five. The point of an MVP is to learn something specific, and a brief without a success metric is a build without a question, which is how teams ship features nobody measures.
This is also your defence against the most expensive mistake in software. CB Insights found that 42% of startups fail because there is no market need. An MVP exists to test for that need before you spend the rest of the budget, and the success metric is how you read the result. Skip the metric and you can ship a polished product and still not know whether anyone wanted it.
A good metric is specific, measurable, and tied to real behaviour rather than vanity. Downloads flatter you; repeat use tells the truth. Write the number down in the brief, and the whole team builds toward it instead of toward a vague sense of done.
Not sure which metric actually matters for your idea? A short scoping call turns a vague vision into the one number worth building toward. Book a free 30-minute discovery call with Foundry 5. No pitch deck, no pressure, just a sharper brief by the end of it.
How to write an MVP brief that fits on one page
Foundry 5 keeps every MVP brief to a single page on purpose, because how to write an MVP brief is really an exercise in leaving things out. If it runs past a page, the decisions usually have not been made yet, and a longer document just hides that. The structure below is the whole thing, and each row maps to a question above.
| Section | What it answers | Example |
| Problem | The pain, in one sentence, from the user’s view | Letting agents lose hours chasing tenant references by email |
| User | The one person version one is for | Independent London agents managing five to twenty properties |
| Must-have features | The few things that prove the idea | Request a reference, track status, get notified when it lands |
| Out of scope | What you are deliberately not building yet | Payments, tenant portal, mobile app, analytics dashboard |
| Success metric | The one number that means it worked | Fifty references completed through the tool in month one |
| Constraints | Budget, deadline, must-use tools, compliance | Live in eight weeks, UK GDPR, integrates with existing CRM |
Add a final line for constraints the studio cannot guess: your real budget range, the deadline that actually matters and why, any tools you must integrate with, and any compliance rules such as UK GDPR. Hiding the budget does not get you a better price; it gets you a quote for a product you cannot afford. A one-page brief with these six blocks answered honestly is worth more than thirty pages of feature descriptions.
MVP, prototype, or proof of concept: brief the right thing
Before you brief a build, be sure you are briefing the right kind of build. Deciding between an MVP, prototype, or proof of concept changes the whole brief, because each answers a different question. A proof of concept asks “can this be built?” A prototype asks “does this feel right?” An MVP asks “will people actually use and value it?”
Founders often say MVP when they mean prototype, and get charged for the wrong thing. If your real question is whether a technical approach works, a small proof of concept answers it for far less. If it is whether the interface makes sense, a clickable prototype tests that without a backend. The MVP is for when you are ready to put a working product in front of real users and watch what they do.
State which one you want at the top of the brief. It sets the expectation for polish, cost, and what “done” means. A studio that has to guess whether you want a throwaway experiment or a launchable product will price for the more expensive reading, every time.
What a sharp brief does to your build, budget, and risk
A brief this tight changes the MVP build process from an act of guesswork into a plan with a date on it. When scope is locked before code starts, the studio can commit to a timeline instead of hedging, and you can hold them to it. The brief is the thing that makes a fixed quote fair to both sides.
It also compresses the calendar. A clear, narrow brief is exactly what lets a good team build an MVP in 4 weeks rather than four months, because there is nothing to renegotiate mid-sprint. Every hour goes into building the agreed thing instead of relitigating what the agreed thing was.
A sharp brief is what makes a risk-free first project possible at all. A studio can only stand behind its work when the target is fixed and shared, so the tighter your brief, the more risk a partner can absorb on your behalf. Vague briefs push risk back onto you, in the form of change fees and slipped dates.
The same discipline matters even more when intelligence is involved. If your product leans on machine learning or a language model, briefing an AI development project adds a few questions the brief must answer up front: what data you have, what a good answer looks like, and how you will measure whether the model is right often enough. Skip those and an AI feature becomes an open-ended science project instead of a scoped build.
Frequently Asked Questions
How do you write an MVP brief?
Foundry 5 writes an MVP brief by answering four questions on a single page: the problem in one sentence from the user’s view, the specific user version one serves, the must-have features with an explicit out-of-scope list, and the one metric that proves it worked. Add a short constraints line for budget, deadline, required integrations, and compliance. If the brief runs past a page, the hard decisions usually have not been made yet, and the extra length is hiding that rather than fixing it.
What should an MVP brief include?
A good MVP brief includes six blocks: the problem, the target user, the must-have features, an explicit out-of-scope list, a single success metric, and your real constraints such as budget, deadline, and compliance. The out-of-scope list matters as much as the feature list, because it gives the studio permission to say no. Everything should be concrete enough that a developer could read it once and ask sensible follow-up questions on a 30-minute call rather than guessing.
How long should an MVP brief be?
One page is the target. An MVP brief is an exercise in leaving things out, so length is a warning sign rather than a virtue. If yours runs to many pages, it usually means decisions about scope and users are still open, and a long document is standing in for a decision. A tight one-page brief that names the problem, the user, the features in and out, and the success metric beats a thirty-page specification a studio has to reverse engineer.
What is the difference between an MVP brief and a PRD?
An MVP brief is the short, founder-written document that frames the problem, the user, the core scope, and the success metric before a build starts. A product requirements document, or PRD, is usually longer and more detailed, and is often produced with the studio once the brief is agreed. Think of the brief as the decision and the PRD as the elaboration. You write the brief first; a good studio helps turn it into whatever fuller specification the build actually needs.
Who should write the MVP brief, the founder or the studio?
The founder should write the first draft, because only the founder owns the problem, the user, and the definition of success. A studio like Foundry 5 then pressure-tests it, flags hidden scope, and sharpens the wording, but it should not invent your answers for you. A brief written entirely by the studio risks encoding their assumptions rather than your intent. The strongest briefs come from a founder’s honest first pass, refined in one conversation with the people who will build it.
The brief is the cheapest part of the build
Everything expensive about software happens downstream of a weak brief: the rework, the scope creep, the polished product that misses the point. Learning how to write an MVP brief is a couple of hours of hard thinking that saves weeks of building the wrong thing. Foundry 5 treats the brief as the highest-leverage page in the entire project, because it is the one place where a founder’s clarity converts directly into a shorter, cheaper, more certain build.
Write the four answers down tonight. The problem in one sentence. The user you could find ten of this week. The features that are in, and the ones you are brave enough to leave out. The single number that means it worked. Do that, and you have already done the hardest and most valuable work in the project.
If you want a second pair of eyes on your brief before you commit a budget, book a free 30-minute discovery call with Foundry 5. No pitch deck. No pressure. Just an honest read on what to keep, what to cut, and what your studio needs to hear before day one.
Get the brief right, and the build gets easy.
