How to scope an MVP without adding features you don’t need

Most MVPs don’t fail because they were built badly. They fail because too much was built too early. This is the scoping process I use with founders, drawn from 45+ web and mobile products designed over 15 years.

Every idea rests on one thing that has to be true. Find it, and the MVP becomes the smallest product that tests it. For Glimpse, a crypto treasure hunt, the risk was whether people would understand how to find and collect a drop, so the design and the tests with 8 beta users centred on exactly that.

Glimpse had four audiences wanting different things. Instead of four feature sets, everything was built around one object, the Drop: money, tokens and prizes all use the same mechanic. If an MVP seems to need a feature per audience, look for what they share.

Vytrac serves providers, clinic administrators and patients, so the scope split into a provider platform and a patient platform built from one component library. A first version needs one complete journey for one user, not half of every journey.

• Does it test the riskiest assumption? If not, it waits.
• Can the first user finish the core task without it? If yes, it waits.
• Can it be done by hand for now? Reports and approvals often can.

Keep the core small even when it’s technical. In Missed Call Assistant, the Android app only watches the call log; everything else lives on the server.

A clickable prototype of the core flow takes days and shows whether people understand it before any code is written. Bloom’s smile, mood check-in and playlist flows were prototyped and A/B tested before the final UI. Everything you cut goes on an after-launch list, where real usage decides what comes next.

A good scope fits on one page: the assumption, the user and journey, the screens it needs, what’s done by hand, and the after-launch list. See MVP design and rapid prototyping.