When a team is told to build an MVP (“Minimum Viable Product”) first and develop the software further later, there are usually two reasons behind it. Either time is short and the most important features have to be available sooner than the rest, or there is uncertainty: “We don’t know if this will work, so let’s try it out first.”
What often gets overlooked is that product development involves several different kinds of uncertainty:
- Product uncertainty. Do our customers actually need this product or feature? Do they want it?
- Problem and solution uncertainty. Are we addressing the right problem, and are we addressing it with the right solution?
- Business uncertainty. What is the business value? Will this actually make money?
On top of that, a team needs to know whether it can build and maintain the product at all. Is the technical expertise there, and is there capacity to deliver and support it?
An MVP is not the cheapest experiment
If an MVP is meant as an experiment to test a hypothesis such as “our customers want this”, building and shipping a piece of software may already be premature. An MVP puts a real, working product in front of customers, so they react to the product itself (its UX, functionality, branding and performance) rather than to the idea behind it. Often there are cheaper ways to prove or disprove the same hypothesis:
- Interviews, surveys and market research
- Clickable prototypes and mock-ups
- Landing-page experiments
An MVP can accidentally turn into a commitment
Once a team decides “let’s build an MVP”, a chain of events is set in motion: a backlog is created, a development team is assigned, expectations are raised and milestones have to be hit.
After days, weeks or months of work, it is easy for an organisation to reach a point of no return. Too much has been invested to conclude “nobody actually wants this, let’s stop”. The more that has been built, the harder it becomes to kill a bad idea.
Reduced feature sets are mistaken for MVPs
The most common picture of an MVP is a feature set that has been reduced because of time constraints. Stakeholder opinions are collected, turned into a backlog, and that backlog is then named “the MVP”.
In corporate environments this often happens when a legacy system is replaced by new software and the organisation asks the team to “create an MVP” for the first launch. The stakeholders involved are usually department heads, clerks and other users who work with the existing processes and workflows every day. They describe the workflows they know, and those workflows are then replicated in the new system. That is the wrong starting point.
Instead of filling the so-called “MVP backlog” with familiar features that stakeholders categorise as required for their work, the team should evaluate the business value, purpose and goal of each feature. The new product should be designed around the outcomes the organisation is trying to achieve, rather than simply reproducing the capabilities of the system it replaces.
This matters because a legacy replacement does not necessarily involve product-market validation. What is uncertain is usually something different: whether the new solution can support the business more effectively, reduce operational cost, improve the user experience, remove existing constraints or enable new ways of working.
Calling the first release an MVP can therefore set a misleading objective. If the goal is to replace an existing system, cutting features may not produce a meaningful “minimum viable product” at all. Remove a capability that users genuinely depend on, and the new system can no longer support the existing business process. Copy every workflow from the legacy system, and you may replicate the same, possibly inefficient processes, with features classified as required because they have always been used rather than because they have any business value.
The question should therefore be:
What capabilities does the new product need to achieve the desired outcome?
“It’s only an MVP”
The MVP label can also turn into a justification for weak requirements, incomplete and inconsistent workflows, immature UX, inadequate security and insufficient testing.
That defeats the purpose of the experiment. If customers cannot understand the product because the UX is too immature, or cannot use it because important parts of the workflow are missing, what have we actually learned when they don’t adopt it?
An MVP does not need to be perfect. Deliberately leaving out functionality and accepting certain limitations can be perfectly reasonable. But it should not turn into an incomplete product by accident.
Before building an MVP
Building an MVP is sometimes exactly the right approach. The problem is treating it as the default response to uncertainty (“let’s try it out”). Before anything is built, the question should be:
What are we actually trying to learn?
If an organisation wants to find out whether there is a market for a product, or how potential customers perceive certain workflows, then market research, clickable prototypes or wireframes may be the better approach.
If the question is whether customers would actually pay for the product and use it, or whether something works in a production environment, a limited pilot or an MVP may be appropriate.