Research teams that reach a working prototype often assume the next step is to build a complete product with full functionality, finished design, and production infrastructure in place. Before that happens, a different kind of test is needed.
This is because a prototype and an MVP answer different questions.
A prototype demonstrates that a technical solution works under controlled conditions. It confirms scientific or engineering feasibility, but it says nothing about whether the solution addresses a real market need.
An MVP (Minimum Viable Product) is the smallest experiment or version of a product or service that lets a team test the riskiest assumption about customer value, adoption or willingness to pay with minimal resources, producing real market evidence rather than opinions or expressions of interest.
An MVP is not a lesser, stripped-down version of the final product. It is a research tool: a way to learn about the market at the lowest possible cost before committing to expensive product development or investment decisions.
Building an MVP is not building a smaller product
In many research teams, an MVP is understood as a simplified version of the final product with fewer features, rougher design and the same target architecture.
- Does the MVP include the core features of the planned product?
- Is the underlying technology the same as in the target version?
- Does the MVP look and function like a professional product?
In commercialization, an MVP is judged differently.
- What is the riskiest assumption about the customer, the problem, or the value we want to test?
- Does the minimal version produce a credible answer, rather than just an opinion?
- Can it be built and tested faster and more cheaply than the full product?
- Will user reaction produce evidence strong enough to support the next decision?
- Can the result of the test be interpreted unambiguously, and are success and failure distinguishable?
- Who will make the decision based on the evidence collected, and by when?
- Can the MVP be tested safely and legally within ethical, regulatory and data protection constraints?
The form an MVP takes depends on the type of technology and what needs to be tested. A handful of patterns recur in practice.
Common types of MVP
| Concierge MVP | The research team delivers the result manually, without automating the technology, to check whether customers want the outcome before building a solution that delivers it on its own. This is useful when the technology itself is the most expensive part of the project and when the goal is to validate demand before investing in a scalable system. |
|
Wizard of Oz MVP |
The user interacts with an interface that appears fully automated, while the process behind it is carried out manually by the research team. This tests acceptance of the solution before investing in building the automation. |
|
Single feature MVP |
A working technology limited to one core function, tested with real users under real conditions. It requires genuine technical development but avoids building features whose value has not yet been confirmed. |
| Landing page or feasibility study MVP | A website, information material, pre-order test or paid feasibility study used to collect qualified interest, meetings, letters of intent, budget signals or advance payments before larger technology development investment begins. |
|
Single customer pilot |
A limited deployment of the technology with one industrial or institutional partner, testing how it performs under real operating conditions with contained risk and close observation by the team. |
The choice of MVP depends on which assumption is riskiest and how much it costs to build and test each version. The same technology may need different MVPs at different stages of development. A pilot is an MVP only when it tests a clearly defined assumption with a pre-agreed success and failure criterion.
What determines whether an MVP produces credible evidence?
Five conditions usually need to be met.
1. A clearly defined assumption to test
An MVP must test one specific assumption stated in advance, for example, that a defined customer segment will pay to have a specific problem solved, not general interest in the technology.
2. Representative users and conditions
The people testing the MVP must match the intended customer group, and the test conditions should reflect, as closely as practical, the situation in which the solution will actually be used.
3. A measurable success criterion set in advance
Before the MVP goes to test, the team should agree what result would confirm the assumption and what would disprove it. Without this, any outcome can be read as a success.
4. Behavior, not statements
The strongest evidence is what users actually do, for example, pay, commit team time, share data, sign a concrete next step agreement, or place an order, not what they say in a survey or conversation. Stated interest systematically overstates real willingness to buy.
5. Safety, regulatory and ethical boundaries
An MVP should reduce market uncertainty without bypassing safety, ethics, regulatory or data protection requirements. In medical, food, chemical, energy or AI applications, the minimal test may need to be non-clinical, simulated, supervised or limited to a feasibility study until the relevant approvals are in place.
An MVP is not a one-off test but a cycle: build, measure, draw conclusions, and decide on the next step: continue in the same direction, change the assumption, or end the project.
MVP and the technology TRL level
TRL 2-3: problem and demand MVP. Desk research, customer discovery, landing page tests, concierge tests or paid feasibility studies can check whether the problem is real before substantial product development begins.
TRL 4-5: value and usability MVP. Demonstrators, Wizard of Oz tests and single feature MVPs can test whether users understand the value, can use the solution and will commit resources to further testing.
TRL 6 and above: deployment and purchasing MVP. Single customer pilots, paid trials and test orders can validate integration, procurement, pricing, operational readiness and repeatability.
A good MVP does not mean the smallest possible version of the product. It means the smallest credible experiment that answers the riskiest commercialization question before the team invests time and resources in a solution nobody needs, cannot adopt or will not pay for.
