Scoping an MVP Without Cutting the Wrong Corners

"Minimum viable product" gets treated like a size setting - just make everything smaller. In practice, most MVPs that struggle didn't fail because they were too big; they failed because the wrong things got cut. The features that survive the scoping conversation are usually the ones easiest to build, not the ones that actually validate whether anyone wants the product.

Separate "viable" from "minimum"

Minimum answers "how little can we build." Viable answers "will anyone act on it." Scope every feature against viable first - does removing this feature change whether a real user can complete the core job they came to do - and only then optimize for minimum within what's left. Most scope creep comes from skipping straight to minimum without agreeing on what viable even means.

One core job, not three half-jobs

The MVPs that give you a clean signal do exactly one job well end to end, rather than three jobs done at 40%. If your MVP list has more than one "and" in the value proposition, something needs to come out - not because the other job doesn't matter, but because a diluted MVP produces diluted, hard-to-interpret feedback.

Cut features, not quality on what stays

The corner that should never get cut is reliability on the features you do ship. A janky version of three features reads to users as "this product is broken." A polished version of one feature reads as "this team knows what they're doing, even if they haven't built everything yet." The second impression is the one that earns you a second look.

Decide the kill criteria before you launch

Write down, before launch, what result would make you kill or pivot the idea - not after you see the numbers and start rationalizing them. An MVP without a pre-committed kill criterion isn't really a test; it's just a first version you're emotionally attached to defending.