The term "MVP" (Minimum Viable Product) has been abused to the point of meaninglessness. In most boardrooms, it has become a euphemism for "a half-broken product we shipped because we ran out of time."
This is not an MVP. This is technical debt with a marketing launch.
A true MVP is not about cutting corners on quality; it is about cutting scope on features to test a specific value proposition. It is a scientific instrument, designed to answer a question: "Do people want this?"
"If your MVP is embarrassing, you launched too early. If your MVP is perfect, you launched too late. The goal is 'viable', not 'minimal'."
The "Cupcake" Model
Imagine you want to build a wedding cake.
A bad MVP strategy is to give the customer a bowl of dry flour and say, "The frosting is coming in Phase 2." That isn't viable. Nobody wants dry flour.
A good MVP strategy is to give the customer a cupcake. It's small. It lacks the grandeur of a wedding cake. But it is complete. It has cake, it has frosting, and it tastes good. It proves that your recipe works.
Validating the Riskiest Assumption
Every product is built on a pile of assumptions. "People will pay for this." "People can figure out how to use this." "This solves a real pain point."
Your MVP should be designed to test the *riskiest* of these assumptions first. If you're building Uber, the risky assumption isn't "can we build a map app?" The risky assumption is "will strangers get into cars with other strangers?"
The Promise of Iteration
An MVP is a promise to your users: "This solves one problem well today, and it will solve more problems tomorrow."
If you ship an MVP and then move on to the next project without iterating, you have broken that promise. An MVP without a follow-up roadmap isn't a product; it's a prototype that accidentally went live.