Find the core loop, then scope the MVP

Ask ten founders what their MVP is and most will hand you a shortened feature list — the full product with the expensive bits removed. That's how MVPs get bloated and prove nothing: you've built a worse version of everything instead of a real version of the one thing that matters.

I scope differently. Before I talk features, I find the core loop — the single repeatable cycle that, if it works, means the product works.

What a core loop actually is

A core loop is the smallest sequence a user repeats to get value: they do something, the product responds, and that response pulls them back to do it again. For a note app it might be capture a thought → find it later when it matters → trust the app enough to capture the next one. For a marketplace it's list something → get matched → complete a transaction → come back with the next one.

Everything else — settings, dashboards, integrations, admin — is scaffolding around the loop. Useful eventually, but none of it matters if the loop itself doesn't spin.

Scope the MVP as the smallest honest loop

Once the loop is clear, the MVP question stops being "what can we cut?" and becomes "what's the least we can build so the loop actually completes for a real person?" That reframing changes everything. Suddenly whole categories of work reveal themselves as premature — you don't need five onboarding states to prove the loop; you need one user to go around it once and want to go around it again.

An MVP scoped this way is small but not thin. It does one full circuit properly instead of ten circuits halfway. That's what makes it a test rather than a toy: a real person can complete the loop, and their behavior afterward tells you something true.

Protect the loop, defer the rest

The hardest part isn't finding the loop — it's holding the line once building starts. Every stakeholder has a favorite feature, and each request sounds reasonable in isolation. The discipline is asking one question of every proposed addition: does this make the core loop complete, or does it decorate a loop that isn't proven yet? If it's decoration, it goes on a list for later. Later is a real place. It's just not now.

Let the loop tell you what's next

The bonus of scoping this way is that a working loop is also a compass. Once real users are cycling through it, they show you — through where they slow down, drop off, or ask for more — what the next most valuable thing is. You stop guessing the roadmap and start reading it off actual behavior. That's a far better planning input than a whiteboard full of features nobody has touched.

Build the loop. Prove the loop. Then, and only then, build outward from it.

If you're trying to figure out what your product's core loop really is — or whether your current MVP is testing it or burying it — that's a good conversation to have.