Dashboards are easy. Data models are hard.
Everyone wants better dashboards. Prettier charts. Real-time metrics. Executive summaries that update automatically. Tools like Looker, Metabase, and Retool make dashboards almost trivial to build.
But here's what I've learned: if the data model is wrong, no dashboard will save you.
The dashboard trap
A company hires me because they can't get answers. Their reports don't match. Different teams have different numbers for the same metric. The executive dashboard shows revenue growth while finance sees a decline.
The instinct is to fix the dashboards. Rebuild them in a better tool. Add more charts. Create a single source of truth.
This doesn't work.
The dashboards aren't the problem. They're reflecting a problem that exists upstream: the data model doesn't match reality.
What is a data model?
A data model is how you structure information to reflect how your business actually works.
Simple example: You have customers and orders.
A naive model: one spreadsheet with customer name, order date, and order amount in each row.
A proper model: separate tables for customers and orders, linked by customer ID. Now you can answer "how many orders has this customer placed?" and "what's the average order value by customer segment?" without gymnastics.
The naive model is faster to create. The proper model is faster to query. This tradeoff compounds as data grows.
The questions a data model answers
A good data model answers structural questions:
- What is an "order"? Is it a single line item or a collection of items?
- When is revenue "recognized"? When the order is placed? When payment clears? When service is delivered?
- What defines a "customer"? The billing entity? The user account? The physical location?
- How do we handle returns? Cancellations? Partial shipments?
These aren't reporting questions. They're definitional questions. Until they're answered, you can't build reliable reports.
I worked with a company that had three different "customer counts." Marketing counted email addresses. Sales counted accounts. Finance counted billing entities. All three numbers were correct — for their definitions. But no one had aligned on what "customer" meant.
The dashboard didn't need fixing. The definition did.
The cost of getting it wrong
Bad data models create compounding problems:
Multiple sources of truth. When the model doesn't fit, people create workarounds. Marketing maintains their own spreadsheet. Sales builds a shadow CRM. Finance exports to Excel. Now you have three versions of reality.
Expensive queries. Complex questions require complex logic. "What's our revenue by product category?" becomes a four-hour analysis instead of a thirty-second query.
Brittle reports. When the underlying structure doesn't match reality, reports break when reality changes. New product line? New customer segment? Time to rebuild everything.
Lost institutional knowledge. The workarounds live in people's heads. When they leave, the knowledge leaves too. The new hire can't figure out why the numbers don't match.
What good looks like
A well-designed data model:
Reflects how the business actually works. Not how it theoretically works. Not how it worked two years ago. How it works today, including the edge cases.
Has clear definitions. Every entity is defined. Every relationship is explicit. There's no ambiguity about what "customer" or "order" or "revenue" means.
Separates facts from interpretations. The order date is a fact. Whether it counts toward this quarter's revenue is an interpretation. Keep them separate.
Handles time correctly. Most business questions are temporal. "What was the revenue last month?" requires knowing when revenue was recognized, not just when the order was placed. This is where most models fail.
Is normalized appropriately. Not everything needs to be in third normal form. But data that's updated frequently should exist in one place. Otherwise you'll spend forever keeping copies in sync.
The investment
Building the right data model takes time. It requires understanding the business deeply — not just what reports people want, but why they want them and what decisions they'll make.
This is unglamorous work. There's no demo. No launch party. The output is usually a schema diagram and a set of definitions that look obvious in retrospect.
But it's the foundation everything else depends on.
Good model + simple dashboard = reliable answers.
Bad model + sophisticated dashboard = reliable confusion.
How I approach it
When I redesign a data model, I start with questions:
What decisions does this data support? Work backward from the decisions to the data. If you don't know why you're collecting something, you probably don't need it.
What are the entities? List the real-world things the business cares about. Customers. Orders. Products. Locations. These become your tables.
What are the relationships? How do entities relate? Customers place orders. Orders contain products. Products have prices. These become your foreign keys.
What changes over time? Prices change. Customer addresses change. Product catalogs change. How will you track history? How will you report accurately across time periods?
What are the edge cases? Every business has them. Partial orders. Refunds. Transfers between accounts. Manual adjustments. The model needs to handle reality, not just the happy path.
Then I build it, migrate data carefully, and update reports to use the new structure. It's weeks of work. It pays off for years.
The meta-point
Dashboards answer questions. Data models determine what questions you can ask.
If your data model doesn't reflect reality, your dashboards show fiction. Sophisticated fiction with real-time updates and beautiful visualizations — but fiction.
The companies that make data-driven decisions aren't the ones with the best dashboards. They're the ones with accurate models. Everything else follows from getting the foundation right.
For questions about data modeling and reporting architecture, reach out here.