What Problem Is a Feature Request Actually Hiding?

A feature request sounds concrete, which is exactly why it is easy to implement too early.

“Add drag and drop.” “Give me another filter.” “Put AI here.” “Let me customize the dashboard.” These are useful signals, but they are already solution statements. They do not yet tell me what actually failed for the user.

A feature request is a proposed intervention

Before I turn a request into backlog work, I ask a different set of questions:

• What was the user trying to accomplish?
• Where did the flow stop or become uncertain?
• What information was missing at that moment?
• Which decision became difficult?
• Was the system showing the wrong state, or merely showing the right state badly?
• Does the requested feature remove the constraint, or just create another path around it?

That separation matters because product architecture is often determined before a component is written.

“More control” can mean “less decision burden”

Ordovia combines tasks, notes, habits, rituals, planning and personal context. In a product like this, unlimited dashboard customization can sound powerful. But if the underlying problem is that the user does not know what deserves attention at the start of the day, more configuration gives that product decision back to the user.

The useful question is not “how many widgets can we expose?” It is “what decision should become easier here?”

I classify the request before I design the solution

A request usually points to one of four layers.

Interaction

The right action exists, but touch targets, gestures, hierarchy or feedback make it hard to use.

Flow

Individual controls work, but the sequence is wrong. The user repeats decisions, loses context or has to move between surfaces unnecessarily.

Domain

The UI is exposing an ambiguity in the product model. Archive versus delete, task versus planned time, draft versus canonical revision: a better button cannot fix an undefined domain rule.

System

The problem lives in state ownership, synchronization, permissions, platform lifecycle or the source of truth. The visible feature request is only the last symptom.

Evidence before implementation

I look for evidence before choosing an intervention: a recording, reproduction steps, route and state, the canonical data model, similar surfaces, network behaviour and the difference between expected and observed behaviour.

Sometimes the answer is a new feature. Sometimes it is not.

If users cannot find an object, the right answer may be information architecture rather than another filter. If they keep looking for a Save button, the problem may be invisible autosave state. If a screen repeatedly shows stale data, a Refresh button may only hide invalidation or synchronization debt.

When I call it a real feature

I want three things to be true.

First, the problem is explicit. “Someone asked for this” is not enough.

Second, the behaviour has a clear place in the existing product model. A new capability should not become an isolated island with its own rules.

Third, success is verifiable. That can be a metric, but it can also be a behaviour: one coherent flow, consistent state across platforms, correct native back behaviour, or the removal of an accidental destructive action.

Keep a problem backlog, not a solution graveyard

Backlogs age badly when they contain only labels such as “AI summary”, “new view”, “drag and drop” or “more filters”. Months later nobody remembers what those ideas were supposed to fix.

A more durable record is:

Problem: the user loses daily context while planning. Evidence: the same information requires three surface changes. Constraint: mobile must retain one primary decision surface. Possible interventions: flow change, contextual panel, domain merge or a new feature. Decision: chosen from evidence.

The feature request is not something to dismiss. It is raw product signal.

My job is to close the distance between the requested solution and the real constraint. A perfectly built feature for the wrong problem is still the wrong product decision.