Cut your MVP to one flow

Two numbers from two unrelated studies describe the same mistake. CB Insights analysed VC-backed startups that shut down since 2023 and found that 43% cited poor product-market fit. Pendo analysed feature usage across its customers' products and found that 80% of features are rarely or never used.

Put them together: most products that fail did not fail for lack of features. They built plenty. They built the wrong ones, or they built so many that nobody could tell which one mattered. The cut I make on every MVP sprint comes straight from this.

What "one flow" means

A flow is the shortest path from a new user to the result your product promises. Sign up, do the core action, see the result. For an invoicing tool: create an invoice, send it, see it paid. For an AI research assistant: paste a question, get a sourced answer, save it. Three or four screens, no settings, no dashboard, no integrations.

If people complete that flow and come back, you have evidence. If they do not, no amount of additional features would have saved it, and you have saved the months you would have spent building them.

What gets cut, and why it is fine

• Settings and preferences. Defaults are a product decision. Make them well and nobody asks for the settings page.
• A dashboard. You do not have enough data for one yet, and users do not need it to get the core result.
• Integrations. Each one is a week. Build the one that the core flow cannot work without, if any, and no others.
• Team features, roles, permissions. The first users are individuals. Teams come after demand is proven.
• A second user type. Two-sided products need one side working first. Pick the side that pays.

Y Combinator says the same thing

Michael Seibel's advice to startup school founders is to launch quickly and build the simplest version that lets you learn from real users, rather than the fullest version you can imagine. The reasoning is the same as the numbers above: the thing you learn from the first flow changes what you build next, so anything built before that learning is a guess.

How I run it

My MVP sprint is fixed at $3,000 and three weeks, and the reason I can fix both is that the scope is one flow. Week one is design: the flow on paper, then clickable, with the cuts agreed in writing. Week two is the build. Week three is edge cases, deployment and handover. New scope gets quoted separately rather than squeezed in, because squeezing it in is how the one flow becomes four and the deadline becomes a quarter.

What happens after the flow works

The feature requests that arrive after launch are different from the ones you imagined before it. They come from people who used the thing and hit a wall. That list is worth more than the one you wrote on day one, and it is the list the next sprint is built from.