In this guide 6 sections
An MVP assumption statement has four lines. It names the belief you are testing, the user who must act, the action that proves it and the result that would make you stop. Fill it in before design starts. Every feature then serves that line or waits.
Why a long idea needs one sentence
Most founders arrive with a document of thirty screens. Each screen is a small hope. None of them is a question the market can answer yes or no. Founders who skip this step often spend months building the second, third and fourth screen before learning that nobody wanted the first one.
An assumption statement forces the choice. You pick the single belief that, if wrong, makes the rest pointless. Everything else is decoration until that belief survives contact with real users.
Write it on paper first. If it runs past two lines, you are describing a product, not an assumption.
The four lines of the template
Line one is the assumption. Line two names the user who must act. Line three is the action that proves it. Line four is the result that would make you stop.
Keep each line to one sentence. Use nouns from the real job: a named role, a document, a count of people, a number of days. Words like engage, adopt or love do not belong here. Prefer a plain verb with a count and a date, such as booked, uploaded, paid or reordered, because anything fuzzier cannot be checked against a log.
The fourth line is the one most people skip. Without it every result looks like encouragement.
- Assumption: we believe that…
- User: the person who must act is…
- Proof: they will…, without being chased, by…
- Stop: if fewer than… do this by…, we stop or change course
A worked example from a clinic booking idea
Take a founder who wants a booking app for physiotherapy clinics, with packages, reminders, exercise videos and a loyalty scheme. The thirty screens shrink fast. Take a founder who wants a booking app for physiotherapy clinics, with packages, reminders, exercise videos and a loyalty scheme, and watch how fast the thirty screens shrink.
Assumption: front desk staff will accept bookings through a shared link instead of phone calls. User: the receptionist at a single clinic. Proof: forty bookings arrive through the link in three weeks without the desk steering patients to it. Stop: fewer than ten bookings, or the receptionist returns to the paper diary.
Notice what disappeared. Videos, loyalty and packages cannot prove the belief, so they wait.
Cutting scope against the statement
Lay your feature list beside the four lines. For each item ask one question: does the user need this to complete the proving action? Yes stays. No is parked.
Sign-in, the core form and a confirmation message usually stay. A settings page, a profile photo and a reports tab usually go. Pricing screens go unless the assumption is about payment. A settings page, a profile photo, a reports tab and a second language usually go, while sign-in, the core form and a confirmation message usually stay.
Be strict about the last mile too. Tracking that counts the proving action must be in scope, or you will finish the test and not know the result.
- Needed to complete the proving action: keep
- Needed to measure the proving action: keep
- Needed only to look finished: park
- Needed only for a second user type: park
Review the statement before build starts
Read it aloud to someone outside the project. If they cannot say what you will know in four weeks that you do not know today, tighten it. Choose someone who knows nothing about the product, because a friendly insider will fill the gaps in your wording without noticing that they did so.
Share it with the build team and ask them to sign beside it. When a new request comes in the fifth week, you both have the same sheet to hold it against.
At the end of the pilot, return to line four first. Did you hit the stop result or clear it? Write the answer under the statement and date it.
Assumption statement worksheet
Four boxed lines for assumption, user, proof and stop result, each with a prompt underneath. Below them sits a feature table with columns for item, needed to complete the action, needed to measure it and decision (keep or park). A footer holds the test dates and two signature lines.
Open a blank worksheet to printQuestions owners ask
Can an MVP test more than one assumption?
It can, but each extra one dilutes the result. If two beliefs depend on each other, test the earlier one first. Run the second pilot once the first has an answer. Whichever one you choose, write the stop result before launch and share it with your build team, so nobody can move the goalposts once the first numbers arrive.
What if I cannot choose between two assumptions?
Pick the one that would hurt most if wrong. Ask which belief, if false, makes the other irrelevant. That one goes first.
How specific should the stop result be?
Specific enough to argue about in advance. Name a count of users, a time window and the action. Agree it before launch, when you are still neutral.
Is this the same as a hypothesis?
It is close. The difference is the fourth line. A stop result turns a hopeful claim into a test that can fail, which is what makes the pilot worth running.