An MVP that nobody can actually use isn't minimal — it's incomplete. The 'viable' in MVP means it has to work, even if it does very little.
1MVP Is a Learning Vehicle, Not a Roadmap Milestone
Teams often treat 'MVP' as sprint-1 of a pre-decided roadmap — a smaller version of the final product they already committed to building. The actual purpose of an MVP is to test whether that final product is even worth building, by isolating and validating the assumption with the highest risk of being wrong.
2MVP vs. MLP (Minimum Lovable Product)
A pure MVP optimized only for learning can feel rough enough that users bounce before you learn anything, especially in consumer products where first impressions matter. The Minimum Lovable Product variant argues for shipping the smallest thing that's still delightful enough to retain a user's trust — a trade-off worth naming explicitly with your team rather than defaulting to either extreme.
3Step-by-Step Breakdown
Introduction. The most common misreading of 'MVP' is 'ship something small and half-broken.' The actual definition, from Eric Ries's Lean Startup: the version of a product that lets a team collect the maximum validated learning about customers with the least effort.
The Skateboard, Not Half a Car. Henrik Kniberg's classic illustration: if the goal is 'transportation,' a bad MVP is one wheel, then two wheels, then a car chassis (unusable until fully built). A good MVP is a skateboard — a complete, usable thing on day one that gets iteratively upgraded into a bike, then a car.
MVPs That Aren't Even Products. The riskiest assumption is often 'will anyone want this at all,' which can be tested before writing a line of product code: a landing page measuring signup interest, a 'concierge MVP' where a human manually does what the future feature would automate, or a fake-door test on a button that isn't wired up yet.
Knowledge Check. A team builds a skateboard as their MVP for a transportation app, instead of a wheel or a chassis. What principle does this demonstrate?
- →An MVP should be a complete, usable product from day one, even if simple — not a fragment of a bigger vision
- →An MVP should always be the cheapest possible thing to build, regardless of whether users can use it
Summary. Before scoping an MVP, name the single riskiest assumption you're testing. Then build the smallest usable thing that tests it — not the smallest fragment of the eventual full product.
