April 7 2025
Dashboards That Help Decisions Instead of Decorating Meetings
How to build dashboards that actually guide product and engineering decisions instead of just showing pretty numbers in a weekly review.
Andrews Ribeiro
Founder & Engineer
5 min Intermediate Thinking
The problem
A lot of teams say they want to be data-driven.
Then they make the classic move:
- build a dashboard quickly
- throw everything into it
- bring it to the review
- expect clarity to appear on its own
It does not.
What shows up instead is something else:
- too many charts
- no hierarchy
- numbers without context
- discussions driven by impression
In the end, the dashboard exists.
But the decision still comes from the most confident person in the room.
Mental model
Think about it like this:
a dashboard does not exist to prove that you measure things. It exists to shorten the distance between signal and decision.
If it does not help answer:
- is this improving?
- where did it get worse?
- do we need to act now?
then it is probably just a display window.
Breaking the problem down
Start with the question, not the chart
This is the root mistake.
People start by thinking:
- “let’s build an activation dashboard”
It is better to start with:
- “what activation decision do we want this dashboard to support?”
Example:
- compare the old and new flow
- detect a drop in a specific segment
- see whether onboarding simplification really helped
When the question becomes clear, the dashboard gets smaller.
And that is good.
A monitoring dashboard is not an investigation dashboard
This is another common confusion.
Some dashboards exist for quick reading.
Others exist for opening the box and investigating.
Mixing both creates a heavy screen and bad reading.
Monitoring usually needs:
- a few metrics
- a trend
- comparison to the previous period
- guardrails
Investigation usually needs:
- slices
- drill-down
- more detail
When you put everything in the same place, nobody does either one well.
A main metric without context misleads
Imagine the dashboard shows:
- activation is up 8%
That sounds great.
But the missing questions are:
- in which segment?
- with what volume?
- did something else drop?
- did errors rise too?
- was this a one-off campaign effect?
A number by itself invites lazy interpretation.
A good dashboard helps prevent that mistake.
Guardrails need to stay close to the main metric
If the main dashboard lives in one tab and the side effects live somewhere else, many people will never connect the two readings.
That is why strong guardrails should stay close to the number you are trying to move.
Example:
- conversion
- cancellation
- errors
- support load
in the same view.
That reduces false wins.
Highlight change, not only current state
Another problem with decorative dashboards:
they show the current value, but do not help you notice meaningful change.
Sometimes the important thing is not “we are at 42%.”
It is:
- we dropped 6 points since yesterday
- only mobile was affected
- variant B hurt retention
Good reading almost always needs comparison.
Simple example
Imagine an onboarding dashboard.
Bad version:
- page views
- CTA clicks
- time on screen
- loose events
- separate charts with no connection
Better version:
- main metric: completed activation
- context: total volume in the period
- initial slice: platform and traffic source
- guardrails: submission errors and abandonment in the next step
- comparison: previous week
Now there is a narrative.
You are not just seeing numbers.
You are seeing:
- what changed
- where it changed
- whether that change was actually good
What usually goes wrong
- Starting with BI before defining the question.
- Showing metrics that impress instead of metrics that guide.
- Mixing monitoring with deep investigation.
- Keeping guardrails too far away from the main metric.
- Creating a dashboard that depends on oral explanation every week.
- Updating the screen but not reviewing whether it still matches current decisions.
How someone more senior thinks
A more mature person usually looks at a dashboard and asks:
- what would I do differently if this number moved?
- what risk would I stop seeing if I removed this chart?
- does this help us decide or only help us tell a story afterward?
That filter kills a lot of useless visualization.
And that is great.
Because a dashboard should not compete for completeness.
It should win on usefulness.
Interview angle
This topic can show up like this:
- “how would you follow this feature after launch?”
- “what dashboard would you build?”
- “how would you avoid looking at the wrong metric?”
The interviewer usually wants to see whether you:
- measure with intention
- know how to separate the main signal from context
- do not answer with a random list of charts
Weak answer:
I would build a dashboard with the main numbers and track them over time.
Strong answer:
I would start with the decision the dashboard needs to support. If it is for monitoring, I would show a few central metrics, comparison with the previous period, and guardrails close to the main one. If the screen needs to be explained every time, it is probably badly designed.
Closing
A useful dashboard does not need to look like a cockpit.
It needs to do one thing well:
help busy people notice what matters without getting lost in decoration.
If the team leaves the meeting with more charts and the same doubt, the problem was not lack of visualization.
It was lack of focus.
Quick summary
What to keep in your head
- A good dashboard answers a decision question. A bad dashboard only exposes numbers without direction.
- Fewer metrics grouped well usually help more than twenty charts fighting for attention.
- Without context, variation, and guardrails, a dashboard encourages bad interpretation.
- Visualization is only the shell. The real value is in the slice and the question it supports.
Practice checklist
Use this when you answer
- Can I say which decision this dashboard helps someone make?
- Are the main metrics shown together with context and guardrails?
- Can someone new on the team tell in one minute what is normal and what looks wrong?
- Am I showing what matters or only what is easy to extract?
You finished this article
Share this page
Copy the link manually from the field below.