What is an MVP, and what is it not?
An MVP, or minimum viable product, is the smallest version of your software that real people can use to get a real result. Its job is to teach you something, quickly.
It is not a rough draft of the final product, and it is not a demo. It has to work, but it does not have to do much.
Step 1: Decide who it is for and what hurts
Write one sentence: this helps [specific person] do [specific task] without [specific pain]. If you cannot fill in the blanks, you are not ready to build. Talk to five or ten people in that group first. Listen for the problems they already spend time or money on.
Step 2: Choose one core workflow
Pick the single path through the product that delivers the value. For a scheduling tool, it might be: create a job, assign a person, mark it done. Everything your product does should serve that path.
Step 3: Make the cut list
Write down every feature you have imagined. Then move most of them to a later list. Invoicing, reports, integrations and admin tools can nearly always wait. Writing the cut list down makes the trade-offs visible and keeps scope from creeping back in.
Step 4: Choose plain, proven technology
Use mainstream tools that many developers know. You can hire for them later and they will not box you in. A web app that also works well on a phone is usually enough for a first version. Build it multi-tenant from the start so each customer's data stays separate.
Step 5: Build in short cycles with real users
Ship something usable every few weeks. Put it in front of five real users early, and watch what they do, not only what they say. The features they ignore tell you as much as the ones they love.
Step 6: Measure what matters
| Measure | What it tells you |
|---|---|
| Activation | Did new users reach the first useful result quickly? |
| Weekly active users | Do people come back without being nudged? |
| Core task frequency | How often is the main workflow used? |
| Trial to paid | Will people actually pay? |
| Reasons for leaving | What is missing or confusing? |
Step 7: Decide what to build next
Use what you learned. Double down if people return and pay. Change direction if they like it but will not pay. Stop, if need be, before you have spent the whole budget. All three outcomes are better than guessing.
A worked example: a scheduling MVP for small contractors
A founder who has worked with plumbers and electricians wants to build a job scheduling app. Her list has twenty features. After a scoping conversation, the first version does three things: an office user creates and assigns a job, a technician sees their day on a phone and marks the job done, and the customer gets a reminder.
Everything else, from invoicing to route planning, waits. She can now test the one thing that matters: will small contractors use this every week, and will they pay? This is a hypothetical example to show the thinking.
What does the first month usually look like?
- Interview potential users and agree the single core workflow.
- Sketch the key screens and test them on paper with two or three users.
- Set up the technical foundation: accounts, database and hosting.
- Build the first slice of the core workflow, end to end, even if it looks plain.
Which MVP mistakes are most common?
- Building features nobody asked for.
- Spending months on design before a single user sees it.
- Choosing exotic technology that is hard to hire for.
- Skipping measurement, so nobody can say what worked.
- Treating launch as the finish line instead of the start of learning.
When should you not build yet?
If you have not spoken to potential customers, test the idea first with a simple prototype, a landing page or a manual service. Software is the expensive way to learn that nobody wants something.
Related: SaaS and product development · Startups and SaaS · All articles