What Is a Minimum Viable Product? A Practical Guide

Four stages in sequence, proof of concept, prototype, MVP and pilot, with the MVP highlighted and the question: will people use it?

Quick answer: A minimum viable product (MVP) is the smallest version of a product that real people can use, released to learn whether it works for them with the least effort. It is judged by what it teaches you, not by how many features it has. A good MVP tests your riskiest assumption, supports one core task end to end, and is built to grow. It usually follows a prototype and comes before a pilot or full release.

Software tends to grow bigger than it needs to be. When Pendo analysed usage data across its customers’ products in 2019, it found that 80 per cent of features in the average product were rarely or never used. Every one of those features was scoped, designed, built, tested and maintained.

The minimum viable product exists to stop that happening. Instead of building the complete product and finding out at launch which parts matter, you release the smallest version that people can use, watch what they do with it, and let that evidence decide what comes next.

It sounds like a startup idea, and it was. But established organisations need it more, because they face more pressure to launch something complete: stakeholder wishlists, funding deadlines and a reputation to protect. This guide covers what an MVP is, how it differs from a proof of concept, a prototype and a pilot, and how to scope one that teaches you something.

What a minimum viable product is, and what it isn’t

Eric Ries popularised the term through his writing on lean startups. In his 2009 definition, the minimum viable product is “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

The important word is learning. An MVP is measured by what it tells you, so three common versions miss the point:

A cut-down version of everything. Twenty half-built features give people nothing they can complete, so you learn nothing about whether the product works.
A prototype with a launch date. A clickable mock-up tests whether people understand a design. An MVP is live software that people use for a real task.
A rushed first release. Minimum applies to scope. Quality, reliability, security and accessibility still have to be there, or the feedback you get will be about the bugs.

Henrik Kniberg’s skateboard-to-car illustration is the clearest picture of the idea. If the goal is a car, delivering a wheel first gives the customer nothing they can use. Delivering a skateboard, then a scooter, then a bike gives them a way to get around at every step, and each step teaches you what the car should be. For that reason Kniberg suggests “earliest usable product” as a clearer name.

Proof of concept, prototype, MVP and pilot: where each one fits

The four terms get used interchangeably, but each answers a different question. Run them in this order and each one reduces the risk of the next:

Proof of concept: will the risky part work for us? A small, real build that tests whether the hardest unknown (an integration, a data source, a new technology) is viable at all. It is often never seen by customers. A proof of concept that returns a clear no is still a success, because it stopped an expensive build.
Prototype: what should it be? A model of how the product could look and work, from paper sketches to a high-fidelity clickable design. You test it with real users before writing production code, because changing a design is cheap and changing software isn’t.
Minimum viable product: will people use it? The smallest live release that lets real users complete a real task, so you can measure behaviour instead of opinion.
Pilot: does it hold up in operation? A limited rollout of a product that already works, to one region, team or customer group, to test support, training and scale before going wide.

Not every product needs all four. A proof of concept matters when the technology is uncertain; a pilot matters when the rollout is large or regulated. The prototype and the MVP are the two steps worth keeping almost every time.

Why a minimum viable product matters more for established organisations

A startup with no customers has little to lose from a rough first release. An established organisation has existing customers, internal stakeholders who each want their feature included, and often a fixed deadline set by funding, regulation or a contract. That pressure pushes scope up, and the first release becomes the complete product by default.

An MVP gives you a defensible way to say “not yet” to most of the list. It puts a working product in front of the people it is for, and lets their behaviour settle the debates that would otherwise be settled by whoever argues hardest.

Cleanaview, Cleanaway’s self-service customer portal, shows the approach under a hard deadline. The platform needed urgent design and build to meet a delivery deadline set by two councils. Working to that deadline, Conduct and Cleanaway built a co-designed MVP that was continually updated and iteratively tested based on user feedback.

How to scope a minimum viable product: five steps

Scoping is where most of the value is won or lost. These are the five steps we work through:

Name the riskiest assumption. Write down what has to be true for the product to succeed, then pick the assumption that would sink it if it turned out to be wrong. That assumption is what the MVP is for.
Choose one task to support end to end. Pick the single task that tests that assumption, such as booking a collection, submitting an application or recording a career path, and make it work completely, from first screen to confirmation.
Prototype and test that task before writing code. Put a clickable prototype in front of real users, watch where they hesitate, and fix the design while changes are cheap.
Decide what not to build yet, and write it down. Every feature you defer goes on a visible list with the reason it was deferred. That list turns stakeholder requests into a queue rather than a fight.
Agree what will decide the next release. Before launch, set the measures that matter (task completion, return visits, support calls, feedback) and the threshold that would change your plan. Then release, measure and iterate.

