The Question You Forgot to Ask: How Business Questions Shape Data Modeling in Legal Tech?

The scene

Walk into most law firms and you’ll find the same contradiction: highly analytical minds surrounded by data they don’t know how to use.

Lawyers are rigorous thinkers. They build arguments from evidence, anticipate counterpoints, and rarely leave room for ambiguity in their work. But when you ask them what they need from a dashboard, the answer is usually some variation of “I want to see everything we have.”

This isn’t laziness or disorganization. It’s a cultural gap. Legal training sharpens the ability to react to a case, a client, a deadline. It doesn’t naturally develop the habit of asking proactive, structured questions about operational data. Numbers and metrics simply aren’t part of the professional language most lawyers grow up speaking.

So when a BI team shows up, the instinct from the business side is to hand over access to their systems and wait for something useful to appear. And the instinct from the technical side, under pressure to deliver, is to build something with what they have.

That’s where the trouble starts.

The symptom

The result is almost always the same: a dashboard that shows a lot and says nothing.

Pages filled with charts, tables and KPIs that nobody questioned before building. Total hours logged. Cases opened this month. Revenue by client. The data is real, the visuals are clean, but there’s no thread connecting them to an actual decision someone needs to make.

Stakeholders open it once, maybe twice. Then it sits there, occasionally pulled up in a meeting to show that yes, the BI team delivered something. But nobody acts on it, because it wasn’t built to drive action. It was built to fill a gap.

And the BI team feels it too. There’s a quiet frustration in spending weeks modeling data, building pipelines and designing reports, only to watch them collect dust. The work was technically sound. The process just started from the wrong place.

The dashboard wasn’t the problem. The missing question was.

The root cause

Every failed BI project usually comes down to the same thing: a question that was never asked.

When that gets skipped, the project doesn’t stop. It just runs blind. Data gets extracted, tables get modeled, dashboards get built. The process looks productive from the outside, but it’s construction without a blueprint. You might end up with walls, but they won’t lead anywhere useful.

In legal tech, this gets messier. BI teams are usually treated as a technical service. Management decides the company needs dashboards, budget gets approved, and suddenly there’s a developer asking lawyers to explain their data. Because lawyers don’t really know what BI can do, they describe how their systems work instead of what their actual problems are. The developer, trying to be helpful, models exactly what they described.

Nobody’s acting in bad faith. But nobody’s asking the right questions either.

The breakdown isn’t technical, it’s conversational. And it starts on day one, in those early scoping meetings where everyone talks past each other.

Why this keeps happening

This pattern isn’t exclusive to law firms. But there are a few reasons it’s particularly common in legal environments.

Cultural mindset. Lawyers are trained to respond to problems, not to anticipate them with data. Their work is reactive by nature: a client comes with a case, and they act. Sitting down to define metrics and business questions requires a completely different mindset, one that most lawyers were never asked to develop.

How BI teams are positioned. When a developer is seen as someone who “builds reports”, stakeholders don’t feel the need to think strategically before the first meeting. They assume the technical person will figure it out. The developer ends up doing discovery and delivery at the same time, which is too much to ask from a single role.

The uncomfortable truth. People often don’t know what they need until they see something they don’t want. Stakeholders in legal tech frequently realize what the right question is only after looking at a dashboard that doesn’t answer it. That’s not a failure of intelligence, it’s just how unfamiliar territory works. The problem is that by then, the model is already built.

These three things together create a cycle that’s hard to break without someone deliberately stopping the process and asking: what decision is this data supposed to support?

Kimball’s lens

Ralph Kimball wrote “The Data Warehouse Toolkit” in 1996, but the core idea behind his dimensional modeling approach is surprisingly relevant to the problem we just described.

Kimball’s methodology starts with four steps:

• Choose the business process you want to analyze
• Define the grain of your fact table
• Identify the dimensions
• Identify the facts

Simple on paper. But look at what the very first step demands: you need to know which business process you’re analyzing before you do anything else.

