The spreadsheet is the most successful data tool ever built. It's flexible, immediately understandable, and requires no infrastructure. It's also the most common source of business risk we encounter — critical business decisions made from a workbook that three people have edited, nobody has tested, and everyone trusts implicitly.
The mistake: starting with the visualisation layer
Most BI migrations start by choosing a tool — Tableau, Looker, Power BI — and connecting it to the database. The dashboards look impressive in the first demo. Three months later, different teams are seeing different numbers on the same metric, nobody knows which is right, and the tools are being blamed for problems that exist in the data layer. The visualisation layer is the last thing to build, not the first.
Start with the semantic layer
Before you build a single dashboard, define your metrics. What does 'revenue' mean in your business? Does it include refunds? Is it recognised on invoice date or payment date? These definitions need to live in a semantic layer — a single place where all metric calculations are defined, tested, and version-controlled. dbt metrics and Cube.js both do this well. With a semantic layer in place, every dashboard and every analyst is working from the same definitions.
The adoption problem
A beautifully built dashboard that nobody uses is a failure. The most technically correct BI implementation we ever saw had 3% adoption six months after launch because the design ignored how the actual end users thought about their work. Build dashboards with the people who will use them. Run usability sessions. Iterate on the layout based on what decisions they actually need to make.