"MVP" has drifted from its original meaning. Ask ten teams what theirs is and most will describe a stripped-down product — fewer features, same shape. That's not a minimum viable product; it's a smaller product, and it answers a different question than the one that matters at the start.

The question an MVP should answer

A real MVP exists to test the riskiest assumption behind an idea as cheaply as possible — will people actually change their behaviour for this, will they pay, will the workflow hold up outside a demo. Everything in scope should trace back to that one assumption. Everything else, however tempting, is scope creep wearing an MVP's name.

What gets protected, what gets cut

The instinct under deadline pressure is to cut the things that feel optional — polish, edge cases, the parts that are "obviously" fine. The discipline is cutting toward the assumption being tested, even when that means shipping something that looks unfinished everywhere else. A rough MVP that answers the real question beats a polished one that answers a comfortable but irrelevant one.

Signs the thinking has slipped

  • The roadmap for "after the MVP" is longer than the plan to validate the MVP itself.
  • Nobody can say, in one sentence, what would prove the idea wrong.
  • Feedback is being collected but nothing is scheduled to change because of it.

Product & MVP thinking isn't about building less. It's about being ruthlessly honest about what you're actually trying to learn — and building only enough to learn it.