Short answer: An MVP is the smallest version of a product that validates the single riskiest assumption with real users. It isn't a beta, it isn't a prototype, and it isn't 'version one with most of the features'. The four useful kinds are landing-page, concierge, wizard-of-oz, and single-feature. Pick the cheapest one that answers the question. Most teams ship an MVP that's too big and learn nothing they couldn't have learned with a landing page.
An MVP -minimum viable product- is a version of your product that enables you to validate your riskiest assumption with real users. The first definition was coined by Frank Robinson in 2001 and popularised by Eric Ries in The Lean Startup. It is now a word every startup uses and most startups misuses. Martin Fowler's working definition is worth reading if you want a tighter frame than the one most teams use.
This guide aims to reduce the likelihood of misusing significance assignments. You’ll learn what a real MVP is and what it isn’t. We’ll also discuss the 4 types of MVPs that do ship and how to choose one well. Finally, we’ll cover the failure modes that stretch a 1 week MVP into a 6 month build. The audience for this article comprises founders, anchors, and engineers trying to get the most out of the term “MVP” on a whiteboard.
What an MVP is, and isn't
An MVP is essentially a version of a product that will enable you to decide whether your riskiest underlying assumption is right. In other words, an MVP delivers a new insight. For example, we now know that this customer segment is willing to pay that price for this solution.
What an MVP Is Not.
- Not version one of the real product. A "scaled-back" version of your eventual product isn't an MVP unless it's small enough to ship in days, not months. If it takes a quarter to build, it's a beta, not an MVP.
- Not a prototype. A prototype validates that something is technically possible. An MVP validates that something is wanted. Different question, different artifact.
- Not a way to "release something to start getting users". Releasing for the sake of releasing isn't an MVP. The MVP exists to answer a specific question, not to generate vanity activity.
- Not "the smallest version of every feature". Most teams that try to ship "lean versions of all five features" end up with five half-features, none of which validate anything. The MVP is one feature, not five small ones.
The effective mental model: spot the most critical assumption your product relies on and create the simplest product that can verify or discard that assumption. Everything else can wait till later. A product design sprint can fast-track that test when the assumption is around user behaviour rather than build feasibility.
The single riskiest assumption test
Here’s a proposition of every product idea: the product idea rests on a stack of assumptions. The MVP is designed to test the assumption which, if proven false, nullifies the whole idea.
For an average software product, the candidate assumptions are usually
- Demand: people will want this thing.
- Willingness to pay: they'll pay actual money for it.
- Behaviour: they'll change how they currently work to use it.
- Distribution: we can reach the people we need to reach.
- Technical feasibility: we can build this with reasonable effort.
Because engineers are involved early on, most startups reach for technical feasibility ("can we build this?"). Technical feasibility is seldom the most risky assumption. Practically everything can be built; the main question is if someone wants it. Willingness to pay demands and generally takes place this risky step.
List down roughly five beliefs that your product is predicated on. Organize in order of “If this wrong the entire thing is dead” The primary item is what you should test for your MVP. If you don’t test the top assumption, you’re procrastinating.
The four kinds of MVP
Below are four parent shapes of MVP. They map closely to Atlassian's MVP playbook but compress better in practice. Select the most affordable option that can address the query.
**1. A minimal viable product for the landing page comprises a single page merely containing a description of the product and a sign up form. Execute a modest advertising campaign for it. Track conversions When 200 strangers see the page and 1 signs up, demand is weak. If 200 strangers view it and 40 sign up, then it is real demand. The total time taken for the build: a day or sometimes less. The right MVP when demand is our top assumption. Many teams skip this step and waste a month learning what the landing page would have taught in a week.
2. Concierge MVP. The end-to-end service must be delivered manually for at least one customer (or a small number of customers), without building any software. You are the Algorithm. A concierge MVP for a “logistics SaaS” is a founder driving a van and texting status updates from their phone. This MVP is well-aligned with the top assumption being behavior, meaning will they actually use and pay for this service in spite of the crude delivery?
**3. A wizard-of-Oz MVP is a product that, though not yet automated, looks automated to the user. The Stage. A founders’ classic is as the early version of Zappos the founders would get photographs of shoes at local shoe stores, post them online, and then physically buy and ship the ones that sold. The user perceived it as an e-commerce site, but it consisted of a guy and a credit card. If the top assumption of your system is value of automated experience and the aim of the MVP is not to build the automation yet, this is the right MVP.
**4. One-feature MVP. Develop only the one characteristic that is essential to the product’s value proposition. Discard authentication, settings, dashboards, social sharing, and others. According to reports, Pivotal Tracker was first released with a single shared backlog along with a velocity calculation. No projects. No admin panel. No user management. You are trained on data up to October 2023.
The ranking starts from the landing page, which is the cheapest, and goes up to the single-feature page, which is the priciest.page. Select the most inexpensive option that addresses your main assumption. Avoid rushing your decision just because the less expensive option “does not feel complex enough”. The one that functions is cheaper.
How to ship an MVP without trapping yourself in scope creep
After selecting an MVP, it’s common to hear “but we should also have…” which is the cram-features-in failure mode most teams fall into. There are three rules to stop this.
Articulate the acceptance criteria in the definition of done before work begins An MVP is something that a stranger should be able to sign up for, do X, and we should be able to measure whether they did it or not. If your criterion uses the word ‘also’ anywhere, then you have already lost the discipline.
Set a timeline for your tests, one you can’t push back. A single-feature MVP completed in six weeks. When the time box is out and MVP is not shipped, ask why and don’t extend. Almost always "we scoper-crept". The fix? Cut, not add time.
Every feature request will get the same answer until the MVP has shipped and a real user has touched it. It gets a ‘good idea, in the icebox’ each time. Only once you've generated a user will the MVP generate good feature ideas. Refer to the project management ground rules for additional information on this topic.
Teams that observe these 3 rules ship MVPs in days or weeks and learn from it. Teams that fail to deliver functionally indistinguishable “MVPs” from first releases 6 months in, learn nothing. There is a useful case study in iterating lean reviews that shows the difference in practice.
What happens after the MVP
The Minimal Viable Product will not be final. The purpose of the job is to answer the question, not to be the product.
Once the MVP is released, there are three possibilities.
- The assumption is validated. The thing works. Customers respond. Now the team has earned the right to build the real product. The MVP code is usually thrown away or heavily rebuilt.
- The assumption is invalidated. Nobody signs up. Nobody pays. The concierge service ends after three customers don't repeat. The MVP did its job; the team saved the cost of a real build. Kill the idea, or pivot to a different assumption.
- The result is ambiguous. Some signal, not enough to act on. This is the most common outcome and the trickiest. The temptation is to "build more and see"; the better move is usually to run another MVP that resolves the ambiguity rather than committing to a real build with weak evidence.
When a team perceives the MVP as the actual launch of a product rather than just an experiment, they lose most of the value in determining the MVP in the first place. The discipline is to be willing to throw away the addendum.
When you don't need an MVP
MVPs serve new product builds when the most uncertain is unknown. They're not always the ones to use.
- Refactoring or rebuilding an existing product. The assumptions are already validated by the existing customers. An MVP of "the same product but rewritten in a different framework" answers no new question. Just build it.
- Regulated industries with high compliance overhead. A medical-device MVP that bypasses regulatory review isn't an MVP, it's a lawsuit. In these contexts the "minimum" is whatever the regulator says.
- Internal tools for a known team. When your customer is your own team, you can ask them. You don't need an MVP to find out whether your colleagues want a feature. Skip the experiment and build the thing.
- Mature product categories with strong competitive benchmarks. If you're building the fifteenth project management tool, demand is established. The risk is differentiation, not existence. An MVP is the wrong frame; competitive positioning is the right one.
As a tracking company, we express this opinion. LiteTracker is not a project management MVP but an incisive opinion in a mature category. The product's purpose is to assist teams that already understand that velocity is not the goal and that accepted-stories-only counting is what actually moves the work forward. A minimum viable product (MVP) wouldn't have helped us discover this we already know. This is worth it.
Frequently asked
What is an MVP in software?
A minimum viable product, or MVP, is a version of the software product which minimises one of the riskiest assumptions and tests it with real users. It doesn’t matter which feature it is; it simply matters to get a clear yes-no answer to a question.
What's the difference between an MVP and a prototype?
The prototype checks whether something can be made. A minimum viable product tests desirability. A prototype is for the team; an MVP is for the users. It may have a different question.
Is an MVP the same as a beta?
No A beta is an early version of what will become the final product. It’s released to a limited audience to find bugs, and is usually used by the engineering team to test the system. An MVP is an experimental artifact that is expected to confirm one specific assumption. They are often not based on the final product at all and may even be discarded post-delivery.
How long should it take to build an MVP?
Landing page or concierge MVP: a few days to two weeks. A wizard-of-Oz MVP can be ready in 2 to 4 weeks. A single-feature MVP should take six to eight weeks. If your minimum viable product, or MVP, is taking three months, it’s most likely not at MVP. It’s just a version of your product, a small version. And it’s going to have all the same scope problems.
What are examples of famous MVPs?
A landing page that rented out the founder's apartment was Airbnb. Dropbox began as a video demonstration of the operation of its product. Zappos was originally set up as a wizard-of-oz e-commerce site to buy shoes from stores. All three answered demand-side questions with the lowest cost artifact.
What's the biggest MVP mistake?
Overengineering Many teams that claim to be doing an MVP build something which is in essence a smaller version of the real thing – five features instead of fifteen – and learn nothing they couldn't have learned with a landing page. The goal is to choose the least costly experiment, not the miniature product.
Should an MVP have polish?
Adequate refinement for credibility, insufficient refinement for expenses. A landing page must look professional but an MVP product must not look like the final design. If you over-polish your MVP, it suggests you have already committed to the build and not testing the assumption.
When should you skip the MVP step?
When the most uncertain assumption is already tested low risk for instance, refactoring, internal tools, regulated industries, mature competitive categories. The purpose of an MVP is to explore a certain question. If you already know the answer then MVP is waste.
Still stuck
As long as a team has the success criteria in a paragraph, two weeks time-boxed and a rule against adding extra features until the first one ships, it is a correct MVP. The rest of this article is about the future version. This one is mostly “ship sooner and learn faster”.
If you're looking for a tool to maintain the MVP backlog as a single ordered list, block scope creep by freezing commitment to a sprint, and track accepted stories (not finished), LiteTracker does just that. You can use it free of charge and with unlimited users. Its import takes around a minute. We recommend you save your money and don’t use us if you are a solo founder, still validating the idea on a landing page. It is meant for a moment when demand is valid.
In any case, select the most affordable experiment. Release it. If it doesn’t work, lose it.