Much analytics work begins with a request for an output.
“We need a dashboard for this.”
“Can you add another KPI?”
“Can you analyze why this changed?”
“We need to measure the new feature.”
These can all be reasonable requests. The problem is that the requested output often arrives before the underlying decision has been made explicit.
That changes the quality of the work. A dashboard can be technically correct, well designed, and widely available while having little influence on what anyone actually does. An analysis can explain an interesting pattern without changing a choice. A KPI can be monitored for years without anyone knowing what action should follow when it moves.
I have found it more useful to start somewhere else: with the decision the evidence is meant to improve.
The output is not the objective
The first question is not necessarily what should be measured. It is what someone needs to decide.
That sounds obvious, but it has significant consequences. Once the decision is clear, several other questions become easier to answer: who owns it, what alternatives are genuinely available, when it needs to be made, what is already known, and what additional evidence could materially affect the choice.
Only then does it make sense to decide whether the right analytical response is a metric, a short analysis, a dashboard, an experiment, a forecast, or nothing new at all.
This is the principle behind the decision-based analytics approach I have used in practice: reframing reporting demand around the business question, the decision, the expected outcome, and how the result will eventually be assessed.
The distinction matters because reporting demand and decision demand are not the same thing.
A stakeholder asking for more visibility may genuinely need better reporting. But they may instead be trying to decide whether to change a product, invest in a channel, intervene in a customer journey, adjust a process, or leave something alone. If the underlying decision remains implicit, analytics is forced to infer what information might be useful.
That is usually where unnecessary complexity begins.
The decision changes the analytical question
Consider a team that asks for a dashboard showing adoption of a new digital feature.
If the purpose is simply operational monitoring, the request may be exactly right. A reliable definition, a few appropriate segments, and a trend over time could be sufficient.
But suppose the real question is whether further investment in the feature is justified.
Feature adoption alone is no longer enough. The relevant questions may include who uses it, whether use persists, how behavior differs between users and comparable non-users, what customer or commercial outcomes are associated with it, and whether those differences can reasonably be attributed to the feature.
The output changes because the decision changed.
The same principle applies to many common analytics questions. “Why did conversion fall?” means something different if the objective is to explain last week's performance than if the business is deciding whether to change the checkout experience. “How are our customers behaving?” is too broad until there is some understanding of what choice the analysis is supposed to inform.
The more important the decision, the more useful it becomes to be explicit about this relationship between question, evidence, and action.
Not all evidence answers the same question
Decision framing also helps avoid a common analytical mistake: expecting one type of evidence to answer a different type of question.
Descriptive analysis tells us what happened and where. It can identify differences between markets, customer groups, products, channels, or points in a journey. For many decisions, that is enough.
It does not automatically tell us why the difference exists.
If a group of customers who use a particular feature converts more often, that is an observation. It may be commercially important, but it does not establish that the feature caused the difference. The users may already differ in ways that explain both behaviors.
Sometimes that distinction matters greatly. Sometimes it does not.
The appropriate standard of evidence depends on the decision. A low-cost, reversible action may justify acting on directional evidence. A large, difficult-to-reverse investment may require stronger evidence, more careful comparison, or an experiment.
Analytical rigor should therefore be proportional to the consequence of being wrong, not to a general preference for sophisticated analysis.
This is also why I treat experimentation and causal analysis as part of a broader decision problem rather than as inherently superior analytical methods. Their value depends on the question being asked.
Expected impact and measured impact are different
Another distinction becomes clearer when analysis is connected explicitly to a decision: evidence before an action and evidence after it serve different purposes.
Before a decision, the organization is dealing with uncertainty. It may need to estimate likely effects, compare scenarios, understand trade-offs, and decide whether an intervention is worth pursuing.
These are expectations, not results.
After implementation, the question changes. Now the organization can assess what actually happened and, where possible, determine how much of the observed change can reasonably be attributed to the intervention.
Keeping the two stages separate sounds straightforward, yet they are often blurred. A business case can gradually be treated as though it were an achieved outcome. A later performance change can be attributed to an earlier decision without sufficient evidence that the decision caused it.
Decision-oriented analytics should make that distinction explicit.
Before acting: what do we expect, based on what evidence, and with what uncertainty?
After acting: what happened, relative to what comparison, and what can we reasonably conclude?
The answer does not always require a formal causal study. It does require clarity about what the evidence can and cannot support.
Keep the process proportionate
None of this means that every dashboard request should become a workshop on decision theory.
Many analytical needs are routine. Organizations need operational reporting, recurring performance views, agreed KPIs, and standard monitoring. If the purpose and response are already clear, adding another layer of process creates little value.
The point is not to make analytics slower.
It is to recognize when a seemingly straightforward request is standing in for a decision that has not yet been framed.
A useful signal is when the analytical team can answer the requested question but cannot explain what somebody would do differently once they have the answer.
That is the moment to clarify the decision.
Sometimes this changes the entire analysis. Sometimes it narrows it considerably. And sometimes it reveals that no new analytics product is needed at all.
Decide what the evidence is for
Analytics becomes more useful when its purpose is clear before its output is designed.
The practical question is simple:
What decision is this evidence meant to improve?
From there, the rest becomes more disciplined. The right question becomes easier to formulate. The appropriate level of evidence becomes clearer. Unnecessary analysis becomes easier to avoid. And the connection between analytical work and business action becomes visible.
The objective is not to eliminate dashboards or reporting. Both are essential.
It is to make sure that when the organization needs to make a decision, analytics is designed around that decision rather than around the first output somebody happened to request.