The feature nobody asked for that ships anyway
How internal conviction quietly outranks user evidence more often than teams admit.
Every product has one: a feature that shipped not because users asked for it or data supported it, but because someone senior was confident it mattered. Sometimes that instinct is right — genuine insight often looks like conviction before it looks like evidence. Often, though, it's just a preference wearing the costume of a strategy.
Testable in retrospect, rarely checked in the moment
The difference is usually testable in retrospect but rarely checked in the moment. Did the feature get a real success metric defined before it shipped, or only a story about why it mattered? Was there a point at which it could have been killed if the evidence didn't support it, or was it unkillable from the start?
Conviction isn't automatically wrong
Some of the best product decisions genuinely are conviction-driven bets that preceded the evidence — the evidence didn't exist yet because nobody had built the thing to generate it. The fix isn't banning conviction; it's not exempting it from the same scrutiny other bets get.
Hold every bet to the same standard
A defined metric, a real check-in date, and an honest willingness to be wrong — applied consistently, regardless of whose conviction drove the decision — is what separates a healthy amount of founder intuition from a pattern of unaccountable pet features.
- Conviction-driven features aren't automatically wrong — but they need the same rigor as any bet.
- Define a real success metric before shipping, not just a narrative for why it matters.
- Set an honest checkpoint where the feature could be killed if evidence doesn't support it.
Feature parity is a trap disguised as a roadmap goal
HAVE A PRODUCT IN MIND?
Tell us what you're building and where you need engineering support.