Minimum Viable Product (MVP)

What is a Minimum Viable Product (MVP)?

A minimum viable product is the smallest release that lets you test your riskiest assumption with real users. The term was popularized by Eric Ries through the lean startup methodology, and its core insight is easy to miss: an MVP is primarily a learning tool, not a small product. You build it to answer a question ("will anyone pay for this?", "will people change their workflow for this?") with the least possible time and money at risk.

In practice, an MVP can be far smaller than founders expect. A landing page with a waitlist, a concierge service where you do the work manually behind the scenes, or a single-feature app can all qualify. What makes it viable is that a real user can get real value from it, and what makes it minimum is that you cut everything that does not help you learn.

Day to day, working MVP-style means shipping in weeks instead of quarters, talking to every early user, and treating each release as an experiment with a hypothesis attached.

Why an MVP matters for startups

For a team of one to five people, the MVP is a survival tactic. Every month spent building unvalidated features is a month of runway spent on a guess. Shipping early converts guesses into evidence: you find out whether the problem is real, whether your solution fits, and whether people will pay, while you still have the time and cash to change course or pivot.

The MVP also changes team dynamics. Instead of debating opinions internally, you settle arguments with user behavior. That habit of customer validation is worth more than the first release itself, because it compounds across every future decision.

MVP vs minimum lovable product

The MVP has a well-known cousin: the minimum lovable product. The MVP asks "will people use this at all?" The MLP asks "will people love this enough to tell others?" If you are first to a problem, viable is usually enough to learn. If you are entering a crowded market where users already have alternatives, a rough MVP may fail not because the idea is bad but because the experience is forgettable. Choose the bar based on how much competition your first users can compare you against.

MVP in practice

Imagine you want to build software that generates invoices from calendar events for consultants. Instead of building the app, you spend one week on a signup page describing the product, then manually create invoices for the first 10 people who join, using their calendar exports and a spreadsheet. Each invoice takes you 20 minutes. Within three weeks you learn that consultants happily pay $19 per month, but only if invoices sync to their accounting tool, a requirement you would not have prioritized. You build the automated version around that insight, and your first paid release lands with eight of those 10 manual users converting.

Common mistakes

• Building a small product instead of an experiment. An MVP without a clear hypothesis is just an underpowered app. Write down what you are testing and what result would change your mind.
• Making it too minimal to be viable. If users cannot complete one real task end to end, you learn nothing except that broken products frustrate people.
• Letting the MVP quietly grow. Scope expands one "small addition" at a time until launch slips by months. Guard against feature creep with a hard cut list.
• Ignoring the data you collected. Founders sometimes ship an MVP, see weak signals, and keep building anyway. The point of cheap learning is to act on it.

Related concepts

The MVP is the first step on the road to product-market fit, and it works best inside a disciplined build-measure-learn loop. For deeper background, the Wikipedia article on minimum viable products covers the history of the concept and its main variations.