Before You Analyze the Problem, Frame the Question

Most business problems don't arrive as clean questions. They show up as something someone noticed: revenue is off-track, sales feel slower, conversion looks soft, customers seem to be leaving earlier, or a product isn't being used the way the team expected.

The natural next step is to investigate. Open the dashboard, pull the data, compare periods or segments, and look for the pattern that explains what changed.

But there is a step between noticing a problem and analyzing it that is easy to skip: deciding exactly what question the investigation needs to answer.

Without that step, good analysis can still end up pointed at the wrong problem.

A problem can look clearer than it is

Take a concern like, “Outbound performance is getting worse.”

Everyone understands the words, but they may not understand the same problem. Does performance mean activity, conversations, meetings or revenue? Is the change happening everywhere or in one segment? Compared with what period? How large is it? Why does it matter? What decision needs to be made once the team understands it?

Those questions have to be answered somewhere. If they aren't settled before the investigation begins, someone ends up making those choices while doing the analysis.

That is how the easiest metric to measure can become the definition of the problem, an early correlation can become the working explanation, or a leader's original hunch can quietly become the hypothesis everyone is trying to prove.

The uncomfortable part is that the resulting analysis can still look good. The queries can be correct, the charts can be convincing, and the patterns can be real. A team can do technically sound work for days and still answer a question nobody deliberately chose.

That is the problem TRACE is designed to prevent.

TRACE turns a concern into a question worth answering

TRACE is a business-question framing method. It takes a concern as it arrived and works toward a precise, evidence-answerable question.

It does not diagnose the problem, decide what data to use, or recommend what the business should do. Its job is narrower: establish what the business needs to learn before deciding how to learn it.

No matter what path you take, the starting point shapes the investigation. Start with the available data and the work can become shaped by what is easiest to measure. Start with a preferred solution and the work can become an exercise in proving it.

TRACE starts with the business problem instead.

When TRACE is useful, and when it isn't

TRACE is useful when something important has changed, underperformed or become harder to explain, but you don't yet have a question you can trust. Several explanations may be plausible. Different teams may be seeing different parts of the problem. Someone may have handed you a concern and asked you to investigate it. Or the business may already be proposing solutions before the underlying problem has been established.

It is especially useful when the answer will inform a consequential decision. The more the business is prepared to change based on what it learns, the more important it becomes to make sure it is investigating the right thing.

You do not need to know what data will answer the question before using TRACE. The evidence may already exist, or the process may reveal that the business is not currently capturing what it would need to know. Both are useful outcomes.

TRACE adds little when the question is already precise and bounded, when you are answering a straightforward reporting question, or when the decision is fundamentally about preference, values or risk appetite rather than something observable evidence can help resolve.

A useful rule of thumb is: use TRACE when you have a consequential business problem, evidence could help resolve the uncertainty, but you don't yet have a question you can trust.

How TRACE works

TRACE moves through the problem in a deliberate order, with each stage removing a different kind of ambiguity.

Raw Input captures the concern before it gets cleaned up. What was raised, what was actually observed, and what explanations or assumptions are already present?

T: Target Outcome identifies the business result that actually matters. It prevents an activity or proposed fix from masquerading as the outcome.

R: Range establishes where the question applies and where it doesn't. It defines the relevant population, process, period and segments so the investigation does not quietly expand into everything that could possibly be analyzed.

A: Anomaly clarifies what is actually different, changing or unexpected. This is where TRACE separates what is known from what is merely suspected. Observation is not explanation.

C: Consequence connects that change to the business effect. Not every unusual metric deserves an investigation, so this stage establishes why the issue is worth pursuing.

E: Execution identifies the decision that better evidence needs to inform, without choosing the answer in advance. A well-framed investigation should still be useful if the evidence comes back opposite to what you expect.

Those pieces then inform the Investigative Question. They are not fields to stitch together mechanically. Each stage has clarified something the final question needs to respect.

to wrap it up, a short Quality Check tests whether that framing held together. If the question is unclear, unbounded, built on an assumed cause or disconnected from a real decision, you return to the stage that created the gap rather than patching the final sentence.

The output is a quality-checked business question ready for the next step.

About 90 minutes from concern to question

A full TRACE pass is designed to take about 90 minutes:

Raw Input: 10 minutes
Target Outcome: 10 minutes
Range: 15 minutes
Anomaly: 20 minutes
Consequence: 10 minutes
Execution: 15 minutes
Investigative Question: 5 minutes
Quality Check: 5 minutes

Anomaly gets the most time because separating what is known from what is assumed often takes the most care. Range and Execution also get more room because a weak boundary or an assumed decision can distort everything that follows.

These are working time-boxes, not quotas. Move faster when something is already clear and spend longer when the framing exposes real disagreement.

For an investigation that may consume days of analysis and influence a meaningful business decision, up to 90 minutes spent making sure you are asking the right question is a relatively small investment.

What happens after TRACE?

TRACE tells you what you need to learn. It does not define the data needed to learn it.

That comes next through Data Translation, where the business question is translated into evidence requirements. What would need to be observed? What comparisons need to be possible? At what level does the evidence need to exist? Which definitions need to be consistent?

Sometimes that evidence will already exist in a form that can be interrogated. Sometimes the result will be more revealing: the business cannot currently observe what it needs to know.

That turns a vague request for “better data” into a specific requirement because you now know which business question the missing information needs to answer.

TRACE defines what you need to learn. Data Translation defines what you need to observe.

Only then should the analysis begin.

Frame the question first. Then earn the answer.