Asking Got Easy. Understanding Didn't.

I ask a lot of questions. Probably more than is comfortable for some people in the room.

I didn't come from tech. I came into a startup that was building an AI data analytics product, with no background in software and none in data, and I picked up responsibilities in the order the company needed them. There was a lot to learn.

Which left me two options. I could perform expertise I hadn't earned yet, or I could ask.

Asking is faster. It's also the only one of the two that actually works.

What I didn't expect was how far that would carry. The same habit that got me up to speed with people turned out to be the difference between useful AI and impressive-sounding AI, and then it turned out to describe something true about how companies work with their own data.

Ask the person who knows

Most people enjoy explaining something they know well. Ask a good question and someone will hand you years of their experience in twenty minutes. You get to skip ahead, and they get to be the person in the room who knows the thing, which most of us like.

There's research on this. People who ask more questions, especially follow-up questions, come across as more responsive and are better liked.

The first question is easy. The second one is where it gets interesting, because you can only ask it if you were actually listening. That's the part I work at: staying with what someone is saying closely enough that my next question comes from what they just told me, not from the list I walked in with.

AI didn't make questions less important

It made them more important.

AI makes it incredibly easy to get an answer. That's exactly why knowing what to ask matters more than it used to, not less.

There are two ways I've watched people use these tools. The first is commanding: write me a go-to-market strategy for this segment. You'll get something back, and it will be structured and confident. It will also be generic, because the model knows a great deal about go-to-market strategy in general and nothing about your customers, your constraints, your last two failed experiments, or why this segment matters to you right now.

The second is exploring:

• What do I need to understand about this before I decide anything?
• What assumptions am I making?
• What would someone who's done this ten times notice here?
• Why does that matter?
• What am I missing?

Then, after that conversation, ask for the strategy. Now you both have context. You've learned something along the way, and the answer is built on your situation rather than the average of everyone else's. AI can produce an answer with almost no context. That doesn't mean it can produce the right answer for you.

It works the same way when you point AI at your numbers. Ask it why revenue fell and you'll get a plausible list of reasons. Tell it what changed last quarter, how you define the segment, which of these numbers you actually trust and which you don't, and then ask, and you'll get something worth taking into a meeting.

Same lesson I'd learned from people, showing up in a different form. The first answer is rarely the most interesting part. The questions that follow are where the understanding starts.

Curiosity has a shape

The important thing is not to stop questioning. Curiosity has its own reason for existence... Never lose a holy curiosity.
— Albert Einstein, recalled by William Miller, LIFE, 1955

I used to think of curiosity as a personality trait. Some people have it, some don't.

The economist George Loewenstein's information-gap theory describes something more mechanical than that. Curiosity shows up when we notice a difference between what we know and what we want to know. Not from knowing nothing... from knowing just enough to see the shape of what's missing.

Which is exactly what a business number does when it moves.

Revenue fell twelve percent last quarter. By itself that's not an insight. It's a gap. And the gap immediately generates questions:

• Fewer customers, or smaller deals?
• Churn, or slower new business?
• One region? One product? One segment?
• Seasonality, or something we changed?

That's curiosity turning into analysis, and it happens in about four seconds inside somebody's head.

But notice what had to be true before any of those questions could form. You had to know that revenue is something you track, that it can be cut by segment and by region, that seasonality is a thing. Curiosity needs a little footing. It doesn't come from knowing nothing, and a blank box with a blinking cursor is not a curiosity strategy.

So sometimes the hardest part isn't answering the question. It's knowing which questions are even available to ask.

How business data usually gets organized

When someone in the business hits a problem, what's in their head is a sentence:

Why is churn going up?

When that same person opens the company's data infrastructure, what they see is closer to:

customer_events account_master subscription_history sf_opportunity invoice_line_items

I want to be careful here, because the easy version of this argument is that the technical layer is wrong, and it isn't. Those names exist for good reasons. Databases need tables. Governance needs structure. Somebody has to answer where this lives, what can be joined to what, and who's allowed to see it. Decades of data modeling practice went into making that reliable, and it worked.

The technical layer isn't wrong. It's solving a different problem.

Real analysis is also messier than question, then answer. Analysts often start by exploring the data itself, working out what's in it and whether it can be trusted, and the question sharpens as they go. But what sets the whole thing in motion is almost always a business concern, not a table.

Someone has always had to translate the question

For as long as companies have had data, somebody has been doing this translation by hand. Usually an analyst.

A manager asks: why did enterprise churn spike last quarter?

A good analyst doesn't go run a query. They start asking questions of their own:

• What do you mean by enterprise, headcount or contract size or the sales segment?
• Logo churn or revenue churn, gross or net?
• Do you care about the reason, or just the number?

Then they figure out which Sources matter, how they relate, which definitions apply, and which number actually represents the question.

That's not SQL work. That's translation work. Researchers who studied analysts inside a large enterprise described them almost exactly that way, as bridges closing a semantic gap between datasets, tools, people, and business needs.

And then the answer gets delivered, and most of that translation evaporates. The dashboard survives. The question, the definitions, the reasoning, and the context usually don't. Six months later somebody asks a version of the same thing and it all gets rebuilt from scratch, sometimes differently... which is how two teams end up with two churn numbers and a meeting about whose is right.

As an industry we got very good at storing the data and the answer. We were less good at storing the question that gave the answer meaning.

Curiosity has always been core to Querri. From the start you could just ask your data a question, and as the product grew we trained it to think more like a business owner than a general-purpose analytics tool, so it suggests the questions that actually matter for the data sitting in front of you. More recently we made a bigger call: build the whole workflow around questions rather than tables and schemas. That's the Querri Library.

That translation work is the job of the Library agent. It asks the clarifying questions and connects the question to the KPI that represents it. The difference is that the context can stay in the Library instead of walking out of the room with whoever did the analysis.

What that looks like in practice

The machinery underneath doesn't go away. The sources, the joins, the permissions, all of it is still there, because you can't compute a real answer without it. What changes is where a person starts.

You start from the question. We call it the Anchor Question. It connects to the KPI that says whether the outcome is actually improving, the definitions you need to read that number sit with it, and the data that can answer it lives underneath. In practice:

The question: Are new customers getting value quickly enough?

The KPI: Time to First Value

The follow-ups: Which acquisition channels reach value fastest? Where do people stall? Has it improved this quarter? Does it predict retention?

The definition: What exactly counts as first value?

Underneath: Product events, CRM, signup, and billing data

Same infrastructure. Different front door.

This is why questions and KPIs sit at the foundation instead of being something we layer onto the data later. In business, curiosity gets much more useful when it's connected to an outcome that matters, and a KPI is how a company says what matters. Anchoring a question to one is the difference between an interesting number and an answer somebody can act on.

There's a side effect we didn't anticipate. A company's recurring questions turn out to be information in their own right. If ten people keep asking which customers are likely to churn, that tells you what the business is actually worried about.

Asking got easy. Useful answers still need context

AI made asking another question easier than it has ever been. That's the real change.

What it didn't change is that a useful answer has to be about you. Ask any model why revenue fell and you'll get the reasons revenue usually falls. That isn't wrong. It just isn't yours.

Which is why a question is such a useful place to start. It arrives already carrying what the data can't: what you're worried about, which customers you mean, what you've already tried.

Curiosity is what makes someone ask. Context is what makes the answer worth having.

Your tables tell you what data you have. Your KPIs tell you what you've decided to measure. But the questions your team keeps asking are what reveal what you're actually trying to understand.