The art of the minimal viable feature

Product teams love to talk about MVPs. Minimal viable products. But by the time most "MVPs" ship, they're neither minimal nor particularly viable. They're bloated compromises that took too long to build.

The problem isn't the concept. It's the execution. Cutting scope is emotionally hard, and most teams aren't willing to do it ruthlessly enough.

The question that cuts through

When scoping a feature, I ask: "What's the smallest version of this that would embarrass us to ship?"

That's usually the right v1.

If it doesn't make you a little uncomfortable, you're probably over-building. You're adding things you think users want instead of shipping something and finding out.

Why minimal is hard

Every stakeholder has a "must-have" that isn't really a must-have. Every designer wants to polish that one more screen. Every engineer wants to refactor that one ugly piece of code.

These impulses are good in isolation. They make things better. But they also make things slower. And in the early stages of a feature, speed of learning beats quality of execution.

A framework for cutting

For every feature, I split requirements into three buckets:

• Must work: Without this, the feature literally doesn't function
• Should work: Makes it significantly better, but not required
• Could work: Nice to have, probably matters less than you think

Ship with only the "must work" bucket. Add "should work" in the next iteration if the data supports it. Probably never build the "could work" stuff.

Speed is a feature

Every week you spend building is a week you're not learning. Every assumption you don't test is a risk you're carrying. Shipping something small and wrong is better than shipping something big and wrong. At least small is cheap to fix.

The art of the minimal viable feature is really the art of admitting what you don't know. You don't know what users want. You don't know what will work. Ship something small, learn fast, and iterate.