A useful MVP brief makes three decisions before design starts: who the product is for, what version one will deliberately leave out, and what user evidence will justify the next investment. That is why the brief is not paperwork. It is the first product decision.
Founders often arrive with a brief that is really a description of the idea: a few paragraphs about the market, a feature list, and a sentence about where the product could go someday. It is enough to start a conversation, but not enough to ship against. A build team needs a smaller, sharper document that turns ambition into a sequence of testable choices.
A useful brief does three jobs
1. It names the person who has the problem
“Small businesses” is a market. It is not a first user. A good brief names the person, the moment they are in, and the workaround they use today. A clinic manager trying to fill tomorrow's cancellations has a different problem from a patient looking for a new appointment, even if both belong to healthcare. The more specific the first user is, the easier it becomes to decide what the product should do next.
2. It draws a line around version one
A feature list tells you what has been imagined. A scope line tells you what will be built. Write the core loop in one sentence, then list the work that makes that loop reliable: the main screen, the one meaningful action, the data behind it, and the feedback that tells the user it worked. Everything else is a candidate for later, not a silent requirement for launch.
3. It defines the proof that comes next
“Launch and see what happens” is not a learning plan. Decide what you expect to observe in the first few weeks: a completed workflow, a repeat action, a paid conversion, or a founder-led interview with a specific type of user. The measure does not need to be sophisticated. It needs to be close enough to the user's behaviour that it can change the next product decision.
What to write down before a screen
- The first user: one role, one situation, and one painful workaround
- The core loop: the smallest action that creates value and can happen repeatedly
- The launch boundary: what is explicitly out of scope for version one
- The trust requirement: what the user must see, control, or understand before they act
- The next proof point: the behaviour or conversation that earns another round of build work
The scope test we use
Take every proposed feature and ask one question: does this make the core loop more likely to succeed for the first user? If the answer is no, move it out of the first release. If the answer is maybe, write down the assumption it is protecting and find a cheaper way to test that assumption. This keeps a useful feature from becoming a permanent excuse to delay the product.
The goal of a brief is not to capture everything you might build. It is to make the next build decision obvious.
— a rule we use in product kickoffs
Frequently asked questions
How long should an MVP brief be?
Short enough to read in one sitting and specific enough to make trade-offs. One to two pages is usually plenty when it names the first user, core loop, launch boundary, trust requirements, and next proof point.
Should the brief include a full feature list?
Include the features that make the core loop work, then keep the rest in a later-ideas section. A separate parking lot protects good ideas without letting them quietly become launch requirements.
What if the target user is still uncertain?
Write down the two strongest candidates and the evidence that would distinguish them. Uncertainty is useful when it is explicit; it becomes expensive when it is hidden inside a broad product scope.
Does the brief need to be finished before design starts?
It should be clear enough to guide the first design pass, not frozen forever. Design is allowed to expose a better question, but every change should update the scope and the proof you are trying to collect.