The one-feature test: how we decide what's actually in scope for an MVP

Nearly every MVP scoping conversation starts with a founder describing a product that's really three or four products stitched together, each one worth testing separately. The test we run to cut that down is simple to state and uncomfortable to apply: if you could only prove one assumption with this build, which one actually determines whether the business works. Everything that doesn't serve that single assumption gets cut, no matter how core it feels to the eventual product.

We run this test in the very first scoping call now, before any wireframes or technical discussion, specifically because it's much easier to have this conversation before anyone has fallen in love with a specific feature list. Once a founder has seen a mockup of the full vision, cutting from it feels like a loss. Before that mockup exists, cutting from a list of ideas feels like focus.

The resistance is rarely about the feature itself. It's that cutting a feature feels like admitting the vision is smaller than it is, when actually the opposite is true: a founder who can articulate the one assumption that matters most has a clearer vision than one who wants to build everything at once and hope something sticks. We've had this conversation with founders who came in wanting a full marketplace, two-sided matching, payments, and reviews, and left with a single-sided waitlist that answered the actual open question: does anyone want this at all.

The founders who adjust fastest are usually the ones who've already been burned once, either by a previous product that took too long to launch or by watching a competitor ship a thinner version faster and learn more from it. First-time founders take longer to trust the cut, which is understandable and exactly why we spend real time on the reasoning rather than just handing down a recommendation.

Ask what would make you shut the idea down. Not what would make you excited, what would make you walk away. If nobody signs up for a waitlist in two weeks, is that a signal to stop, or would you keep going anyway because you already believe the thing you're testing? If the answer is you'd keep going regardless, you haven't found the real assumption yet, you've found something you're not actually testing.

This question routinely surfaces a second, more honest assumption underneath the one a founder originally described. A founder who says they're testing "whether people want same-day delivery" often, under this question, reveals they actually believe that already and are really testing something narrower: whether they personally can operate the matching logistics profitably. Those are different tests requiring different MVPs, and only one of them is usually the real bottleneck.

The features that almost always get cut from a first MVP: payments (a waitlist or a manual invoice tests willingness to pay just as well for a first cohort), user accounts beyond the minimum needed to use the core workflow, admin dashboards for internal team use (a spreadsheet works fine for the first 50 users), and anything described as "eventually we'll need." Eventually is not now, and now is the only thing an MVP budget should be spent on.

We keep a running "parking lot" document for every project listing everything cut and the reasoning behind each cut, specifically so a founder doesn't feel like good ideas are being discarded, just deferred with a clear trigger for when they'd actually get built. That document has become one of the more reassuring artifacts we hand over, since it turns a scary-feeling cut into a visible, honest plan.

The one workflow that tests the core assumption gets built properly, not as a prototype held together with tape. If the assumption is that local retailers will pay for same-day delivery matching, that specific matching flow needs to actually work end to end, reliably, because a broken core flow doesn't just fail to prove the assumption, it actively disproves something that might have been true with a working version.

We treat this one workflow with the same engineering rigor we'd apply to a much larger product, proper error handling, real testing, a design that doesn't feel obviously unfinished, because a flaky core experience contaminates the entire test. A user who hits a bug in the one thing the MVP exists to prove doesn't file a detailed bug report, they just conclude the product doesn't work and leave, and that response gets read as a failed test even when it wasn't really testing the actual idea.

Applying this test typically cuts a founder's initial feature list by 60 to 70 percent, and cuts build timelines from four or five months down to six to eight weeks. More importantly, it produces a test that actually tests something, instead of a half-built version of everything that takes too long to launch and doesn't cleanly prove or disprove anything when it finally does.

The timeline compression matters for reasons beyond cost. A founder who gets a real answer in eight weeks instead of five months has four extra months of runway left over to act on whatever that answer turns out to be, whether that's raising on stronger signal or redirecting the idea before more money is spent chasing the wrong version of it.

The one-feature test only works if the founder is honest about what they'd actually do with a negative result. We've had founders name a clear assumption, watch the MVP disprove it, and then keep building anyway because they'd already emotionally committed to the idea regardless of what the test showed. That's not a failure of the test, it's a sign the test was never really being run as a test in the first place, just as a formality on the way to a decision that had already been made.

We ask about this directly before scoping starts now: if this specific assumption turns out false, what do you actually do next? A founder who can answer that concretely, even if the answer is uncomfortable, is genuinely testing something. A founder who can't or won't answer it is building a product, not running an experiment, and we scope the conversation differently once we know which one we're actually in.