There's a question I started asking every stakeholder before I built anything for them at Amazon:
"What decision will you make differently once you can see this data?"
Most people couldn't answer it immediately. Some pushed back — "we just need visibility." Others rattled off three decisions, then pivoted to five metrics that had nothing to do with any of them.
That question saved me from building dozens of dashboards that would have looked impressive in a review and gathered dust in a browser tab by week three.
The dashboard trap
Here's how it usually unfolds.
A business team gets access to data for the first time. They're excited. They ask for a dashboard. The BI team builds one — clean, well-labelled, refreshes daily. Everyone loves it in the demo.
Six weeks later: the dashboard has 40 metrics, three sub-tabs, a date filter that nobody uses correctly, and an ASIN-level drill-down that took 60% of the build time and has been clicked exactly twice.
The business is still making decisions the same way they did before the dashboard existed: gut feel, whoever shouted loudest in the last meeting, or whatever the most recent email said.
The dashboard didn't fail. The dashboard succeeded at being a dashboard. That was the problem.
What actually happens when a dashboard goes live
Dashboards answer questions. What they rarely do is surface the right questions in the first place, or push someone toward a specific action.
Humans are pattern-matchers. When we see a chart going up, we feel good. When it goes down, we feel bad. We rarely ask: what should I do about this number specifically, given these constraints, by this Friday?
That translation — from metric to action — doesn't happen automatically. It requires judgment, context, and often another layer of analysis. Which is why the best analysts I worked with at Amazon weren't the ones who built the most dashboards. They were the ones who could take a single signal and turn it into a specific recommendation with a clear rationale.
The dashboard is the input to that work, not the output.
The failure mode at scale
At scale, this becomes expensive.
When I joined the EU Private Brands BI team in 2021, there were no analytics systems at all — I was the first BIE hire. So I got to build things from scratch. But I also got to watch what happened in adjacent teams that had been building dashboards for years.
Those teams had impressive catalogues: weekly business reviews, monthly reports, quarterly deep dives. Hundreds of metrics tracked. I counted once — one team had 22 active QuickSight dashboards.
What they didn't have was a clear answer to: what does good look like for this metric, what do we do when it's below that, and who owns the action?
Metrics without decision thresholds are just observations. Observations without owners are just noise.
What I built instead (and why it actually worked)
When I uncovered the ~€110M GMS opportunity through catalog defect analytics, the insight didn't live in a dashboard. It lived in a bridge analysis — a document that said: here is the specific defect category, here is the estimated GMS impact, here is the team that can fix it, here is what "fixed" looks like.
That got taken to senior leadership quarterly planning. It drove action.
The Deals Performance Dashboard I built had 90+ users across 10 countries, but its value wasn't the charts — it was that I'd made deliberate choices about what was not in it. Every metric had a clear owner. Every cut was tied to a decision someone was already making manually. The dashboard reduced friction on a decision flow that existed. It didn't create a new reporting obligation.
That's the distinction: decision-support systems versus reporting systems.
Three questions to ask before you build anything
-
What decision does this enable? If you can't name the decision, you're building a report. Reports have their place — but they shouldn't be mistaken for strategy.
-
What does "act on this" actually look like? Who clicks, what do they do, when do they do it? If the path from insight to action has more than two steps, you haven't finished the design.
-
What happens when this metric moves in the wrong direction? If there's no answer — no threshold, no owner, no pre-agreed response — the metric is decorative.
The AI layer changes the calculus
This is where I think things get genuinely interesting right now.
The bottleneck in analytics has never been data. It's been the synthesis step — turning a collection of signals into a specific recommendation under time pressure. That step requires judgment, which is expensive and doesn't scale.
LLMs are surprisingly good at the synthesis step, when they're given structured inputs and asked specific questions. Not perfect — they hallucinate, they need grounding, they miss domain nuance. But they're good enough to compress a two-hour analyst session into five minutes if the prompt and data pipeline are right.
That's the core idea behind Disha, which I've been building: a restaurant intelligence platform that takes publicly available data about a restaurant and produces a ranked action plan, not a chart. The output isn't "your Google rating is 4.1." It's "your most frequently mentioned negative is wait time; your competitor three blocks away consistently gets praised for it; here's what that implies for your staffing model."
That's the end of the stack I was always trying to build at Amazon. The dashboard was step one. This is step five.
The honest version
I've built dashboards that nobody used. I've built analyses that drove multi-million dollar decisions. The difference, almost every time, was whether I started from the decision or started from the data.
Starting from the data feels safer. You can always say "I gave them the information." Starting from the decision requires having an opinion, which is uncomfortable when you're new, and still uncomfortable when you're experienced.
But it's the only way to actually matter.
The question isn't "what metrics should we track?" It's "what decision are we trying to make, and what's the minimum data we need to make it well?"
Build for that. Delete everything else.