The short answer
An MVP is the smallest thing you can put in front of real users that tests your riskiest assumption. It is an experiment, not a cut-down product. Start by writing down the one belief that would sink the idea if it were false, pick the cheapest MVP type that tests it (concierge, wizard of oz, single feature or no-code), and time-box the build to a few weeks.
On this page (8)
An MVP is an experiment, not a small product
The phrase 'minimum viable product' has been stretched until it means 'version one, but rushed'. That reading causes most MVP failures. Founders build a smaller version of the full product, launch it, get a lukewarm response, and cannot tell whether the idea was wrong, the execution was thin, or the wrong people saw it.
A better definition: an MVP is the cheapest artefact that produces evidence about the assumption most likely to kill you. Sometimes that is software. Often it is a spreadsheet, a form and you doing the work by hand. The test is not whether it looks like a product but whether, at the end, you know something you did not know before and can act on it.
This framing also changes what 'viable' means. It does not mean polished. It means that the person using it gets enough real value that their behaviour tells you the truth. A demo nobody can use produces opinions. Something people can actually rely on, even if it is held together by hand, produces behaviour.
Start from the riskiest assumption
Every idea rests on a stack of beliefs: that a specific group has the problem, that they will pay to solve it, that you can reach them, that you can deliver the result, that they will keep using it. Write them down as plain sentences. Then ask of each one: if this turned out to be false, would the whole idea collapse, and how confident am I that it is true?
The riskiest assumption is the one that is both fatal and uncertain. That is what the MVP tests, and nothing else. If you are confident you can build the thing but unsure anyone will switch from their current spreadsheet, the MVP is about switching, and writing clean code is a distraction. If demand is obvious but delivery is technically uncertain, the MVP is a technical spike, and a landing page tells you nothing new.
Write the test as a sentence with a threshold before you start, for example: 'If at least five of the first fifteen office managers we onboard use the weekly report three weeks in a row, we keep going.' The numbers here are an example; choose ones that would genuinely change your mind. Deciding the threshold afterwards turns every result into a success.
The four MVP types and when to use each
These overlap and you can move between them. A common path is to start concierge with a handful of customers, notice which steps you repeat every time, automate those with no-code tools, and only write custom software once the workflow has stopped changing every week.
| Type | What it is | Best for testing | Main weakness |
|---|---|---|---|
| Concierge | You deliver the outcome personally, openly, with no product at all | Whether people value the result enough to pay and come back | Does not scale and can hide how hard automation will be |
| Wizard of oz | A product front end, with humans doing the work behind it | Whether people will use the product as designed | Easy to underestimate the real cost of automating it later |
| Single feature | Real software that does exactly one job well | Whether the core job is valuable on its own | Users may need the surrounding workflow to get value |
| No-code | Built from forms, databases, automations and site builders | Workflow and willingness to pay, quickly and cheaply | Hits limits on performance, permissions and edge cases |
What to cut
A useful rule: if removing a feature would not change the answer to your riskiest assumption, remove it. Things you cut are not lost; they go on a list you can revisit once the core is proven.
- Sign-up flows and account settings — For the first customers, you can create accounts by hand. A login screen tests nothing.
- Billing automation — Send an invoice. Taking money matters; automating how you take it does not, yet.
- Admin dashboards — You can query the database or read the spreadsheet directly.
- Edge cases — Handle the main path. When an unusual case appears, deal with it manually and write it down.
- Integrations — Unless the integration is the product, export and import a file instead.
- Branding and polish — Clean and legible beats beautiful. Nobody switches because of a logo.
- Features requested by one person — Note them. Build them only once several customers ask for the same thing unprompted.
Time-box the build
Scope expands to fill the time available, and an MVP with no deadline becomes a product with no users. Set a fixed window, commonly somewhere between two and six weeks depending on the type, and cut scope to fit the window rather than extending the window to fit the scope.
Split the window into building and learning. If you have four weeks, perhaps one to two weeks build and the rest is putting it in front of people and watching. A schedule where the build eats the entire window and launch is 'next week' is the most common way MVPs drift into six-month projects.
When the time-box ends, make a decision against the threshold you wrote at the start: continue, change the approach, or stop. If you find yourself wanting another month 'to see', ask what specific result in that month would change your decision. If you cannot name one, you already have your answer.
Signs your MVP is actually version one
- You cannot state the assumption it tests in one sentence.
- You are building features for users you have not spoken to yet.
- The launch date has moved more than once and the scope has grown each time.
- You are choosing a tech stack for scale you do not have.
- There is no number written down that would make you stop.
Your action checklist
0/7 doneSaved in this browser only. Nothing is sent anywhere.
Questions
How long should it take to build an MVP?
Long enough to test one assumption and no longer. Concierge and no-code MVPs can often be running within days; single-feature software might take a few weeks. If your plan says several months, you are probably building a full first version. Cut scope to fit a fixed window and keep part of that window for watching real users rather than building.
What is the difference between a prototype and an MVP?
A prototype shows how something might work and is usually used to gather reactions or test usability. An MVP delivers real value to real users so you can observe what they actually do, including whether they pay or return. Prototypes produce opinions; MVPs produce behaviour. Both are useful, but only the second tells you whether people need the thing.
Is a landing page an MVP?
It can be a useful test, but it tests something narrow: whether your message makes people take a small action such as joining a list. It does not test whether the product solves the problem or whether people keep using it. Treat a landing page as a demand smoke test that sits before an MVP, not as a replacement for one.
Should I charge for my MVP?
Usually yes, if it delivers real value. Payment is the clearest signal that the problem matters, and free users behave differently from paying ones. You can offer a discount for early customers in exchange for feedback, but a price of zero removes the most useful piece of evidence you could collect at this stage.
Terms in this guide
Finished? Mark it so your paths and the library remember.