Minimum viable product (MVP): how to design one

What is a minimum viable product?

The term was coined by Frank Robinson in 2001, then popularised by Eric Ries (The Lean Startup, 2011) and Steve Blank. A minimum viable product is the version of your product that contains just enough to check that a market exists. Its goal is not to please, nor to be complete: it is to produce validated learning, as early and as cheaply as possible.

Two words in the phrase matter. Minimum: anything that does not help test the main hypothesis is removed. Viable: what remains must genuinely solve the problem for someone, otherwise the test proves nothing.

The MVP is not the start of your product. It is the start of your learning.

The MVP also forces you to focus. A team’s natural tendency is to add features. You end up with a bloated product nobody adopts, and it becomes impossible to know why. A narrow scope makes failure readable, which is exactly what you are after.

MVP, POC, prototype: don’t mix them up

• The proof of concept (POC) answers a technical question: is it feasible?
• The prototype answers a usability question: do people understand it and know how to use it?
• The MVP answers a market question: do people use it for real, and are they willing to pay or change their habits?

The three complement each other, but they are not measured in the same way:

Many projects, particularly in AI, stop at the POC believing they have built an MVP. I cover this in from AI POC to production.

How to choose the scope: features or segment?

There are two ways to slice an MVP.

By features

You pick the few features that seem to generate interest and offer them broadly. Tempting, but risky: with a fuzzy target, the feedback is contradictory and you don’t know who you are talking to.

By customer segment

You pick a precise group, with a precise problem, and build only what that group strictly needs. This is the approach I recommend almost every time. It produces consistent feedback, lets you talk to real users every week, and sets you up to win a niche before widening.

In practice, the right question is not “which features?” but “for whom, and to test which hypothesis?”. That is the role of the hypothesis roadmap: listing what you need to prove, in order.

The forms an MVP can take

An MVP is not necessarily software. Choose the cheapest form that produces the signal you need:

• The pre-order page: a value proposition, a price, a button. It tests interest and price, not usage.
• The concierge service: you deliver the service by hand, customer by customer. You learn exactly what they need before writing a line of code.
• The Wizard of Oz: the user sees an interface, a person does the work behind it. Useful for testing a function that will be automated later, AI included.
• The single-feature product: one task, done properly, for one segment. This is the form closest to a real product.

The method, in five steps

1. Write down the main hypothesis. “Managers of X lose time on Y and will pay to reduce it.” One sentence, testable.
2. Choose the segment. Small enough that you can talk to everyone in it, real enough that the result counts.
3. Define the success signal before building. A usage rate, a purchase commitment, four-week retention. Not “positive feedback”.
4. Build the minimum. A page, a form, a service delivered by hand behind a simple interface. Automation comes after the proof.
5. Measure, talk, decide. Continue, redirect or stop, based on the signal set in step 3.

To structure steps 1 and 2, the Business Model Canvas and the Lean Canvas remain good tools. A shared whiteboard is enough to fill them in as a team.

Step 3 is the one most often skipped. Write the threshold down in black and white, with the decision rule: “if fewer than X users out of Y come back in week three, we drop this lead”. Set after the fact, a threshold always adjusts itself to the result you got.

A worked example

A fictional example, to make the method concrete: a team wants to help office cleaning companies plan their rounds.

1. Hypothesis: “Operations managers at cleaning companies with 20 to 100 employees spend several hours a week redoing schedules after absences, and will pay a subscription to spend less time on it.”
2. Segment: around ten companies in the same region, reachable by phone, that have agreed to a six-week trial.
3. Signal: at least six companies out of ten use the proposed schedule every week by the end of the trial, and at least three accept a price announced from the start.
4. Build: no app. Every Sunday, the team receives the list of absences through a form, redoes the schedules by hand in a spreadsheet and sends them back by email. Time spent is logged.
5. Decision: after six weeks, the team knows whether the need is real, which cases come up most often, and how long the task takes. If the signal is reached, it automates the most frequent cases first.

This MVP cost almost nothing in development. It cost human time, and that is deliberate: that time is a direct measure of the value of the future software.

How do you know your MVP is ready to launch?

Three criteria, no more:

• It genuinely solves the problem it was designed for, even if only roughly.
• A small group of users has tried it, and the obvious blockers have been fixed.
• You have talked to potential customers and they have shown concrete interest: time, a commitment, a payment.

If it meets these criteria, launch. If you wait until it looks presentable, you are already building version 1, without knowing whether it should exist.

Before opening access, also check these practical points:

• The hypothesis and the decision threshold are written down and shared with the team.
• The useful events are measured: sign-up, first action, return the following week.
• You know who talks to users, and how often.
• Personal data is handled properly, even for a test.
• A decision date is set in the calendar.