That’s not a technical requirement. It’s a business one.

Without a clear process to analyze, you can’t define the grain, which is basically the answer to “what does one row in this table represent?” And without the grain, your dimensions and facts are just guesses. The whole model becomes unstable, because it wasn’t built around a real question.

This is exactly what happens in the generic dashboard scenario. The developer skips, or is forced to skip, that first step. They go straight to the data and start modeling what they see. The result might be technically correct, but it’s built on a shaky foundation.

Kimball’s four steps aren’t just a modeling framework. They’re a reminder that good data work starts with a conversation, not a database.

Examples of good business questions

This is where things get concrete. To show how much a well-defined question changes the work, let’s look at three areas any law firm deals with daily: billing, case closure rate and team workload.

Billing

A vague request sounds like this: “I want to see our billing data.” A real business question sounds like this: “What percentage of worked hours are actually being billed to clients, and which practice areas have the highest loss?”

The difference is enormous. The second question immediately tells you what to model. You need a fact table around time entries, with dimensions like lawyer, practice area, client and case type. The grain is clear: one row per time entry. Nothing about that model is a guess.

Case closure rate

“I want to see case information” is not a question. “How long does it take on average to close a case by type, and is that trend improving over time?” is. Now you’re modeling case lifecycle events, tracking opening and closing dates, durations and outcomes. You know exactly what facts matter and what dimensions give them context.

Team workload

This one is trickier. “Which lawyers are consistently over or under capacity, and how does that correlate with case outcomes?” crosses two different business processes: capacity and performance. A vague request would never surface that complexity. A clear question forces you to deal with it upfront, which is exactly where it should be dealt with.

Three different questions, three completely different models. That’s the point.

What changes when you get it right

The difference between a project that starts with a clear business question and one that doesn’t isn’t just about the final dashboard. It changes the entire process.

When you know what you’re trying to answer, the first modeling decisions become much easier. The grain is obvious. The dimensions you need are obvious. You’re not guessing what facts matter because the question already told you. The model gets simpler, more focused, and easier to maintain down the road.

The stakeholder relationship changes too. When a lawyer comes to you with a real question, they’re invested in the answer. They’ll tell you when something looks wrong, suggest refinements, and actually use the dashboard because it was built around something they care about. That feedback loop is what turns a one-time delivery into something that grows and improves over time.

There’s also a less obvious benefit: trust. A developer who asks good questions before touching the data looks like a strategic partner, not a report builder. In a legal environment, where credibility is everything, that perception matters more than most BI teams realize.

None of this requires a perfect process or a long discovery phase. It just requires one honest conversation at the start, where someone asks: what decision are we trying to make, and what would the data need to show for us to make it confidently?

That question changes everything.

Practical takeaways

Getting a clear business question out of a lawyer isn’t always easy. They’re busy, they’re not used to thinking in terms of metrics, and they often don’t know what’s technically possible. But there are a few approaches that tend to work.

Start with decisions, not data. Instead of asking “what do you want to see?”, ask “what decision are you trying to make, and what’s stopping you from making it today?” That reframes the conversation around their world, not yours. Lawyers understand decisions. They make them every day.

Use bad examples on purpose. Sometimes the fastest way to get to a good question is to show a generic dashboard and ask what’s missing. People find it much easier to criticize something concrete than to describe something abstract from scratch. Let them tell you what they don’t want, and work backwards from there.

Find the person who feels the pain. In most law firms, there’s someone who manually compiles reports in Excel every week, or who spends hours answering questions that a dashboard could answer in seconds. That person knows exactly what question needs to be answered. Find them early.

Write the question down and get it signed off. Before any modeling starts, the business question should be written in plain language and agreed upon by the stakeholder. It doesn’t need to be a formal document, but it needs to exist. That single sentence will save you weeks of rework.

The goal isn’t a perfect discovery process. It’s just making sure that when you sit down to model the data, you’re not building in the dark.