The one-workflow rule for scoping an MVP

Every founder we work with has a full product vision, and almost none of that vision needs to exist in the first version. The one-workflow rule is simple to state and hard to actually follow under pressure: an MVP should prove or disprove exactly one core assumption, and every feature that doesn't serve that single workflow gets cut, no matter how important it feels in the moment.

Most product ideas rest on one load-bearing assumption: that a specific type of user will pay for a specific outcome in a specific way. Everything else, the settings page, the admin dashboard, the account management flow, is scaffolding around that one assumption. We ask founders directly: if this one thing turned out to be false, would the rest of the product matter? If not, that's the workflow to build first.

This question is deceptively simple and consistently uncomfortable, because it forces a founder to admit that most of what they've been mentally designing for months isn't actually load-bearing yet. Getting comfortable with that discomfort early saves real time later.

We usually spend the first scoping session doing nothing but this exercise, writing every feature the founder has in mind on a shared board and then testing each one against the load-bearing question one at a time. It's common for a founder to walk in with fifteen features in mind and walk out having identified that only two or three of them actually sit on the assumption being tested, with the rest quietly reclassified as things to revisit only once that assumption is confirmed.

The one-workflow rule is about scope, not craft. The single workflow you do build should work well, feel considered, and not embarrass the product in front of an early user or investor. Cutting scope to afford quality on what remains is the trade we're actually making, not cutting corners across a wider surface area.

This distinction gets lost when a founder hears "cut scope" and assumes it means cutting effort across the board. We push back on that reading directly: the whole point of narrowing to one workflow is that the same design and engineering budget that would have been spread thin across five features now goes entirely into one, which is what makes it possible to ship something that actually feels finished rather than five half-built things that each feel rushed.

Founders often want to build a settings page or a polished onboarding flow because they imagine an investor asking about it. In practice, investors care far more about evidence the core assumption holds than about peripheral polish. A working core loop with real usage data beats a fully-featured product with no users, every time we've seen this play out.

The imagined investor question is almost always a proxy for the founder's own anxiety about looking unfinished, not a real objection an investor is likely to raise. We ask founders to write down the actual question they're afraid of hearing, then ask honestly whether a real usage number would answer it better than the feature they want to add. It almost always does, and naming the fear explicitly usually deflates it faster than building the feature would have.

On a recent logistics MVP, the founders wanted payments, a ratings system, and a referral program in version one. We scoped it down to exactly one workflow: a retailer requests a pickup, a courier accepts it, both see live status. No payments, no ratings. That shipped in six weeks instead of four months, and the pilot data on that one workflow is what got the seed round moving.

The first draft of a cut list almost always produces some resistance, because every feature felt necessary when the founder first wrote it down. We've found it helps to frame each cut as "not now" rather than "never," and to keep a visible backlog of everything deferred, so the founder can see the vision is preserved, just sequenced differently than they'd originally imagined.

By the second or third project meeting after the cut, most founders stop mentioning the deferred features entirely, having redirected their attention to making the one remaining workflow genuinely good. That shift in focus is usually a better sign than any amount of upfront enthusiasm about the cut list.

For anything genuinely necessary but outside the core workflow, account settings, basic admin visibility, we often recommend a manual, unglamorous stopgap: a shared spreadsheet, a founder manually adjusting a database record, an email instead of an automated notification. It's not scalable, and it doesn't need to be yet, since the entire point of the MVP stage is learning, not operating at scale.

We've had founders resist this specifically because it feels unprofessional, manually editing a database record feels like something a real company shouldn't have to do. We push back on that instinct too: a founder personally handling twelve pickup requests a day by hand is a perfectly reasonable operating model at twelve requests a day, and building the automated version before validating that twelve requests a day is even achievable is solving a problem the business doesn't have yet.

If the remaining scope still feels slightly uncomfortable, too thin, not quite a full product, that's usually a sign you've cut correctly. An MVP that still feels complete to the founder building it almost always has scope left to cut.

We've started using this discomfort as a deliberate checkpoint rather than something to reassure founders out of. If a founder looks at the final cut list and feels fully at ease with it, we go back through it once more looking specifically for anything that snuck back in because it felt too uncomfortable to remove the first time. The workflows that actually get cut correctly tend to leave a founder slightly nervous right up until real usage data starts coming in and either validates the bet or doesn't.