The three scope decisions that determine whether your MVP ships

Decision one: which user, exactly

An MVP serving three user types is three products. Pick the single user whose problem is most urgent and whose behaviour you can observe. Everything else waits. This is the decision teams resist most, and it is the one that most reliably determines whether the build finishes on schedule.

Decision two: what evidence you need

Define, before building, what result would justify further investment and what result would mean stopping. Without this, every launch produces the same conclusion — 'promising, needs more features' — and the product never faces a real decision point.

Decision three: what you will not build

Write the exclusions down and share them. Admin dashboards, granular permissions, billing tiers, integrations 'we will need eventually' and internationalisation are the usual candidates. Each is defensible on its own; together they add months. Something crude and manual behind the scenes is almost always acceptable at this stage.

Instrument from the first release

Ship analytics with version one. If you cannot see activation, retention and the drop-off in the core flow, the launch will produce opinions instead of data — and opinions are exactly what an MVP was supposed to replace.