What is an MVP (minimum viable product)?

Viable is the word that matters

Minimum is easy to over-index on. Teams strip a product until it's a skeleton, ship it, watch it fail, and conclude the market doesn't want it — when what the market rejected was something that didn't work.

The MVP has to actually do a job for someone. Everything else — scale, polish, automation, edge cases — is negotiable.

Manual beats thin

The best MVPs are frequently not software. Airbnb's founders photographed apartments themselves and handled bookings by hand; the learning they needed was whether strangers would sleep in each other's homes, and no amount of platform engineering would have answered that faster.

This is the concierge pattern: deliver the outcome manually, learn what the workflow really is, automate afterwards. It feels wrong to engineers and it consistently produces better information than a scaled-down v1.

Cut features, not quality

The other common error is treating MVP as licence to ship something broken. Instagram launched with a tiny feature set — photos, filters, a feed — and those few things worked beautifully. The pivot away from Burbn's bloated check-in app worked precisely because the remaining slice was excellent, not because it was small.

A minimal product that's good tells you whether people want the thing. A minimal product that's buggy tells you nothing except that people don't like bugs.

Know what you're testing

Write the question down before you build. "Will small businesses pay for automated invoice reminders?" is answerable. "Is our product good?" is not. Once the question is explicit, the minimum thing that answers it is usually much smaller than the thing you were about to build — and occasionally isn't software at all.