AMillionPaths, a platform for documenting and sharing career paths, shows steps three and four in practice. AMillionPaths came to us with a patent specification and an early prototype. We took the design from wireframes to a high-fidelity prototype and tested the core flows with real users before any production code was written. Just as important was deciding what not to build yet: we scoped a focused first release AMillionPaths could take to market, with a foundation ready for the phases to come.

How AI tools change the minimum viable product

AI-assisted design and development tools have changed the cost of the build steps. A team can now turn a sketch into a clickable prototype, or a tested prototype into working software, much faster than was practical even a few years ago. That changes what an MVP can be: instead of testing a mock-up, you can often put a working version with real data in front of users, and run more rounds of learning before committing to the full build.

What AI doesn’t replace is the design process. Learning what people need still comes from research with real users, and their behaviour is still the evidence that counts. Deciding what the product should be, and what to leave out, still draws on years of product design and strategy experience. AI helps execute those decisions faster; it doesn’t make them. And when building gets cheaper, it gets more tempting to build more, which is exactly what an MVP exists to prevent. So the scoping steps above matter more, not less: one risky assumption, one task end to end, and a written list of what not to build yet.

We work this way ourselves. Our own operations platform, Waypoint, replaced seven subscriptions and is built so AI agents can work on its data directly. If the product you are testing needs AI inside it, such as an agent that answers questions from your own data, our AI development work covers how we approach that.

Minimum in scope, viable in quality: building an MVP that can grow

The two failure modes of an MVP pull in opposite directions. Build it as a throwaway and you rebuild it from scratch the moment it works. Engineer it for every future feature and it stops being minimum.

The balance is to keep the scope small and the foundations sound. Choose an architecture and data model that can carry the next few releases, even if the first release uses a fraction of them. Make the parts you do build reliable and secure. And make them accessible from the start: a product that excludes some of its users gives you feedback from only some of them, and retrofitting accessibility later means reworking what you have already built (our WCAG 2.2 guide covers what that involves).

The same principle applies when the product replaces an existing system: release in stages that each deliver value on their own, rather than waiting for one large switchover. Our guide to application modernisation without a big-bang rewrite covers that approach in more detail.

Since 2008, Conduct has designed and built web applications, mobile apps and custom software for government, enterprise and not-for-profit organisations, often starting with a prototype and a focused first release. If you have an idea you want to test with real users before committing to the full build, talk to us.

An MVP isn’t a smaller product. It’s a faster answer.

Frequently asked questions

What is a minimum viable product?

A minimum viable product (MVP) is the smallest version of a product that real people can use, released to learn whether it works with the least effort. Eric Ries defined it as the version that allows a team to collect the maximum amount of validated learning about customers. A good MVP supports one core task end to end and is built to grow into the full product.

What is the difference between an MVP and a prototype?

A prototype is a model of how a product could look and work, such as a clickable design, used to test whether people understand it before any production code is written. An MVP is live, working software that people use for a real task. Prototypes answer “what should it be?”; an MVP answers “will people use it?”

What is the difference between a proof of concept and an MVP?

A proof of concept tests whether the riskiest technical part of an idea is viable at all, and is often never seen by customers. An MVP is a usable product released to real users to see whether they adopt it. A proof of concept comes first when the technology is uncertain; the MVP follows once you know it can be built.

How long should it take to build an MVP?

It depends on the task the MVP has to support, but the aim is to get a working product in front of real users as soon as it can teach you something. If an MVP keeps growing and the release date keeps moving, the scope has crept back towards the full product. Revisit the riskiest assumption and cut back to the one task that tests it.

What should an MVP include?

Everything needed for one core task to work end to end, and very little else. That includes the unglamorous parts that make it viable: reliable data handling, security, accessibility and a way to collect feedback and usage data. Features that don’t serve the core task go on a written list of what’s deferred and why.

Can AI tools speed up building an MVP?

Yes. AI-assisted design and development tools make prototypes and first releases much faster to build, so you can often test a working version with real users instead of a mock-up. They don’t replace the research with real users, or the product design and strategy experience, that decide what to build. Because building is cheaper, keeping the scope minimum matters even more.

Is an MVP only for startups?

No. The term comes from the startup world, but established organisations often benefit more, because they face stronger pressure to launch a complete product. An MVP gives government agencies, enterprises and not-for-profits evidence from real users before committing their full budget, and a clear way to prioritise competing stakeholder requests.