What Is an MVP and How to Scope One

What an MVP actually is

The term was popularised by Eric Ries, author of The Lean Startup. In his 2009 guide to the minimum viable product he defines it as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."

Two things follow from that definition, and Ries points them out himself:

• It is about learning, not about being small. He writes that MVP, despite the name, "is not about creating minimal products". The point is to find out whether people want the thing, and the first version must be built so that you can learn from it.
• There is no formula. Because the definition balances "maximum" learning against "least" effort, it takes judgment to decide what makes sense in each case.

The Lean Startup principles put the MVP at the start of a build, measure, learn loop. So an MVP is not simply "version 1 with fewer features". It is the first version whose job is to answer a question: will these people use this to solve this problem?

Start with the problem

Most MVPs go wrong before any design work starts, because they begin with a solution. The UK government's guidance on the discovery phase says that if you are handed a predefined solution, you should question it and reframe it as a problem to be solved. Its example: the problem is not "we need to build an interactive map to show people where our contact centres are", but "how can we make it easier for people to find their nearest contact centre if they need to book a face-to-face appointment?"

Write your problem the same way before you list a single feature:

• Who has the problem? Be specific: "dog groomers who take bookings by phone", not "pet businesses".
• What goes wrong for them today, and how do they cope now?
• How will you know it is better? A number you can watch, such as bookings made without a phone call.

Find your riskiest assumptions

Every idea rests on assumptions: that people have the problem, will change how they work, will pay, or that a key integration is possible. The GOV.UK alpha phase guidance calls identifying and testing your riskiest assumptions a crucial part of the work. Its example is the Register to vote service, which needed an API that integrated with the registration systems of over 400 local councils. If that had not been possible the service would not have worked, so that is what the team focused on first.

List yours and mark which are most likely to be wrong and would do the most damage if they were. Those decide what the MVP must test.

How to scope it

With the problem and the risky assumptions written down, scoping becomes a series of cuts:

1. Pick one group of users. Michael Seibel of Y Combinator, in his talk How to plan an MVP, advises focusing on a small set of initial users and their highest-order problems, and ignore the rest until later: "You should have a vision of everyone. You should have an MVP, very small."
2. Pick one journey. The one thing those users must be able to do from start to finish. Our guide on writing a project brief shows how to write these as user stories and sort them into must, should and could have.
3. Time-box the list. Seibel suggests deciding when you want to launch and only allowing features you can build by then. That removes everything that will not fit.
4. Write it down, and cut again when you are behind. He notes that an unwritten spec drifts, and a three-week plan turns into a three-month plan.

Decide up front what you will measure: if the question is "will groomers take bookings online?", count bookings, not sign-ups.

What to leave out, and what not to

Seibel's example is an early Airbnb, with no payments and no map view. These are usually safe to postpone:

• Automating what a person can do by hand for the first users, such as approvals or reports.
• Admin dashboards beyond the basics, extra user types, languages and edge-case settings.
• A native app, when a web app can test the idea. Our guide Mobile app or web app? helps with that choice.

Some things cannot wait, because cutting them harms real people or makes the test meaningless:

• Security and privacy for any personal data, payments or logins you do collect.
• Legal and store requirements such as a privacy policy and the store rules for your app.
• Accessibility basics. The GOV.UK discovery guidance notes that in the UK, 1 in 5 people report a permanent disability.
• Reliability of the core journey, or users leave for reasons that have nothing to do with the idea.

An MVP does not have to be an app

Sometimes the cheapest way to learn is to build very little software. Seibel says most people should build a lean MVP, "fast, in weeks, not months", and that some startups simply begin with a landing page and a spreadsheet. Ries describes spending two weeks building a feature nobody wanted, and says a simple advertising "smoke test" would have shown much sooner how weak the idea was.

Options include a landing page that collects sign-ups, a clickable prototype, or a service you run by hand behind a simple form. Where the idea cannot be tested without serious engineering, scope the first build around the riskiest technical assumption.

Test it with real users

Start small and widen the group as the product improves. The GOV.UK beta phase guidance describes a private beta, where you invite a limited number of people so you can get feedback and make improvements, before opening up to everyone.

Both app stores have tools for this:

• Apple TestFlight. Apple's TestFlight page says you can add up to 100 internal testers from your team and invite up to 10,000 external testers. The first build for external testers must be approved by App Review for TestFlight.
• Google Play testing tracks. Play Console offers internal, closed and open tests. Internal testing reaches up to 100 testers, and Google recommends starting there before a closed test with a small group. Google also requires personal developer accounts created after 13 November 2023 to run a closed test with at least 12 testers, opted in for at least 14 days in a row, before applying for production access. Plan that into your timeline.

A web app needs no store review: you can share a link with your first users the day it is ready, which is one reason a web MVP is often the fastest way to learn.

After the MVP

Look at what users did, not only what they said, then decide whether to keep improving or pivot to a new idea, as the Lean Startup principles describe. Seibel's advice is not to fall in love with your MVP: it is "just step one in a journey".

If the idea works, the next round covers the "should have" list and what you left out. Our guide How much does it cost to build an app? explains what drives the budget for that next stage.

Frequently asked questions

What does MVP stand for?

Minimum viable product. Eric Ries defines it as the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort.

Is an MVP the same as a prototype?

Not quite. A prototype is usually something you show people to test a design or an idea. An MVP is something real users actually use, so you can see what they do. A clickable prototype can be a good step before an MVP.

How long should it take to build an MVP?

There is no fixed answer, and it depends on what you need to learn. Y Combinator's Michael Seibel says most people should build a lean MVP fast, in weeks rather than months.

Should my MVP be a mobile app?

Only if the idea depends on things a web app cannot do well, such as reliable push notifications, offline use or device hardware. A web app can be shared with a link and needs no store review, so it is often the faster way to test an idea.

Have an idea you want to test? See how we approach web application development and mobile app development, or email info@creahive.com with the problem you want to solve and who has it.