The Wrong Question

I Thought We Had a Data Problem. We Actually Had a Question Problem.

Recently I found myself working through a reporting request that I had probably been approaching the wrong way for a long time.

The request was reasonable. A business group wanted better analytics around a category of sales. Not just how many were sold, but what customers were actually buying. What brands were moving? What colors and sizes were popular?Were certain SKUs helping drive recurring revenue? How long were customers keeping units before upgrading?

Those are useful questions. They are the kinds of questions that help a business understand customer behavior instead of only looking backward at revenue.

The problem was the data.

The system with all the useful operational detail did not reconcile cleanly to the accounting source of truth. We had spent plenty of time trying to understand why. The accounting records were the system we had validated over and over. The operational records had richer detail, but they also had issues we could not always fully explain.

So my instinct was pretty predictable:

If it does not tie, how can we trust it?

That mindset makes sense in finance. If I am preparing financial statements, I want the numbers to reconcile. I want the dollars to tie. I want the story to be supportable all the way down.

But then someone asked me a question that caught me off guard.

“Why does it matter?”

At first, I thought it was a strange question.

Of course it matters.

Why would anyone want an analysis that does not tie to the financials?

But when I tried to answer the question from her perspective, I struggled.

The business was not asking me to prepare financial statements. They were not trying to determine the official revenue number for the month. They were trying to understand patterns in customer behavior.

Those are different problems. Once I saw that, the work changed.

Instead of trying to force the operational data to behave like accounting data, I started looking at what it was actually good at. It had details the accounting system was never designed to provide. Unit attributes. Customer choices. Inventory characteristics. Patterns that would have taken a lot of extra tables, joins, and assumptions to recreate somewhere else.

In a way, I stopped trying to build the perfect dataset and started trying to learn from the dataset that already existed. That was the shift.

The question was no longer: “Can this replace the financial source of truth?” It could not, and it should not.

The better question was: “Is this reliable enough to help someone make a better operational decision?” That is a very different standard.

If a report is going into the financial statements, directional accuracy is not good enough. A few percent off can matter a lot.

But if the question is whether one market strongly prefers a certain type of unit, or whether customers are behaving differently across brands, the standard may be different. If the data shows a clear pattern, that pattern may still be useful even if the report is not built for financial reporting.

That does not mean data quality stops mattering. It means the level of precision should match the decision being made.

I think finance and accounting people especially can struggle with that, partly because we are trained to care about precision. That training is valuable. It protects the integrity of reporting.

But sometimes the business is not asking for accounting truth. It is asking for operational insight.

And if we apply the wrong standard to the wrong question, we can accidentally block useful information from ever reaching the people who need it.

I do not know exactly what happened after that first report was shared. I was thanked. I was told it was useful. I heard it was forwarded around to others in the organization.

But like a lot of analysts, I was not always in the room where the next decision was made.

That may be part of why this lesson has stayed with me. It made me realize that building the analysis is only part of the work. The more important part is understanding the decision the analysis is supposed to support.

I still care about reconciliation and about accuracy.

But now, before I get too deep into a dataset, I try to ask one question first: What decision are we actually trying to make?

The answer usually changes the work.