Designing an MVP: what to cut and what to keep
Designing an MVP means cutting to the core that tests your riskiest assumption without sacrificing usability. Learn what goes in and what stays out.
What is an MVP?
Frank Robinson coined and defined the term in 2001, and Steve Blank and Eric Ries popularized it. The core idea is an MVP as a version with just enough features for early adopters to use it and give feedback. Ries describes it as a way to gather the maximum amount of validated learning with the least effort.
That last phrase matters. An MVP is not “an unfinished version that ships fast.” It is an experiment: a way to test a hypothesis before investing in the rest. That is why its success is measured by what you learn, not by how many features it has.
Why does it matter to a designer?
Because in most teams the feature list grows faster than the capacity to build it, and the designer is the one drawing every screen on that list. Knowing what not to design is as useful as knowing how to design well. A badly scoped MVP also produces a false conclusion: if people do not use it, you will not know whether the idea was bad or the interface got in the way.
A designer can bring a concrete judgment: which flow tests the idea, and what is the minimum interface that makes it understandable.
How do you find the riskiest assumption?
Before touching scope, write in one sentence the riskiest assumption behind the idea. Full Scale recommends exactly that: identify “the single riskiest assumption” in the business, and treat everything that does not test it as cuttable. That assumption can be technical (can it be built?), about demand (does anyone want it?), or economic (will anyone pay?).
For example, if your idea is a booking service for yoga classes, the riskiest assumption is probably not the booking interface. It is whether people will fill the classes. That decides which screens you need.
What do you cut and what do you keep?
Mockplus proposes three questions for each feature:
- Does it solve the main problem?
- Does the product work without it?
- Does it test the core assumption?
If the answer is “no” to all three, the feature probably does not belong in the MVP. Full Scale adds a practical rule: if cutting a feature makes you nervous, it probably belongs in version 2.
To prioritize, Mockplus mentions well-known methods such as MoSCoW, the Kano model, or an impact-versus-effort matrix. Use whichever you like, as long as the result is a short list.
| Keep | Cut |
|---|---|
| The flow that shows the idea’s value | Settings, personalization, and advanced preferences |
| The minimum needed to complete that task | Integrations that do not test the assumption |
| Measurement, so you know whether the flow works | Long onboarding sequences |
| Error and loading states in the core flow | Polished visuals on secondary screens |
How do you design the core?
Design around the critical flow, and do it with the same care the full product would get. Mockplus also recommends analytics from day one, with measurable funnels and elements you can A/B test. Without that, the MVP cannot tell you anything.
Cutting features is not the same as cutting usability. A confusing core flow distorts the test: you will not know whether the user rejected the idea or got lost in the interface. If the core flow is not understood, the MVP cannot teach you anything.
When is an MVP the wrong tool?
An MVP does not fit every situation. It is a poor choice when:
- The main risk is technical, and a demand experiment would not change your decisions. A proof of concept is the better tool there.
- The product must meet a safety or regulatory standard from day one, for example in payments or health. Cutting corners there can be dangerous.
- You already have enough market data and what you need is to scale.
Full Scale distinguishes the prototype, which tests the idea with your team; the proof of concept, which answers whether something can be built; and the MVP, which tests the idea with the market. Knowing which one you need keeps you from building the wrong piece.
Example
Illustrative example: a team wants to launch an app for finding pet sitters. The initial list has 40 features. Applying the three questions, the team keeps four: search for sitters by area, view profiles with reviews, send a request, and confirm the service by message. They cut real-time chat, advanced filters, in-app payments, and the admin panel, which they plan for a second phase. The assumption they test is whether owners will contact an unknown sitter. The request flow gets careful design: loading states, availability errors, and a clear confirmation. Six weeks later, they know whether the assumption holds.
Common mistakes
- Confusing an MVP with a version without design. Cutting features does not authorize neglecting the core experience.
- Cutting without a written hypothesis, so nobody knows what the MVP was supposed to test.
- Including features out of fear, even though they test nothing, “because competitors have them.”
- Measuring nothing, so the result is an opinion rather than data.
- Treating the MVP as the final version instead of an experiment that can be thrown away.
To frame the problem before choosing features, How Might We questions help, and the Kano model helps you tell what users expect from what delights them. If the MVP is part of a larger process, the UX design process shows where it fits. And if you decide to test the concept before building, paper prototyping is the cheapest way to start.