Ask for the last example
When someone asks for a dashboard, ask what they needed to find out the last time the dashboard would have helped. Which decision were they making? What information did they collect, and what happened because they could not collect it quickly?
This keeps the conversation grounded without dismissing the requested feature. The answer might support a dashboard, a scheduled report, a clearer status field, or a notification at the moment a decision becomes possible.
Identify the user and the decision
Two people can request the same feature for different reasons. A manager may want to spot stalled work, while an operator needs to find the next item to handle. A single screen designed around both needs can become cluttered unless the distinction is explicit.
Write the problem as a short statement containing the user, the situation, and the desired result. Add the consequences of leaving it unresolved. Avoid using the proposed feature name as the result; “can export a file” is less informative than “can reconcile these records with the finance system.”
Compare plausible responses
Consider at least one approach that changes the existing workflow rather than adding a new surface. Would better defaults remove the need for another form? Would an integration eliminate the report someone currently assembles by hand?
Evaluate options against the original problem, including how often it occurs and who will maintain the solution. Explain the chosen approach to the requester using their example. If the proposed change still leaves them unable to make the original decision, the conversation is not finished.
Keep the original request alongside the problem statement. It preserves useful context while letting the implementation evolve.
A practical example.
A manager asks for a live dashboard. In a recent example, however, the manager only needed to know which customer requests had no owner before the daily handover. That could be addressed by a saved queue with an “unassigned” filter and a clear assignment action.
Write the original request alongside the underlying decision. Then compare a dashboard, a filtered list, and a daily summary against the same need. The point is not to argue people out of their ideas; it is to preserve the useful intent while testing the proposed mechanism. Show a rough version to the manager and ask them to complete yesterday’s task. Observe what information they still have to find elsewhere.
Put it into practice.
- Record the requested feature without treating it as an agreed implementation.
- Ask what happened the last time the missing capability caused a problem.
- Compare alternatives using the user’s decision, frequency, and consequence of delay.