"MVP" has quietly come to mean "the full product, but built faster and with less polish." That's not what the term was for, and it's the reason so many first versions take three months, cost more than planned, and still don't tell the founder anything they didn't already believe.
A real MVP is built to answer one specific question: will people actually do the thing you're betting the business on? Not "will they sign up" — signing up is nearly free. Will they come back. Will they pay. Will they change a habit for this. Everything in the build should be justified by whether it helps answer that one question, and almost nothing else should make the cut.
In practice, that means the features founders assume are non-negotiable — user accounts, a polished onboarding flow, admin tooling, a settings page, a mobile-responsive redesign of every screen — are usually not required to test the actual hypothesis. A single hardcoded account, a Slack notification instead of an admin dashboard, an ugly-but-functional core flow: all of that is fine, sometimes better, for a first version whose only job is generating a real answer.
The conversation worth having before any code gets written is blunt: what is the one behavior that, if we see it from real users, tells us this is worth continuing? Everything that doesn't serve testing that behavior gets deferred, not because it's unimportant, but because it's premature — it's optimizing a product that hasn't been validated yet.
The upside of this discipline isn't just a cheaper first version. It's a faster answer. A tightly-scoped MVP can go from kickoff to real user feedback in weeks. A "full product, but faster" MVP often takes long enough that the market question it was meant to answer has changed by the time it launches.