Minimum viable product
em-vee-PEE
The simplest version of a product that can be released to test a hypothesis and learn from real user feedback.
An MVP is the smallest thing you can build that tests your hypothesis. It is not a prototype. It is not a demo. It is a real product that real users can use, stripped down to the absolute essentials.
The goal of an MVP is learning, not revenue. You are testing whether people actually want what you are building. The faster you get an MVP in front of users, the faster you learn whether to iterate, pivot, or abandon the idea. Finding product-market fit starts here.
The most common MVP mistake is making it too big. 'Minimum' means minimum. If a feature is not essential for testing your core hypothesis, it does not belong in the MVP. You can always add it later. You cannot get back the time spent building features for a product nobody wanted. Once validated, the MVP evolves toward beta and eventually general availability.
Examples
A startup tests demand with a landing page MVP.
Before writing any code, the team creates a landing page describing the product and a 'Sign up for early access' button. 500 people sign up in a week. That validates demand. Now they build the product, knowing there is an audience.
An MVP is a single feature, not a product.
The product idea has 20 features planned. The MVP has one: the core action that delivers value. For a deployment tool, the MVP deploys code. No monitoring. No rollback. No team management. Just deploy. If people use it to deploy, the hypothesis is validated.
An MVP teaches the team something unexpected.
The team builds an MVP for a reporting tool. Users try it but keep asking for data exploration instead of canned reports. The MVP taught them that their assumption (users want pre-built reports) was wrong. Users want to explore data on their own.
In practice
Read more on the blog
Frequently asked questions
How long should it take to build an MVP?
Weeks, not months. If your MVP takes 6 months, it is not minimum. The goal is the fastest path to learning. Some MVPs are built in a weekend. Most should be done in 2-6 weeks. If it is taking longer, cut scope.
Should an MVP be high quality?
The core experience should work well. The user should be able to accomplish the main task without frustration. But edges can be rough: limited settings, manual processes behind the scenes, basic UI. Quality where it matters, minimum everywhere else.
Related terms
The point where a product satisfies strong market demand, evidenced by organic growth and high user retention.
A pre-release version of a product or feature made available to a limited audience for testing and feedback before general availability.
The second major version of a product or feature, typically a significant overhaul that incorporates learnings from V1.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.