An MVP is a strategy, not a destination.
1The Skateboard Metaphor
If you want to build a car, don't build a wheel, then an axle, then a body. Build a skateboard, then a scooter, then a bike, then a car. Each step is a complete, usable product that teaches you something about transport.
2Concierge & Wizard of Oz
You don't always need code. A 'Concierge' MVP is when you perform the service manually. A 'Wizard of Oz' MVP is when the user thinks it's automated, but a human is doing the work behind the scenes.
3The Feedback Loop
Build - Measure - Learn. The faster you can complete this loop, the faster your product will find success. The MVP is just the first 'Build' in a never-ending cycle of improvement.
4Step-by-Step Breakdown
The MVP is NOT the smallest version of your final product. It is a process of testing your most critical business assumptions with the least amount of work.
Viable means it must actually solve a problem. A car's MVP isn't a single wheel (not viable); it's a skateboard (viable for transport, even if simple).
The goal of an MVP is Learning, not Profit. Every feature you add to an MVP should be designed to answer a specific question: 'Do users actually want X?'.
What is the primary purpose of building an MVP?
- →To start making money as fast as possible
- →To prove your engineering skills to the world
- →To collect maximum validated learning about customers with the least effort
- →To have a finished product to show at a tech conference
What is the 'Minimum Lovable Product' (MLP) concept?
- →A product that is so small it fits in your pocket
- →A product that focuses not just on functionality, but also on a delightful user experience to build emotional connection from day one
- →A product designed only for pets
- →A product that costs nothing to build
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Don't Cut Accessibility to Hit 'Minimum'
Teams under pressure to ship a lean MVP sometimes treat accessibility as a 'nice to have' cut alongside real scope. Basic accessibility (labeled form fields, keyboard operability, sufficient color contrast) costs little extra effort even in a stripped-down build and prevents excluding real users from your very first learning cycle.
<!-- Even a bare-bones MVP form should keep this -->
<label for="email">Email</label>
<input id="email" type="email" required />SEO Implications
- 1
MVP Landing Pages Still Need Basic SEO Hygiene
An MVP is often validated through a simple landing page before the product exists. Even a 'fake door' test page should have a proper title tag, meta description, and a single clear heading — otherwise you're relying entirely on paid or direct traffic to validate demand, which skews your learning.
Best Practices
Define the Riskiest Assumption First
Before scoping the MVP, list your assumptions and rank them by risk and uncertainty. Build only enough to test the riskiest one — everything else can wait until that assumption is validated.
Set a Learning Deadline, Not Just a Feature List
An MVP should have a decision date attached ('by this date we'll have enough data to decide whether to invest further'), not just a list of features to ship. Without a deadline, an MVP quietly turns into version 1.
Frequent Bugs
The 'MVP' quietly grows scope during development because every stakeholder adds 'just one more thing', and it ships months later as a full product with no early learning.
Freeze scope in writing before development starts and route every new request to a 'v2 backlog' — if it's not needed to test the core assumption, it doesn't belong in the MVP.
Real-World Examples
The Concierge MVP for a Meal-Kit Startup
Before building an ordering platform, a meal-kit founder manually sources ingredients and hand-delivers boxes to the first 20 customers to validate that people would actually pay for the service.
// MVP validation plan
{
assumption: 'Customers will pay $60/week for curated meal kits',
method: 'concierge', // manual fulfillment, no automated platform
successCriteria: '15 of 20 customers renew for a second week',
buildRealPlatform: false // only build after assumption is validated
}