An MVP fails at its job when it either ships too little to learn anything, or too much to ship on time. The scoping conversation is where that gets decided, well before anyone writes code.
Define the one thing you’re trying to prove
Every MVP should be built to answer a specific question: will people use this, will they pay for it, does this workflow actually save time. Every feature that doesn’t help answer that question is a candidate to cut, no matter how reasonable it sounds in isolation.
Cut features, not quality
Scope down by removing entire features, not by building every feature halfway. A product with three things that work well tests better, and looks more credible to early users, than one with ten things that are all slightly broken.
The releases that prove an idea fastest are usually smaller than founders expect going in. That’s a feature of a good MVP process, not a compromise.
