Product Sense · medium
A stakeholder asks for a dashboard showing everything. How do you respond?
Asked in BI Developer interviews.
Short answer
Push back with questions, not a wall of charts: what decision does this drive, who acts on it, how often, and what would make them act differently? Then design to that decision. Everything dashboards get built once and never opened, a dashboard is a decision tool, not a data dump.
How to answer it
What is actually being asked
Nobody wants everything. A request for everything means the person cannot yet name what they need, usually because they are worried about missing something. Building it literally produces a dashboard with forty charts that nobody opens twice.
So the response is not no, and it is not yes. It is a question.
The questions to ask
What decision will this help you make?
The single most useful question. Everything follows from it.
What will you do differently depending on what it says?
If there is no answer, it is curiosity rather than a decision, which
is fine but does not need a dashboard.
How often will you look at it?
Daily and quarterly need completely different designs.
What do you look at today, and what is missing?
Fastest route to the real gap.
If you could only see three numbers, which three?
Forces prioritization without a confrontation.Then propose, do not refuse
Come back with a small version: three to five metrics that serve the decision they named, with drill-down for the detail. Ship it in a few days rather than something comprehensive in a month, then add what they actually ask for once they have used it.
That sequencing is the answer to the question. It gets them something quickly, and the additions afterwards are driven by real use rather than by anxiety.
Why "everything" fails
- Forty charts means no hierarchy, so nothing looks important.
- It loads slowly, so people stop opening it.
- Every metric needs definition, testing and maintenance forever.
- Nobody owns it, so it decays and quietly misleads.
Key points
- The request means "I do not know what I need yet", so help them name it.
- What decision will this help you make is the question that unlocks it.
- Propose a small version rather than refusing.
- Ship in days, then extend based on use.
- Every chart is a permanent maintenance obligation, so fewer is genuinely kinder.
FAQ
- What if they insist? Build the small version first and offer the rest as phase two. Most phase twos are never requested.
- Is it ever legitimate? An exploratory tool for analysts, yes. That is a different product from an executive dashboard.
- How do I say no politely? You do not say no. You ask what decision it serves, and the scope shrinks on its own.
The 30-second answer
I would treat it as a signal that they cannot name what they need yet, rather than as a specification, because nobody actually wants forty charts.
So I would ask what decision this helps them make, and what they would do differently depending on what it shows. Then how often they will look, what they use today, and if they could only see three numbers which three. Those questions shrink the scope without any confrontation.
Then I would propose rather than refuse: three to five metrics serving the decision they named, with drill-down for detail, shipped in a few days instead of something comprehensive in a month. Then extend it based on what they actually ask for once they have used it, because that is driven by real use rather than by worry about missing something.
In the interview
- What they are checking: whether you can question the request without refusing it, and whether you design to a decision.
- Common mistake: building everything. It ships late, loads slowly, and nobody can find the one number they needed.