A minimum viable product (MVP) is a product version or experiment that lets a team learn about an important customer or product assumption with limited effort. The minimum depends on what the team needs to learn; it does not mean removing features without a purpose. Eric Ries describes an MVP as a version that helps a team collect validated learning about customers. The original article also stresses that an MVP is not a formulaic size or feature count.
How an MVP test works
The team states an assumption, such as whether a particular group will use a service feature. It chooses the smallest credible way to test that assumption, defines what evidence would change the decision and observes the results. The experiment might use an early working product, a limited pilot or another test appropriate to the question. The next step is to learn and decide whether to change, continue or stop the direction.
Illustrative business example
Illustrative example: A facilities team believes staff need a simpler way to report maintenance issues. Before connecting every building system, it could test a limited reporting flow with a small group and review whether people can submit the information the team needs. The result would inform the next design decision; it would not prove demand across every site.
MVP, prototype and proof of concept
A prototype helps explore a product’s design or interaction. A proof of concept (PoC) tests whether a technical approach can work under stated conditions. An MVP tests a customer or product assumption and needs a way to learn from its use. These terms are used differently across organisations, so agree what question a proposed exercise is meant to answer. Read about system integration and workflow automation as product capabilities that may appear in a test.
Limits and decision quality
An MVP does not guarantee product-market fit, customer demand or a successful launch. Poorly chosen tests can give misleading evidence, and a rough experience may test usability problems rather than the underlying assumption. Define the target users, test conditions, measures and stopping decision before building. Protect participant data and avoid presenting an experimental feature as a finished service.
For a service-focused overview, see technine.io’s MVP and proof-of-concept development service.
Frequently asked questions
Does an MVP have to be a working product?
Not always. It can be an early product, a pilot or another experiment, as long as it is suitable for learning about the assumption being tested.
Is an MVP just a product with fewer features?
No. Its scope should be based on the question the team needs to test. Removing features without a learning purpose does not make a test useful.
Is an MVP the same as a proof of concept?
No. A PoC usually tests technical feasibility; an MVP is intended to learn about a customer or product assumption. One project may use both at different stages.
Primary source: Eric Ries: What Is an MVP?