The Difference Between a Finding and a Decision
Most research tells you what is true. Decisions require something else entirely.
The presentation went well.
Twelve weeks of research. A clean methodology. Statistically robust findings with confidence intervals that held up under scrutiny. The deck was polished. The room was engaged. The senior leader asked good questions and said, genuinely, that it was some of the most rigorous work the team had produced.
Three months later the decision got made anyway. Different direction. No reference to the study. When someone asked why the research hadn’t informed the outcome, the answer was something about timing, about how the business context had shifted, about how the findings were interesting but didn’t quite speak to what the team needed to know right now.
Nobody said the research was wrong. It wasn’t. The findings were accurate. They just didn’t change anything.
This is not a story about a bad research team or an evidence-resistant organization. It is a story about a category error that most organizations make so consistently they have stopped noticing it. The research was designed to produce a finding. The organization needed something to support a decision. Those are different things, and almost nobody explicitly designs for the difference.
What a finding actually is
A finding is a true statement about the world derived from evidence. Users prefer Feature A over Feature B. Churn is highest among users who don’t complete onboarding. Employees in this demographic report significantly lower engagement scores than the organizational average.
Findings are valuable. They are also inert on their own. A finding tells you what is. It does not tell you what to do next, which option to choose, what to prioritize, what to stop doing. The gap between what is and what to do is where most research disappears.
The gap exists because decisions require more than accurate findings. They require evidence that is calibrated to the specific choice at hand, framed around the actual options available, connected to the people who have to act, and clear about what it cannot tell you as much as what it can. Most research is not designed with any of that in mind. It is designed to be true. Truth is necessary and insufficient.
What a decision actually requires
Think about the last significant decision you had to make with evidence. Not a routine call, a real one with meaningful stakes and genuine uncertainty. What did you actually need to know?
You needed to understand the tradeoffs between specific options, not just the state of the world in the abstract. You needed a sense of how confident to be in the evidence, not just what the evidence said. You needed to know what the evidence couldn’t tell you, where the gaps were, what you were still essentially guessing at. And you probably needed all of this framed around the actual decision in front of you, not a research question that was specified six months earlier when the context looked different.
Most research is not built for this. It is built to answer a question. The question it answers is often a reasonable approximation of what the decision-maker needs but it is rarely the same thing, and the distance between a reasonable approximation and the actual decision is where insight goes to die.
The specific ways this breaks down are worth naming:
The question was specified too early. Research timelines require committing to a question weeks or months before the findings land. By the time the study is complete the decision context has often shifted. The findings are accurate answers to a question that is no longer quite the right one.
The findings are not framed around options. Most research reports present findings neutrally, as facts about the world rather than as inputs to a specific choice. A decision-maker reading a research report has to do the work of translating findings into implications for their actual options. That translation is hard and often does not happen well under time pressure.
Uncertainty is underreported. Research that surfaces its own limitations and confidence bounds is more useful for decisions than research that presents findings with false precision, but it is also harder to present and easier to challenge. The incentive is to report cleanly, which systematically overstates how much the evidence actually tells you.
The right people are not in the room. Research that is designed in isolation from the people who will act on it tends to answer the questions researchers find interesting rather than the questions decision-makers find necessary. The gap between those two sets of questions is often larger than either party realizes.
Why this matters more when AI is in the loop
The finding-versus-decision gap has always undermined strategy. In AI product contexts it becomes structurally dangerous in a specific way.
AI systems are trained on findings, patterns extracted from historical data, and then deployed to support decisions, which require calibrated judgment about novel situations. When the data was collected to answer the wrong question, the model inherits those questions. When the research informing product direction was designed to be defensible rather than decision-relevant, the product gets optimized for the wrong outcomes. When the evaluation framework measures what was easy to measure rather than what actually mattered for the decision, the model gets validated against a standard that was never quite right.
The errors compound. A model trained on findings that were never connected to decisions will produce outputs that are accurate in the narrow sense and useless in the practical one. It will tell you what is. It will not tell you what to do. And because the outputs are fluent and confident, the gap between finding and decision gets harder to see, not easier.
This is not a model quality problem. It is an upstream research design problem that gets encoded into the model and then distributed at scale.
A pattern worth naming
This gap between the question on the table and the question that actually needed answering showed up consistently in my own work across federal modernization, enterprise AI platforms, and healthtech contexts. The formal research question was rarely wrong exactly. It was usually a reasonable approximation of what the organization thought it needed to know. But the decision that was actually blocking progress required something the formally specified question was never designed to produce.
The organizations that moved fastest were not the ones with the most research. They were the ones where someone had taken the time to connect the research question to the actual decision before the study was designed. That step, which sounds obvious and takes maybe two hours of structured conversation, was the difference between research that changed direction and research that got filed.
It is also, in my experience, the step that gets skipped most consistently under time pressure. Which is precisely when the quality of the decision matters most.
What designing for decisions actually looks like
The shift from designing research to produce findings to designing research to support decisions is not primarily methodological. It is relational and structural.
Start with the decision, not the question. Before specifying a research question, name the decision it is meant to inform. Who is making it. What the options are. What would change their choice. What they already know. What the research needs to add that they don’t already have. A research question derived from a decision is fundamentally different from a research question derived from curiosity or organizational habit.
Build in decision framing from the start. The research report is not the deliverable. The decision support is the deliverable. That means findings need to be explicitly connected to the options available, uncertainty needs to be reported honestly, and the implications of the research for specific choices need to be part of what the research produces, not an afterthought for the decision-maker to work out alone.
Define what you cannot answer. A research design that is honest about its own limitations is more useful for decisions than one that presents findings with false completeness. Decision-makers who know where the evidence is thin can compensate. Decision-makers who don’t know are operating on false confidence, which produces a specific and predictable category of error.
Put researchers and decision-makers in the same room earlier. Not at the presentation stage. At the design stage. The questions that matter for a decision are often not the questions that get specified when researchers work in isolation. Closing that gap requires structural changes to when and how researchers engage with the people who will act on their work.
Measure research by downstream decision quality. Not by volume of studies, not by methodological rigor alone, not by how well the presentation went. By whether the decisions that followed were better. This is a harder metric to track and a more honest one. Organizations that measure their insight function by output will get output. Organizations that measure it by decision quality will eventually get something more valuable.
None of this requires abandoning rigor. The argument is not that findings don’t matter or that methodological quality is irrelevant. It is that rigor applied to the wrong question produces accurate answers to problems nobody has. The goal is rigor in service of decisions, which requires knowing what the decision is before you design the research meant to inform it.
Most organizations have never made that a requirement. The ones that do will find that their research starts changing things.
This is the first part in The Measurement Traps That Break Strategy, a series on how evidence infrastructure fails organizations and what to do about it. Start with the series introduction here. Next: Why Most Insight Functions Produce Answers Nobody Asked For.
Ground Truth is written by Shannon Coleman, PhD. Product strategy leader and researcher with a background in psychology and quantitative methods. Her work spans govtech, healthtech, fintech, and consumer product contexts, with particular depth in enterprise AI platforms. Portfolio: shannonlcoleman.com