The Feature List We Cut From Every Product Before Launch, and Why

The first version of every product we've built has had more features cut from it than we ever add back later. That includes Quiz Bru, Sorted Nexus, and every product since. The list we start with is never the list we launch with, and after six products we've stopped treating that as a sign of slipping scope. It's the part of the process doing what it's supposed to do.

What's harder to explain to someone outside the two of us is which features get cut and why. It's rarely the features that took the most work to plan. It's usually the ones that sounded important right up until we had to explain, in one sentence, who they were actually for.

Before launch, every feature on the list gets asked the same question: does the product fail without this, or does it just feel incomplete without this. Those are different problems, and only the first one blocks a launch. A quiz platform that can't score answers fails without scoring. A quiz platform without a saved quiz history feels incomplete without it, but nobody's first session breaks because it's missing.

That distinction sounds obvious written down, but in the moment, everything on a feature list feels load-bearing, because we thought of a reason to want it. The test forces the actual question: is this reason strong enough that the product doesn't work at all without it, or is it a reason to add this later once we know real users actually want it.

Quiz Bru launched without team-based scoring, custom branding on the join screen, or a library of pre-built quiz templates. All three were on the original plan. All three came back later, once hosts using the product told us which one they actually missed, instead of us guessing which one they'd want before a single quiz had been run.

Sorted Nexus launched with quotes and invoices and nothing else, despite the plan for it always being a full business admin toolkit. Cash flow tracking, the feature that ended up mattering most to the people using it, wasn't in the launch version at all. We'd rather ship the two features we were certain about and prove those work, than ship five features at once and not know which of them is actually carrying the product.

The pattern repeats on every product: the feature that survives the cut is the one the product can't function without, and the feature that gets deferred is the one that would be nice to have an opinion about once real usage tells us what people actually do with the thing.

Cutting a feature feels like reducing your odds of success, which is exactly backwards from how we'd naturally think about risk. Our instinct, the one we've had to actively correct for, is that more features mean a more complete product, and a more complete product means a safer launch. In practice the opposite is true: every feature you add before launch is a feature you're guessing is worth building, and a guess you haven't tested yet is itself a risk, not a hedge against one.

The actual safer move is shipping the smallest version that can fail or succeed on its own terms, because that's the version that tells you something real. A five-feature launch that flops tells you almost nothing about which feature was the problem. A two-feature launch that flops tells you exactly what to fix or abandon next.

Cut doesn't mean discarded. Every feature we take off a launch list goes into that product's own backlog, the same way this site tracks its own article topics, and it gets revisited once we have actual usage data instead of a guess. Team scoring came back to Quiz Bru because hosts asked for it directly, not because it had been sitting on a list since day one waiting for its turn.

That ordering matters more than it looks like it should. Building a feature because a real user asked for it after using the product is a fundamentally different bet than building it because it seemed reasonable during planning. The first is informed by evidence. The second is informed by our own guess about what evidence will eventually show, and we've been wrong about that guess often enough to stop trusting it by default.

This is often the single most useful thing we do in a technical consulting engagement: help a founder or team separate what a product needs to launch from what it needs to eventually become. Most teams we review haven't drawn that line themselves, and the launch date keeps moving because the list keeps growing instead of narrowing.

The question we ask clients is the same one we ask ourselves: if you cut this feature today, does the product stop working, or does it just stop being the product you eventually want it to be. Only the first answer belongs before launch. If you're weighing your own launch scope and want a second opinion on where that line sits, that's exactly what our services page is set up to help with.

None of our products launched as the product we originally planned, and none of them are worse for it. The features that made it back in later did so with real evidence behind them, which is a better foundation than any amount of upfront planning could have given them. The list we cut before launch isn't a record of what we failed to build in time. It's a record of what we correctly chose not to guess about yet.

If you're staring at a launch list that keeps growing instead of shrinking, that's usually a sign the test isn't being applied yet, not a sign the product genuinely needs everything on it. We'd rather help you find that out before launch than after, and you can reach us through our contact page if you want to talk it through.