The Feature No One Asked For

"Nobody asked for this feature because nobody had the problem this feature solves."
// 2 MIN READLOAD: NOMINAL
[PRODUCT][DIAGNOSTIC]

The product team shipped a new feature last quarter. The release notes were written. The demo was recorded. The OKR was updated.

Nobody checked whether a customer asked for it. Nobody checked whether any customer used it.

Most features are born from internal pressure, not external signal.

The Origin of Phantom Demand

A feature appears on the roadmap because an executive saw a competitor's press release. Or because a sales team promised a prospect something that does not exist. Or because a product manager needed to fill the quarterly plan with deliverables and this one was already half-designed from a previous cycle.

None of these origins involve a user with a problem.

The system does not require user validation to begin building. It requires a ticket in the backlog with a priority label. The label is the authorization. The user is optional.

The Sunk Cost Escalation

Once the feature enters development, it acquires mass. Engineers are allocated. Designs are reviewed. Dependencies are declared. A launch date is committed.

At this point, killing the feature becomes more expensive than shipping it. Not technically expensive. Politically expensive. The manager who championed it cannot absorb the loss. The designer who spent three sprints on the interaction model cannot write "cancelled" in their performance review.

So the system ships something nobody asked for, because the cost of honesty exceeded the cost of waste.

The Adoption Ritual

After launch, the product team measures adoption. The numbers are low. This is expected, because the feature solved a problem that did not exist.

But the system cannot accept this conclusion. Instead, it diagnoses a "discoverability problem." It adds onboarding tooltips. It sends email campaigns. It builds tutorials to teach users how to want something.

The organization spends more resources teaching users to use the feature than it spent validating whether the feature should exist.

The Diagnostic

When a feature has low adoption, do not ask how to increase it. Ask why it was built.

Trace the origin. If the origin is a user with a documented pain point, iterate. If the origin is internal politics, competitive anxiety, or backlog padding, cut it.

The most expensive feature is the one the organization refuses to kill because someone important approved it.

End.