Questioning Features Before Users Have To
Buildable features still need to survive pressure from users and the business.
It is easy to mistake a buildable feature for a useful one.
This usually happens during brainstorming. A direction looks clean, the data exists, the UI can be made polished, and the engineering path is not blocked. Nothing feels wrong because the idea is being tested against internal coherence.
But products are not used inside brainstorms.
A feature only becomes real once a user has to interpret it, act on it, or work around it. That is where many ideas that looked useful internally start losing shape. The question is not only whether something can be built or whether it looks impressive. The question is whether it survives pressure from the user and the business at the same time.
I ran into this while thinking through a dashboard home screen.
1. Data-Backed Does Not Mean Useful
The first set of ideas looked reasonable.
Counts. Hours transcribed. Average response times. Usage aggregates. Each one had data behind it, and each one rendered cleanly in my head.
That made them feel valid.
But they were only valid from the system’s side. The backend could measure them. The UI could display them. The dashboard could look complete with them.
Then one question changed the evaluation:
Most of the aggregates had no good answer.
They were observable, but not actionable. They described activity, but did not reduce uncertainty. They made the product look informative, but they did not help the user decide what needed attention.
That is where dashboards often fail.
They become a display of what the system knows, instead of a surface that helps the user act.
2. Brainstorming Rewards Internal Coherence
The problem is not that teams intentionally build useless features.
The problem is that brainstorming usually rewards ideas that can be justified internally.
An idea feels strong when:
- the data exists
- the UI is visually clean
- the feature sounds reasonable
- the implementation path is clear
- stakeholders can understand it quickly
But none of these checks prove user value.
They only prove that the feature fits inside the team’s current model of the product.
That model is incomplete by default because it usually overrepresents what the team can see and underrepresents what the user is trying to do.
The team sees systems, entities, counts, events, workflows, and implementation surfaces.
The user sees pressure, confusion, interruption, risk, and the next task they need to complete.
A feature that makes sense in the first world can still fail in the second.
- systems, entities, and events
- counts, workflows, and implementation surfaces
- what the product can display cleanly
- pressure, interruption, and risk
- uncertainty about what needs attention
- the next task they need to complete
3. Business and User Value Are Separate Filters
After skipping engineering feasibility, two filters still remain.
The first is business direction.
Does this feature support what the company, owners, or investors are trying to prioritize right now? A feature can be useful and still be strategically distracting. It can improve a small corner of the product while pulling attention away from the direction the business actually needs to move.
The second is user value.
Does the user need it, want it, or at least benefit from it once it exists? Users do not need to request every useful feature directly, but the feature still has to improve their workflow, reduce their uncertainty, remove friction, or help them make a better decision.
A weak feature often fails one of these filters.
It may look good in the product, but not move the business. Or it may align with a business goal, but add friction to the user experience. Or it may be technically interesting, but create no meaningful change for either side.
That is why “cool to build” is not a product argument.
It is only an internal signal.
Can the team build it with the data, UI, and engineering path available?
Does it support what the company needs to prioritize now?
Does it reduce friction, uncertainty, or effort for the user?
4. Questioning Is Pre-Production Pressure
The dashboard example was not really about dashboards.
It was about questioning things early enough that weak assumptions collapse inside the team, not in front of users.
A simple question like “what does the user do with this?” acts as pressure. It forces the idea to leave the internal room and face the user’s operational context.
If the feature survives, it becomes stronger.
If it does not, the team avoids shipping something that would later become interface noise.
Without that questioning, the cost moves forward. Users inherit the unclear decision, support teams absorb the confusion, and future product work has to route around another surface that exists but does not justify itself.
That is how products accumulate clutter.
Not through obviously bad decisions, but through individually reasonable features that were never pressured hard enough before release.
5. Feature Cost Is Not Only Engineering Cost
A shipped feature does not only cost development time.
It also adds:
- cognitive load
- maintenance surface
- design complexity
- documentation overhead
- QA coverage
- onboarding explanation
- future compatibility constraints
Internally, each feature arrives one at a time.
Externally, users experience the accumulation.
They do not see the meeting where each widget was justified. They only see a product that asks them to interpret more things before reaching the thing they came to do.
That is why omission is sometimes product work.
Dropping a feature is not always a lack of ambition. Sometimes it is the result of applying enough pressure to realize that the feature would make the product look richer while making the user’s workflow weaker.
Conclusion
The dashboard metrics were not wrong.
They were measurable, visually coherent, and technically reasonable. That was exactly why they were dangerous. They could have survived the brainstorm without resistance.
The useful question was not whether the feature could exist.
It was whether the user or the business would be better off once it did.
That question is easy to skip because it slows down the excitement of building, but skipping it only delays the pressure. Either the team questions the feature early, or users question it later through confusion, shallow usage, and avoidance.
A product does not become better because every internally valid idea gets shipped.