How to define an MVP before you start development

Most early product failure does not come from bad engineering. It comes from building the wrong version of the right idea — too much surface, too many roles, too many integrations, too much polish before anyone has confirmed the problem is real.

An MVP is not the smallest possible product. It is the smallest deliberate slice that gives a real user a useful outcome and gives the team a real signal.

The answer: scope an MVP around one outcome

Before any framework chooses you, decide what single outcome the first version has to make possible. Everything else either supports that outcome or gets removed.

A delivery pattern that works

Run a short discovery to produce a product context summary, MVP boundary, risk map, and architecture direction. Then specify the MVP as documentation and contracts before writing implementation code — AI-assisted delivery becomes much more useful once that scaffolding exists.

Mistakes to avoid

• Treating the MVP as version 1.0 of the eventual product.
• Listing features instead of outcomes.
• Designing for three personas at once.
• Adding integrations to look complete instead of to enable the outcome.
• Skipping discovery because the idea 'feels obvious'.