Most teams treat missing features as gaps.
Something to be filled. Something to be added. Something that was overlooked.
But absence is rarely neutral.
If users don't use a feature, don't request it, or don't even notice it exists, that is still information. It just isn’t packaged in a way that fits neatly into a backlog.
We tend to privilege explicit feedback. Support tickets, user interviews, analytics events. Things that can be counted, categorised, prioritised. But software is constantly producing another kind of signal: silence.
User feedback systems are good at capturing what people complain about. They are far less good at capturing what people quietly ignore.
A missing feature is often read as a backlog item waiting to happen. But in many cases it is a hypothesis that never survived contact with reality. Something that looked important in planning, but failed to matter in use.
This is where teams start to drift. Because once everything is treated as a feature request, nothing is treated as a question about whether the thing should exist at all.
The more structured the delivery process becomes, the easier it is to confuse activity with value. A roadmap fills up. A backlog grows. Work continues. But none of that necessarily reflects whether users are actually changing their behaviour in response.
It feels similar to what The Lean Startup describes as validated learning: the idea that progress is not about output, but about reducing uncertainty through real use.
The uncomfortable implication is that sometimes the most correct action is to do nothing. Not because the feature is bad, but because the absence is telling you something more important than the addition ever would.
We tend to treat silence as missing data.
Often it is the data.