Scoping an MVP down to one loop

The core idea: an MVP isn't a smaller version of the final product, it's the smallest version of the one thing that has to work for the rest to matter. We call that thing the loop: the single core action a user takes, start to finish, that proves the product's reason for existing.

The exercise, week one

1. 1 List every feature currently on the table, no filtering yet.
2. 2 For each one, ask: does this feature need to exist for the loop to complete, or does it exist to make the loop nicer? Anything in the second bucket goes on a separate list, not a deleted one.
3. 3 Draw the loop itself as a diagram, three to six steps. If it takes more than six steps to draw, the loop is still too big, keep cutting.
4. 4 What's left after that is version one. Everything on the “nicer” list becomes the version-two backlog, not a lost idea, just a delayed one.

Rising Collectively is a real example of this in practice: the MVP was built in React and Vaadin across two-week sprints, with brand identity embedded into the product from day one rather than layered on after. That pace only worked because the loop itself, connecting a seeker to a healer, stayed the fixed center of every sprint, while everything else flexed around it.

Why the cutting matters more than it sounds like it should: every feature you don't build in week one is a feature you don't have to test, debug, explain to a client, or maintain once real users start finding the edges of it. Cutting scope early isn't caution, it's speed banked for later, when you'll actually need it.