What a minimum viable product is really for

“Minimum viable product” is one of the most widely used — and widely misunderstood — terms in product development. It is often taken to mean a cheap or unfinished version of a product. In practice, it is a disciplined way to test a product's core assumptions with real users, as early as possible.

An MVP is an experiment

Every new product rests on a set of assumptions: that people have the problem, that they will find the product, that they will try it — and that they will return. An MVP exists to test the riskiest of those assumptions with real people, as quickly as possible.

This changes the objective. The goal is not to release a reduced version of the full product. It is to release the smallest product that can confirm or challenge the idea it is built on.

Minimum means focused

Effective MVPs do one thing well rather than many things adequately. We identify the moment where the product delivers its core value — a booking confirmed, a payment completed, a problem resolved — and focus on making that experience fast, clear and reliable.

Every other feature is assessed against one question: does it help us learn what we need to learn now? If not, it is scheduled for a later release.

“Reduce scope, not quality. A focused product that works reliably will teach you more than a broad one that does not.”

Viable means used in real conditions

A prototype gathers reactions; an MVP gathers behaviour. It should be complete enough for people to use it for their actual problem, with their own data, as part of their normal routine.

That is where reliable evidence comes from — not from what people say in interviews, but from whether they return without being prompted.

In practice, that means finishing the details that build trust — clear copy, sensible error messages, a payment flow that feels safe — even when the feature list is short.

Keep operations manual where you can

In the early stages, it is often more effective to handle some processes manually rather than automate them immediately. Matching, approvals, onboarding and parts of service delivery can run behind a well-designed interface while you learn what really matters.

This shortens development time and accelerates learning. When you do automate, you are automating a process you understand rather than one you assumed.

Common pitfalls

MVPs that stall tend to share a small number of issues:

• Scope creep — the first version keeps expanding and the launch date keeps moving.
• Under-investing in quality — cutting so much that users cannot rely on it for a real task.
• Launching without a feedback plan — releasing the product with no structured way to learn from users.

Each one delays the main purpose of an MVP: learning from real use.

Decide what success looks like before launch

An MVP without a clear success measure is simply a smaller launch. Before development starts, we agree on what we need to learn and what result would confirm it. For example:

• A share of sign-ups who complete the core action in their first week.
• A number of users who return without a reminder.
• A first customer willing to pay, even a small amount.

After launch, we monitor usage closely and speak with users regularly. The first version is a starting point, and each subsequent release should be guided by evidence rather than opinion.

Further reading: How to Build an MVP — Michael Seibel, Y Combinator