Typical mistakes, and how to spot them

1. The MVP that keeps growing. Symptom: every review adds “one more small feature”. Check whether each addition serves the main hypothesis. If nobody can say, remove it.
2. The signal chosen after the fact. Symptom: at the end of the test you discover that “engagement is encouraging”. If the threshold was not written down beforehand, the test settled nothing.
3. Testers who are too close. Symptom: the only active users are friends, colleagues or project partners. Count usage by people who owe you nothing.
4. The segment that is too broad. Symptom: contradictory feedback from one interview to the next. Narrow it until the problems people describe look alike.
5. The MVP that never dies. Symptom: a “temporary” test still online a year later, with no decision. Set the decision date from the start.

Small team or large organisation

In a startup or a small team, the MVP is often the company itself. The risk is enthusiasm: you build too much because you believe in it. The safeguard is simple: a written threshold, a decision date, and someone on the team whose job is to argue for the “stop” option.

In a larger organisation, the MVP has to survive the process. The obstacles are compliance, security, data access, successive sign-offs. Negotiate an explicit frame before building: a restricted segment of internal users or customers, a limited duration, authorised data, and a sponsor who accepts that the result may be negative. Without that frame, the MVP turns into a six-month project.

In a small business that wants an internal tool rather than a product to sell, the logic still holds: start by checking that off-the-shelf software is not enough, then limit the first version and its budget to what proves the value.

What AI changes in 2026

No-code tools for moving fast still exist. But coding assistants and interface generators have changed the equation: a small team can now produce in a few days a simple prototype that used to take several weeks.

The direct consequence: build cost is no longer the limiting factor. The limiting factor is the quality of the hypothesis and how fast you get real feedback. It has become easy to build far too much, very quickly, for nobody.

Three reflexes to keep:

• Building fast doesn’t excuse you from choosing. The scope must stay minimal, even when adding more costs almost nothing.
• For an AI feature, start with a human in the loop. Have cases handled by hand, or reviewed, before automating: you learn what “a good answer” means for your users.
• Measure from day one. An MVP without instrumentation is a demo.

A quickly generated prototype must also be reviewed before real users see it: forms, data collected, mandatory notices, security. The checks for a website built with AI largely apply to an MVP.

In hindsight

I wrote the first version of this article in 2022. I would keep the essentials: slice by segment rather than by features, set the signal before building, accept that a negative result is a result. These three rules have held in every context where I have applied them since.

I would nuance two things.

First, I set the MVP against the “presentable” product a little too sharply. When building is cheap, a polished prototype can be an excellent learning tool, as long as you don’t mistake it for market proof. The danger has moved: it is no longer about spending six months building, but about shipping in two weeks something nobody asked for. At Dotworld, four SaaS products were shipped in under six months. When delivery moves that fast, choosing what not to build becomes the real discipline.

Second, I underestimated how much of an MVP is organisation. I now argue that successful AI transformations are 70% organisation and 30% technology, and an MVP often follows the same ratio. At Home Partners of America, the customer service work started with the support teams, listening to calls and mapping journeys, before the gradual rollout of an assistant. The use cases were chosen there, not in a tool.

What AI assistants have changed in my product work is real: prototypes in a few days, cheaper experiments, interviews synthesised faster. They have also added a task: checking. A generated prototype can work in a demo and fail on the first real case. An interview synthesis can smooth over exactly the nuance that mattered. So I review what they produce the way I would review the work of a fast new colleague: with interest, and without signing it blind. To measure what an AI feature really delivers once launched, see measuring an AI assistant.

The MVP remains what it has always been: the first step towards market fit, and the starting point of your product roadmap.

Frequently asked questions

How long does it take to build an MVP?

As long as it takes to build the minimum that tests your main hypothesis: ideally a few weeks. If your plan runs past a quarter, the scope is probably too broad or the hypothesis poorly framed.

Does an MVP have to be paid for?

Not necessarily, but it must secure real commitment: a payment, a pre-order, time invested, a change of habit. Polite interest is not a signal.

What if the MVP doesn’t validate the hypothesis?

That is a result, not a failure. You have learned at low cost. Reframe the hypothesis, change segment or value proposition, and run a more targeted test.

Can an AI-generated prototype serve as an MVP?

Yes, if real users use it in their work and you measure a signal set in advance. Review it before opening it up: data collected, security, real cases. A successful demo is not market proof.

Should an AI feature be automated from the MVP stage?

Rarely. Start by handling cases by hand or with human review. You learn what a good answer is for your users, and you get a baseline for measuring the automation later.