A dashboard is built around the questions someone already thought to ask. The charts, the date ranges, the segments — someone decided those in advance. That someone usually wasn’t in your last sprint planning meeting, and they almost certainly weren’t thinking about the specific decision you’re facing today.
I used to spend a lot of time reading dashboards. I’ve stopped. Not because the data is less useful — it’s more useful than ever. But reading a dashboard is a passive act. You’re accepting someone else’s framing of what matters. Interrogating your data is a different activity entirely.
Dashboards are designed to confirm things. Conversational analytics is designed to discover them.
The problem with dashboards isn’t the data
Dashboards are useful for monitoring. If you want to know whether a metric is inside normal range, a dashboard is exactly the right tool. They’re less useful when you want to understand something — when you have a specific question and you need to follow it wherever it leads.
The limitation is structural. A dashboard shows you the same view every time you open it. The metrics are predetermined. The segments are fixed. If the question that matters today doesn’t map to one of the charts you built six months ago, the dashboard can’t help you — not without a developer, not without a data team, not without building a new report and waiting for data to accumulate.
For product decisions made in sprint cycles, that latency is too long. The decision you need to make is now. The question is specific. The data exists — it just isn’t formatted for your question.
What interrogating data actually looks like
I connect Claude to my Matomo analytics through an MCP server — a setup I described in detail in How I connected Claude to my WordPress analytics. The practical effect is that I can ask questions in plain language and get back specific numbers, segmented the way I need them, without touching the Matomo UI.
The questions I ask are different from the questions a dashboard answers. They’re more specific, more contextual, and they branch. “What’s the bounce rate on the checkout page?” becomes “What’s the bounce rate on the checkout page for users who arrived from paid search, and how does that compare to last month?” becomes “Which pages did those users visit before landing there?” A dashboard can’t follow that chain. A conversation can.
The result isn’t a report. It’s a line of reasoning — one that I can take into sprint planning with a specific hypothesis, rather than a set of charts that need interpretation.
The questions dashboards can’t answer
There’s a category of product question that dashboards structurally can’t address. They’re the questions that require combining metrics, applying a segment that wasn’t set up in advance, or comparing periods in a non-standard way. In practice, these are often the most important questions — because they’re the ones that don’t have obvious answers.
Some examples from my own sprint prep:
“Did the users who converted after we shipped the new search experience come from the same channels as before, or did we attract a different cohort?” This isn’t a standard dashboard view. But it’s the question that tells you whether your intervention worked, or whether you got lucky with a traffic mix shift.
“For the pages we’re planning to change next sprint, which ones have stable engagement over the last three months, and which ones are trending?” This matters because you want to distinguish structural problems from seasonal or campaign-driven noise before you commit to redesigning something.
“Which of our content pages sends the most users to the booking flow, and is that changing?” This tells you which content is doing product work — and therefore which content to protect when you’re under pressure to cut scope.
None of these are exotic questions. They’re the questions a thoughtful product owner asks before making decisions. They’re just not the questions dashboards were designed to answer quickly.
What this requires
Two things make this approach possible: first-party data you control, and an AI interface that can query it in plain language.
The first-party data requirement matters more than it might seem. I use Matomo precisely because it runs on my own infrastructure and gives me unsampled, unfiltered access to the raw numbers. With sampled data — or data that’s been processed through a third party’s anonymisation layer — the specific segment comparisons I rely on either aren’t available or can’t be trusted at small sample sizes. The reasons I run Matomo on-premise aren’t just philosophical. They’re practical.
The AI interface lowers the cost of asking non-standard questions. Before I had it, I’d ask myself whether a specific data check was worth the time to set up the custom report and export. Usually the answer was no, and I’d make the decision without it. Now the cost of asking is close to zero, so I ask more questions. The decisions are better for it.
Where this fits in a product workflow
I’m not suggesting dashboards have no role. They’re the right tool for monitoring — for catching anomalies, for seeing whether a metric is inside normal range, for sharing a consistent view with stakeholders who need the same framing. I still have them. I just don’t use them as a primary thinking tool.
The distinction I’ve found useful: dashboards for monitoring, interrogation for deciding. If the question is “is anything broken?”, open the dashboard. If the question is “what should we build next?”, ask the data directly.
The Nielsen Norman Group describes analytics as most valuable when it moves from reporting to strategic decision-making — which requires the ability to ask specific, contextual questions rather than reading fixed views. The infrastructure to do that is now accessible without a data science team. The constraint is knowing which questions to ask.
That’s the part that doesn’t change. The questions still require product judgment. The AI doesn’t generate them — it answers them faster. Which means you can ask more of them, follow more threads, and arrive at better decisions in the same amount of time.
TL;DR: Dashboards are monitoring tools — they answer the questions someone already thought to ask. Interrogating your data with AI means asking specific, contextual, branching questions that follow the decision you’re actually facing. The shift requires first-party analytics you control and an AI interface that can query it in plain language. The questions still require product judgment. The AI just means you can ask far more of them.
Delphine Ragazzi is a Product Owner with 20 years in digital analytics and product delivery. About Delphine →
