Get your free personalized podcast brief

We scan new podcasts and send you the top 5 insights daily.

The question itself reveals a systemic failure. The real problem isn't the feature, but a lack of upfront validation and product discipline before the feature was ever built. The focus should be on pre-build evidence, not post-build justification.

Related Insights

The goal of early validation is not to confirm your genius, but to risk being proven wrong before committing resources. Negative feedback is a valuable outcome that prevents building the wrong product. It often reveals that the real opportunity is "a degree to the left" of the original idea.

Instead of forcing yourself to complete every planned feature, treat decision fatigue as a signal. If you consistently let a feature "die on the vine" because you lack the energy for it, it's likely not a priority for you or the market. This reframes a negative feeling into a useful prioritization tool.

Evaluating a feature based on a single customer request is a trap. You must zoom out to the portfolio level to understand its strategic fit, opportunity cost, and financial implications. A feature that makes sense in a vacuum can be absurd in the context of the entire product strategy.

Avoid the paralysis of a "kill list" by managing features through a defined lifecycle. Every feature should be in an active phase: 'Exploring' (testing), 'Exploiting' (scaling), or 'Sunsetting' (managed decline). A feature you can't place in a phase is in limbo and draining resources.

Early demos shouldn't be used to ask, "Did we build the right thing?" Instead, present them to customers to test your core assumptions and ask, "Did we understand your problem correctly?" This reframes feedback, focusing on the root cause before investing heavily in a specific solution.

Don't wait for post-launch metrics to validate an idea. The essential evidence for whether to build something is gathered through direct, face-to-face conversations with users about their problems. This pre-build signal is far more reliable than any data collected after shipping.

Many founders become too attached to what they've built. The ability to unemotionally kill products that aren't working—even core parts of the business—is a superpower. This prevents wasting resources and allows for the rapid pivots necessary to find true product-market fit.

Actively killing or investing in a feature has clear outcomes. The most damaging path is perpetual limbo where a feature is left "in pilot" or "gathering data" indefinitely. This passive indecision consumes ongoing maintenance effort and opportunity cost without resolution.

If you have to ask whether your product is an 'A', it’s not. Many founders persist with 'B+' ideas based on hope, which is confidence without data. Truly great products have clear, undeniable signals. Kill hopeful projects before they drain all your resources and kill your company.

When a feature ships and there's no user feedback, it shouldn't be seen as a success. It's a terrifying indicator that no one is using it or cares about it, meaning the work had no impact and was a waste of time.

If You're Asking When to Kill a Feature, You Have Already Lost | RiffOn