Blog
The BI Tool Solved the Wrong Problem
I want to be careful with the title here, because it's easy to read it as a criticism of tools I have a lot of respect for. Tableau, Power BI, Looker — these are genuinely impressive pieces of software. They solved real problems. I've used them, relied on them, and watched them change what analysts are capable of.
But they solved a specific problem. And there's a different problem, adjacent to it and just as important, that the industry has mostly left untouched.
What the last decade actually built
If you step back and look at where the analytics industry invested its energy over roughly 2013–2023, a clear picture emerges.
The data layer got dramatically better. Cloud warehouses made it possible to store and query enormous amounts of data cheaply. Transformation tooling — dbt in particular — gave analytics engineers a principled, version-controlled way to build and maintain data models. The raw material got cleaner and more accessible than it had ever been.
The exploration layer followed. BI tools made it possible for reasonably technical people — and in some cases genuinely non-technical people — to pull their own reports, build their own visualisations, answer their own questions. The promise of self-serve analytics, which had been largely theoretical for years, started to become real.
These are genuine achievements. I don't want to gloss over them. The analyst who needed to write a ticket to the data team in 2012 to get a simple query run can now answer the same question themselves in ten minutes.
The problem that didn't get solved
What didn't change much, if you squint at it, is what happens after the analysis is done.
The delivery problem — getting finished analysis in front of the right people, in a form they can actually use, at the right time — is still mostly solved the same way it was in 2010. Email attachments. Slack links. Static PDFs. Decks built in PowerPoint or Google Slides and shared in a way that immediately makes them orphaned from the data they contain.
The BI tools made it easier to build dashboards. Dashboards are live, interactive, connected to the underlying data. This feels like it should solve the delivery problem. In practice, it mostly doesn't — for a simple reason.
Dashboards are destinations. Someone has to go to them. They require the decision-maker to form a habit, remember the URL, log in, navigate to the right view. Most decision-makers don't do this. Not because they're lazy, but because their job is not to monitor dashboards. They're moving fast, reacting to things, making decisions in contexts that don't naturally include "open the BI tool."
Analysis that requires people to come and find it is analysis that mostly doesn't get found.
The exploration/delivery split
Here's a way to think about this. There are two distinct jobs in the analytics workflow:
Exploration is finding the answer. Querying, transforming, visualising, iterating until the data says something true and useful. This is the work the analyst does.
Delivery is making the answer matter. Packaging it, framing it, getting it to the right person at the right moment in a form they can act on. This is the job that comes after.
BI tools are, fundamentally, exploration tools. They're excellent at giving analysts the ability to find answers. Most of them bolt on some delivery functionality — the ability to schedule a report, embed a dashboard, export a PDF — but this is clearly not where the product thinking went. It shows.
The scheduled PDF export that comes out of most BI tools is barely functional. The embed story is usually an afterthought requiring significant engineering. The "share with a stakeholder" flow assumes the stakeholder is happy to log in to another tool, which they usually aren't.
Why this happened
I think the BI industry went where the value was most legible. Exploration is a concrete problem: can you query this data without writing SQL? Can a non-technical person build this chart? You can demo exploration. You can benchmark it. The value is immediately visible when someone runs a query and sees their answer in seconds rather than days.
Delivery is harder to demo. It's about what happens after the analyst closes the laptop. It's about whether the insight caused anything to change. That's a longer feedback loop, more organizational than technical, and harder to sell.
There's also a buyer problem. The person who buys the BI tool is usually a data or engineering leader. Their job is to give analysts better tools. The delivery problem — making insights reach executives and operational teams effectively — is somewhat outside their remit. It falls between tools.
What good delivery actually requires
When I think about what it would mean to genuinely solve the delivery problem, it looks pretty different from what existing tools offer.
It requires publication, not just sharing. A piece of finished analysis should be a live document — connected to the data it references, updatable, something that can be pointed to and trusted over time rather than a static artifact that starts going stale the moment it's sent.
It requires meeting people where they are. The insight should arrive in the stakeholder's context — embedded in a page they already visit, pushed to them at the right moment — rather than requiring them to navigate to a new tool.
It requires the analyst's voice. Numbers without framing are ambiguous. The analyst who built the analysis understands its limits, its context, the question it was answering. Good delivery preserves that context rather than stripping it out.
And it requires different output formats for different audiences. A polished single-number summary for an executive. A detailed breakdown for an operational manager. An embeddable chart for a web page. Most current tooling produces one format and expects the audience to adapt to it.
Where this leaves us
None of this means BI tools failed. They succeeded at what they were designed for. But the framing of "better BI" as the solution to the analytics value problem is, I think, incomplete.
The exploration layer is largely solved for most organisations. The data is there. The ability to query it is there. The gap — increasingly the only gap that matters — is between good analysis and good decisions. And that gap is mostly a publishing problem, not a data problem.
That's where I think the next meaningful investment goes.
Max is building Infigured, focused on the publishing and delivery layer for analysts. If this resonates, sign up for updates or reach out directly.
Continue the workflow
Explore related guides
Next step
Move from insight to a stakeholder-ready story.
Infigure helps teams replace the export-to-slides loop with one connected reporting workflow for analysis, narrative, and delivery.