Cutting MVP scope without gutting the product

The wrong way to cut

Teams under deadline pressure usually cut breadth-first: half of each feature. The result is a product where every journey ends in a wall. Nobody can use it end to end, so nobody can tell you whether the idea works.

Cut along the journey instead

Pick the single most important thing a user must be able to complete. Build that path all the way through, including the unglamorous parts: errors, empty states, and what happens after success. Then stop.

Everything not on that path is a candidate for removal, no matter how obvious it seems. Settings pages, bulk actions, admin dashboards and role management are the usual suspects, and they are usually postponable.

What is never cuttable

• The success path, complete.
• Not losing user data.
• A way for users to reach you when something fails.

These three are not features. A product missing any of them cannot be tested with real users, which defeats the purpose of building an MVP.

Write down what you cut and why

Keep the list visible. Half of it will turn out to be unnecessary once real usage arrives, and the other half will now be built on evidence rather than assumption. That list is one of the more valuable artefacts of the whole phase.