What is an MVP? The meaning of minimum viable product

An MVP (minimum viable product) is the simplest version of a product that already genuinely helps real users. You build only what is needed to solve one core problem, put it in front of users and let their behaviour tell you what to build next. It is the first working version of a product, built to learn rather than to impress.

You will come across the abbreviation MVP in two worlds. In sport it means Most Valuable Player, the best player of a match or season. In business and software development, MVP always means minimum viable product. This article is about the second meaning.

What does minimum viable product mean exactly?

Together, the three words explain what an MVP is.

• Minimum: as small as possible. Anything that is not needed to solve the core problem stays out.
• Viable: it has to work and deliver value. A user must be able to complete a real task with it.
• Product: not a drawing or a presentation, but something people use in their own situation.

The point of an MVP is not to get something online quickly. The point is learning. You want to find out, with as little building as possible, whether your assumption holds: do people have this problem, does your solution solve it, and are they willing to pay for it or change the way they work?

Where does the term MVP come from?

The term is attributed to Frank Robinson, who used it around 2001. It became widely known through the lean startup movement, with Steve Blank and above all Eric Ries. In his book The Lean Startup (2011), Ries describes the MVP as the version of a new product that lets a team learn the most about its customers with the least effort.

Ries ties the MVP to a fixed loop: build, measure, learn. You build something small, measure how people use it, draw a conclusion and adjust the product. So an MVP is not an end point. It is the first round of that loop.

What an MVP is not

The term comes with plenty of misunderstandings. These are the three that cost the most money:

• Not a half-finished product. An MVP does little, but what it does, it does well. An app with ten half-working features is not an MVP. An app with one feature that works is.
• Not a prototype. A prototype shows how something could look or work. An MVP is actually used, with real data and real consequences.
• Not a cheap version of the final product. If you treat the MVP as the budget edition of the whole plan, you build too much and learn too little.

MVP, prototype, proof of concept and MMP: the difference

These four terms are often used interchangeably. Each answers a different question.

• Proof of concept (PoC): is it technically possible? You test whether an idea can be done, for example whether an integration or an AI model does what you expect. Users usually never see it.
• Prototype: what does it look like, and do people understand it? You test form and usability, often with a clickable design and nothing working behind it.
• MVP: do people actually want to use it? You test the value, with a working product in the hands of real users.
• MMP (minimum marketable product): can you sell it to a wider market? The MMP is the first version you actively take to market, with everything that comes with it, such as payments, onboarding and support.

The order is not always PoC, prototype, MVP, MMP. If the technology is well known, you skip the proof of concept. If user behaviour is the big unknown, you sometimes start straight with an MVP.

The benefits of an MVP

• You learn sooner. You see what users do before most of your budget is spent.
• You build less that nobody uses. Features are only added once it is clear they are needed.
• You limit the risk. If the assumption is wrong, you find out with a small investment and can change course or stop.
• You have evidence for the next step. Usage data and feedback from real users convince a board or investor more than a plan does.
• Your product grows on the right foundation. A well-built MVP is the start of the real product, not something you throw away.

Pitfalls: where it goes wrong

• Putting too much in. The temptation to add one more feature is strong. Every extra feature makes the build longer and the outcome less clear.
• Putting too little in. A product that does not really solve the problem gives you no useful information. You will not know whether the idea is bad or the execution.
• No measurement plan. Without a question and metrics agreed in advance, you will not know afterwards what the MVP proved.
• The wrong users. Colleagues and friends are kind. You need people who actually have the problem.
• A foundation that cannot grow. Building fast is not the same as building carelessly. Skip security, the data model and maintainability, and you will rebuild the second version from scratch.

How to set up an MVP in six steps

1. Start with the problem

Describe who you are building for and which problem you solve. Not the solution, but the situation. What does your user do today, what does it cost them, and why is it worth changing?

2. Make your riskiest assumption explicit

Every product idea rests on assumptions. Pick the one that brings the whole idea down if it turns out to be wrong. For example: customers want to submit their request online themselves instead of phoning. That is the assumption your MVP tests.

3. Decide how you will measure it

Agree in advance when the MVP counts as a success. How many users complete the core task? Do they come back? Are they willing to pay? A concrete criterion stops you from reading every outcome as a win afterwards.

4. Cut until only the core is left

List every feature and ask of each one: is this needed to test the assumption? If not, it moves to later. What remains is often a single route from start to finish for a single type of user. Your own password system, extensive settings and an admin area for everything can usually wait.

5. Build small, but build it properly

Choose technology that can grow with you and get the basics right: security, privacy and a data model that can be extended. What can stay manual may stay manual. An email that a colleague still sends by hand is fine in an MVP.

6. Launch, measure and decide

Put the MVP in front of real users, collect data and talk to them. Then make one of three decisions: keep building, change course or stop. All three are a good outcome, as long as they are based on what you have seen.

Examples of an MVP

An MVP does not even have to be software. A few forms that often work:

• Landing page: you describe the product and measure how many people sign up before anything is built. You test demand, not the solution.
• Concierge MVP: you first deliver the service by hand, for a small group of customers. That shows you exactly which steps to automate later.
• Wizard of Oz: to the user it looks automated, but behind the scenes a person does the work. Useful when the technology is expensive and demand is still uncertain.
• Single-feature product: a web application or app that does one task well. Think of a customer portal where customers only submit a request and track its status, without all the other features that come later.
• Internal first: a new platform goes to one department or one group of customers before you roll it out widely.

How much does an MVP cost and how long does it take?

There is no fixed answer, and anyone who gives you one without knowing your plan is guessing. Cost and timeline depend on a handful of factors:

• the number of user roles, such as customer, employee and administrator;
• the number of integrations with existing systems;
• the platform: web only, or also an app for iOS and Android;
• the requirements for security, privacy and accessibility;
• how much of the design and the processes is already settled.

The biggest cost driver is almost always scope. Every feature you cut makes the MVP faster and cheaper. Plan in weeks, not quarters: the longer the build takes, the later you learn. A fuller breakdown of the cost items is in what it costs to build an online platform.

When is an MVP not the right step?

An MVP is meant for uncertainty. If you already know exactly what is needed, for example because you are replacing an existing internal system whose use is well established, a minimal version will not help much. The question then is whether to have something built or choose an off-the-shelf package. That trade-off is covered in custom software or an off-the-shelf package.

In sectors where a product has to meet strict requirements from day one, such as medical or financial applications, the minimum is higher too. The principle stays the same: build only what you need to learn, but that minimum then includes the mandatory requirements.

How Your Tech Club helps with an MVP

We do not start with the technology but with what needs to get better, and for whom. Opportunity first. Technology second. Together we decide which assumption the MVP has to test, what goes in and what can wait.

Then we build the first version so that it can grow into the real product. That might be a web application, a customer or partner portal, or the start of a SaaS product. After launch we measure what users do and improve from there. How we take digital products from idea to platform is described under digital products and platforms.

Have a product idea and want to know the smallest version that already delivers value? Book an intro call and bring your idea.