The one workflow test: how we decide what's actually in an MVP

Every MVP scoping conversation eventually hits the same moment: someone suggests a feature that's genuinely useful, technically easy to add, and has nothing to do with the assumption the MVP is actually supposed to test. Saying yes to that feature feels harmless in isolation. Said yes to twenty times, it's how a six-week MVP becomes a five-month build that still hasn't validated anything.

We've watched this happen to founders who were otherwise disciplined about everything else in the business. The scope creep rarely arrives as a single bad decision. It arrives as fifteen individually reasonable ones, each argued for on its own merits without anyone stepping back to ask whether the growing list still fits inside what an MVP is actually for.

We start every MVP engagement by writing down, in one sentence, the single workflow the product needs to prove works: a retailer requesting a pickup and a courier accepting it, for example, not the twelve other things a logistics platform will eventually need to do. Everything in the scope document gets checked against that sentence. If a feature doesn't touch it, it's a version-two conversation.

This sentence has to survive being read back to the client cold, weeks later, without context. If it still sounds obviously right, it's specific enough to actually filter scope decisions. If it needs a paragraph of explanation to make sense, it's too broad to do the job, and we push the client to narrow it further before writing a single line of the scope document itself.

The features that derail MVP scope are rarely the hard ones, those get cut by default. It's the easy ones: a settings page, an admin dashboard, a second user role, each maybe a day or two of work. A day here and there doesn't feel like scope creep. Add up fifteen of them and the MVP has quietly doubled in timeline without getting any closer to answering the question it was built to answer.

The psychology behind this is worth naming directly, because it keeps recurring across nearly every client we work with. "It's only a day" is true of each individual request and false of the pattern. Nobody budgets time for the pattern, because the pattern doesn't show up as a line item, it shows up as a launch date that keeps slipping by increments too small for anyone to point to a single cause.

A logistics client wanted an in-app messaging system between retailers and couriers in version one, reasoning that couriers would need to coordinate pickup timing. It was a genuinely useful feature and not a hard one to build. It also had nothing to do with the one workflow being tested: whether retailers would actually use the app to request a pickup at all.

We shipped version one with a phone number displayed on the pickup confirmation screen instead, a solution that took an afternoon rather than two weeks. Once real retailers were using the app, it turned out fewer than one in ten pickups needed any coordination beyond the confirmation screen itself, and the ones that did were handled fine by a phone call. The messaging feature, when it eventually got built for version two, looked different from what anyone would have specified up front, because it was designed around what real usage actually showed rather than a guess made in a planning room.

Almost every feature suggested in an MVP planning session is useful in the abstract. That's a low bar and not the right one. The question that actually filters scope is narrower: if this feature didn't exist, would the MVP fail to answer the question it's built to answer? For the pickup-and-courier workflow, a messaging system doesn't meet that bar. A working notification when a courier accepts a job does, because without it the core workflow doesn't actually function end to end.

Reframing the question this way turns a subjective argument about usefulness into something closer to a checklist, and it's a lot easier for a founder to accept a cut when the reasoning is that specific rather than a general appeal to staying lean.

We don't throw cut ideas away, we log them in a version-two backlog the client can see, which makes the cut easier to accept because it's clearly a "not yet" rather than a "no." Most of those ideas turn out to matter a lot less once real users interact with the core workflow, because the actual friction points are rarely the ones anyone predicted in the planning room.

Revisiting that backlog after the MVP has real usage data is one of the more useful exercises we run with clients. Ideas that felt essential in the planning phase frequently drop off the list entirely once actual user behavior is available to check them against, and new ones that nobody thought to suggest up front rise to the top instead.

Founders sometimes worry that this kind of discipline makes them sound negative in front of their own team, always the person shooting down ideas in the planning meeting. The framing that works better in practice is asking the team to write every idea into the version-two backlog themselves, in real time, during the same meeting it comes up in. That keeps the meeting feeling generative rather than restrictive, and it's the same list we come back to once the MVP has real usage data to check the ideas against.

The discipline here isn't about being stingy with scope for its own sake. It's about protecting the one thing an MVP is actually for: getting a real answer to a real question as fast as possible, before the budget and the timeline get consumed by features that were never going to change that answer either way.