MVP design: launch the smallest product that proves the point
An MVP fails in two ways: it is too big to learn from, or too rough for people to judge fairly. We help you decide what the first version must prove, design that properly, and test it before engineering commits.
What should you do first?
Before designing an MVP, write down the one assumption the first release must prove, such as that a specific user will complete a specific job with your product, and design only what is needed to test it convincingly.
Everything else is deferred on purpose, not forgotten. The core flow, though, should be designed properly: a rough version of the main job tests whether people tolerate rough software, not whether your idea is right.
You're in this situation if
- The business goal is clear and the product is not
- The feature list for version one keeps growing
- Investors or early customers are waiting for something to try
- Nobody has watched a target user attempt the core task
- Engineering is ready to start and the flows aren't
How we help
Discovery (2 to 3 weeks)
Interviews with target users, competitor and category review, and a written definition of what the MVP must prove.
Scope the first release
The core flow and the minimum around it, with everything else consciously parked.
Design the core flow properly
Information architecture, interaction and interface for the one job that matters, including errors and empty states.
Prototype and test
Clickable prototypes tested with people who match your users, before code.
Foundations for later
A small set of tokens and components so version two extends version one rather than replacing it.
Your options, honestly compared
| Best when | Risk | |
|---|---|---|
| Discovery only | You are not yet sure what to build or for whom | Low cost; you still need design afterwards |
| Discovery + MVP design | You know the users and need a tested first release | The usual choice for funded early-stage teams |
| Design sprint | One specific question needs a fast, prototyped answer | Answers a question, does not design a product |
| Build first, design later | The product is internal or throwaway | Redesign cost arrives with your first real users |
Related work
A new developer platform designed from research, replacing three tools with one.
Frequently asked questions
What should an MVP include?
The one core flow that proves your main assumption, designed properly, plus the minimum around it (sign-up, a way to get help, a way to measure). Everything else is deferred deliberately.
How long does MVP design take?
Discovery runs two to three weeks. Designing and testing the core flow usually adds several more, depending on complexity. You get written dates before we start.
Do we need discovery if we already know our users?
Sometimes not. If you have recent, first-hand evidence of the problem and the users, we can go straight to scoping and design. We will tell you if discovery is not worth it.
Will the MVP design need to be thrown away later?
It shouldn't. We keep a small set of foundations, such as tokens, components and naming, so later versions extend the MVP rather than replacing it.
What does your first version need to prove?
Tell us the idea and the users. We'll tell you what we would put in the first release, and what we would deliberately leave out.