The Anatomy of a Business Question

The Coffee Machine Test

Consider this exchange at the coffee machine:

"How were sales last quarter?"

"Good! We increased it by 10%"

Both parties walk away satisfied. The conversation worked. But what actually happened? Did sales increase 10% across all customer segments? All product groups? Are we talking about orders placed or orders delivered? Gross or net of returns?

None of those questions came up because they didn't need to. Both people share context - years of it. They know which products matter, which metrics the company tracks, what "good" means. The ambiguity wasn't a bug; it was efficient communication between people who share tribal knowledge.

Now try building a dashboard from that question.

The Interface Mismatch

The difficulty people have formulating business questions isn't about intelligence or capability. It's about an interface mismatch.

Human communication evolved for context-rich environments. We're remarkably good at filling in gaps, inferring meaning, and navigating ambiguity. When you ask a colleague about sales, you're not just exchanging words - you're drawing on shared meetings, past conversations, company history, and implicit understanding of what matters.

Data systems have none of this. A dashboard doesn't know that "customer" means something different in marketing than in finance. A KPI definition can't intuit that "active" should probably exclude test accounts. A data model doesn't remember that conversation you had about seasonal adjustments.

This creates a genuine translation problem. People aren't asking bad questions - they're asking questions designed for human listeners, then expecting data systems to understand them.

What Makes a Question Answerable?

Questions that data systems can actually answer have a predictable structure:

"What is the [AGGREGATION] of [MEASURE] per [DIMENSION], [DIMENSION]?"

For example:

• "How many unique accounts have completed at least one purchase in the last 90 days, per week and acquisition channel?"

This sounds clunky compared to "How are customers doing?" But notice what the clunky version gives you:

• The measure is defined: unique accounts with completed purchase
• The time window is explicit: last 90 days
• The dimensions are stated: week and acquisition channel
• The aggregation is clear: a count

You could build a query from this. You could build a dashboard. You know exactly what "customer" means in this context because it's defined right in the question.

The Evolution of a Question

What's interesting is watching a question transform as the ambiguity gets squeezed out:

Stage 0 - The demand: "I need customer numbers!"

This isn't even a question. It's a statement that could mean almost anything.

Stage 1 - The vague question: "How many customers do we have?"

Better - it's a question now. But customers who have ever purchased? Currently active? In trial? As of when?

Stage 2 - The precise question: "How many unique accounts have completed at least one purchase in the last 90 days, per week and acquisition channel?"

Now we know what we're measuring, how we're slicing it, and what time period we care about.

Stage 3 - The question with definitions: The precise question, plus explicit definitions for every term that could be ambiguous. What exactly counts as "completed"? What are the valid acquisition channels? Is week ISO week or something else?

The gap between Stage 0 and Stage 3 isn't trivial. It requires real thinking about what you actually want to know and why.

Why This Matters Beyond Data

This same problem shows up in working with AI agents.

In designing for agentic experience, I called this "the sticky-note problem" - we pass AI fragments without context, expecting it to guess our standards and preferences. The underlying issue is the same: systems built for humans rely on shared context that never gets made explicit.

The qualities that make systems work well with AI agents - clear semantic definitions, explicit rules and boundaries, documented processes instead of tribal knowledge - these are exactly what makes business questions answerable by data systems.

In both cases, the solution isn't smarter technology. It's making the implicit explicit. Writing down what we actually mean. Defining our terms. Acknowledging that the receiver of our communication doesn't have access to everything in our heads.

There's another use case worth mentioning: validating data models. A well-formed question decomposes directly into model requirements - the measure reveals what entity you need, the dimensions reveal its attributes. If your data model can't answer the questions stakeholders actually ask, the model has gaps. The questions become a specification.

Common Failure Modes

A few patterns worth watching for:

The missing question mark. "Monthly active users by region." This sounds complete, but it's actually a statement masquerading as a question. Force it into question form - "How many monthly active users do we have per region?" - and you'll naturally start asking what "active" means, which regions, and what defines a month.

Undefined terms. "How many churned customers per month?" Churned could mean canceled subscription, hasn't purchased in six months, explicitly requested deletion, or failed payment. The person asking probably has one of these in mind. The data system needs to know which one.

The compound question. "How many new and returning customers do we have per channel, and what's their average order value?" Two questions pretending to be one. They need different grains, different visualizations, different contexts. Split them.

Missing time dimension. "What's our conversion rate by landing page?" When? All time? Last month? Is this a snapshot or a trend? Every business question has a time dimension, even if it's not obvious.

The Real Difficulty

The reason this is genuinely hard - not a matter of just trying harder - is that it requires a kind of context-switching that doesn't come naturally.

When you're thinking about your business, you're immersed in context. You know what matters, what's been discussed, what decisions are pending. Stepping outside that to ask "but what would someone with zero context need to know?" is cognitively expensive. It feels pedantic. It slows things down.

But the alternative is worse: meetings where 30 minutes are spent debating what "active user" means, three teams calculating the same metric three different ways, reports that contradict each other, dashboards nobody trusts.

The upfront work of defining terms and making questions precise isn't overhead - it's the actual work. Skip it, and you'll do it later, more expensively, when the dashboard is already built and the numbers don't match.

A Practical Starting Point

If you're trying to improve how your organization asks business questions, here's where I'd start:

Pick one important question your team asks regularly. Go through the exercise of making it fully explicit: What's the measure? What are the dimensions? What's the time grain? Define every term that might be interpreted differently by different people.

It might feel tedious the first time. But once you've done it, you have something you can actually build from. And more importantly, you have a template for how questions should be asked.

The formula isn't magic. It's just a structure that forces the translation between how humans naturally communicate and what data systems need to hear.

At the coffee machine, ambiguity is fine. At the dashboard, it's expensive.