What Behavioural Research Looks Like When It's Done to Inform, Not to Justify

Somewhere between a research brief and a boardroom presentation, a decision gets made about what the research is actually for. That decision rarely appears in writing. It sits in the tone of the commission, in the questions the team is told to ask, in the way findings get framed before they reach the room. And it determines whether the work that follows is genuine discovery or an elaborate way of making a conclusion look earned.

We have walked into projects where the research was real, the questions were open, and the team genuinely did not know what they were going to find. We have also walked into projects where the answer was already written and the research was being built around it. On the surface, both look the same. Same methodology slides. Same participant counts. Same confident readout in week four.

The decision about what research is actually for is made before a single participant is ever recruited.

The difference only becomes visible when a finding contradicts the expected direction. In genuinely exploratory research, a contradictory finding changes something. In confirmatory research, it gets reframed, deprioritised, or quietly dropped. The product still launches. The roadmap stays intact. And six months later, nobody connects the disappointing numbers to the research that could have warned them.

This distinction is more often glossed over than confronted directly, and it is worth being precise about how it happens and what it costs.

The Two Types of Research That Look Identical on a Slide

Exploratory app user research starts with a genuine question. The team does not know the answer, and the design of the study reflects that. The questions are open. The participants are recruited to represent real users, not to fill a demographic box that already matches the intended audience. The moderator is trained to follow unexpected threads rather than steer back to the discussion guide.

Confirmatory research starts with a conclusion. The team wants to know whether users will respond well to a feature that has already been decided on. Or they want data to support a pitch to investors. Or a senior stakeholder has a strong view and wants it validated. The research is designed, consciously or not, to produce the finding that is already expected.

Neither type announces itself on a methodology slide. Both will describe sample sizes, recruitment criteria, and question frameworks. Both will produce a findings deck. The structural difference is invisible unless you look at what happens when the data does not cooperate.

The Redirect Signal

One reliable indicator is what gets done with a finding that conflicts with the brief. In exploratory work, it gets examined. In confirmatory work, it gets explained away. "That participant wasn't typical." "That question was slightly misworded." "We'd need a larger sample before we could act on that." The rationalisation is always available, because every study has limitations. The question is whether those limitations are invoked selectively, only when the findings are uncomfortable.

How Confirmatory Research Gets Commissioned

Most confirmatory research is not commissioned deliberately. Nobody writes a brief that says "please find evidence to support what we have already decided." The process is subtler than that, and it usually begins with how the research question is framed.

A brief that asks "how do users respond to our new onboarding flow?" is structurally different from one that asks "what barriers do users encounter in their first session?" The first orients the research around a specific feature and implicitly positions user response as a variable to be measured against it. The second is genuinely open to finding that the onboarding flow is the wrong solution entirely.

Simon's observation from years of this work is direct. He has not seen a research process fail because of methodological weakness. Every case where findings were ignored traces back to a stakeholder who had already decided what they wanted to build, and who treated the research as a procedural step rather than a genuine input. No level of rigour in the documentation changes that dynamic, because the problem is not with the process.

The Budget Signal

Confirmatory research also tends to be under-resourced in ways that make challenging findings easy to dismiss. A small sample is convenient: it yields the signal the team wanted, and if something contradictory surfaces, the sample size becomes the reason not to act on it. Genuine discovery research is resourced to the point where findings are hard to ignore.

What the Data Actually Shows About Research Being Acted On

A 2022 survey by UserZoom and Ipsos found that approximately 72% of product decisions were made without user research informing them at all. That figure is not describing research that was conducted and then ignored. It reflects the scale of decisions that happen with no user data in the picture.

Among the organisations that do conduct research, the picture is not much more encouraging. According to Nielsen Norman Group, in lower-maturity organisations, startups and smaller companies, fewer than 20% of research findings result in a documented product change. Even in more established companies, that figure rises but does not reach 50%.

We tracked this pattern directly on one project, working on a product that had gone through multiple rounds of user research during development. Between funding rounds, we made the decision to implement much better tracking of user retention and to proactively solicit ongoing user feedback. The reason was straightforward: investor confidence had been functioning as a proxy for product readiness, and the actual health of user retention had not been properly understood. The research had been conducted. It had not been used to build a clear picture of whether users were staying.

The gap between conducting research and acting on it is structural, rooted in how the research was set up and what the organisation was prepared to hear.

The Signs Your Team's Research Was Built to Defend, Not Discover

There are several patterns that indicate research has been oriented around defending a position rather than discovering one. None of them are conclusive on their own, but a team that recognises three or four of these in the same project should take that seriously.

• The research question names a specific feature or solution rather than a user need or behaviour.
• Participant recruitment criteria closely mirror the product's intended audience in ways that exclude likely critics or edge cases.
• The discussion guide moves quickly past questions that could surface negative responses.
• Contradictory findings from the research are attributed to participant characteristics rather than product issues.
• The findings deck leads with positive responses and places concerns in an appendix.
• No finding in the readout leads to a decision to stop, reverse, or substantially change anything.

That last one is the strongest signal. Research that never produces a "no" or a "not yet" or a "this needs to be rethought" was almost certainly not designed to find one. Discovery work will always surface some proportion of findings that are uncomfortable to act on. If a research cycle produces only green lights, the brief was written to guarantee that outcome.

Before finalising a research brief, write down the finding that would most challenge the current product direction. Then check whether the study is actually designed to surface it. If the answer is no, revise the brief.

When the Founder Already Knows the Answer

Founders with deep domain knowledge are particularly susceptible to confirmatory research, and for understandable reasons. They have spent months or years building expertise in their sector. They have spoken to industry contacts. They have mapped competitors. That body of knowledge generates strong convictions about what users want, and those convictions feel earned because they are, in part, earned.

We worked on a communications product where the founder had very strong opinions about how the product should work, grounded in real sector experience. The research process became, in practice, a box-ticking exercise. When findings emerged showing that a large portion of the potential user base did not want particular features and actively preferred alternatives, the founder did not engage with those findings. The team walked away from the engagement. The product launched about a year later, largely unchanged, and by our account it did not find traction, for the same reasons the research had flagged.

What makes this pattern so persistent is that competitive analysis provides a form of validation that user research does not. A spreadsheet mapping competitor features cannot tell a founder their idea is wrong. A user interview can. The asymmetry in risk explains why founders so often invest heavily in the former and treat the latter as a formality.

When a founder presents strong competitive analysis, treat it as a starting point for user research rather than a substitute for it. The question is whether users want it.

How to Stress-Test a Research Brief Before the Work Begins

The most effective point at which to catch confirmatory research is before it starts. Once the methodology is set, the participants are recruited, and the discussion guide is written, the structural orientation of the study is fixed. Challenging it afterwards produces friction without changing the output.

A structured review of the brief before fieldwork begins should work through the following sequence.

1. Identify the research question and check whether it is oriented around a user need or around a specific solution the team has already developed.
2. Review the recruitment criteria and ask whether they would systematically exclude users likely to respond negatively.
3. Read the discussion guide and map which questions could surface a finding that would require stopping or substantially redirecting the work.
4. Ask the team to name the finding that would most challenge the current direction. Then check whether the study could plausibly produce it.
5. Establish in advance what the threshold is for acting on a challenging finding, what it would need to show, and at what sample size.

That fifth step is particularly worth doing with stakeholders present. Agreeing in advance on what would constitute actionable evidence removes the room for post-hoc rationalisation. If a finding meets the agreed threshold, it is harder to dismiss it on the grounds that the sample was too small or the participants were atypical.

Building the Conditions Where Challenging Findings Are Safe to Surface

Even when a research brief is well-designed, challenging findings can still fail to reach the people who need to act on them. The researcher knows what they found. The moderator heard what participants said. But by the time the readout reaches a senior stakeholder, the edges have been smoothed, the caveats have multiplied, and the recommendation has been softened into something easier to absorb.

Part of this is a natural social dynamic. Researchers do not want to be seen as obstructive. They have observed the investment a team has made in a direction, and they are conscious that their findings could disrupt it. So they frame things carefully. That carefulness, in aggregate, changes the finding.

The structural fix is to separate the role of surfacing findings from the role of recommending actions. A researcher whose job is to describe what participants said, accurately and without softening, is in a different position from a researcher who is also responsible for a recommendation the stakeholder will act on. When those roles collapse into one person, the pressure to make findings palatable becomes part of the job.

Our debrief process reflects this. We start by establishing what was tested and what the goals of the research were, then review who participated and how their feedback should be weighted. From there, we map each finding against business value and potential user uptake before any prioritisation decisions are made. The sequence keeps the reporting and the recommending distinct.

Build a standing rule that research readouts include a section where the researcher describes the findings in their own words, before any framing or prioritisation is applied. That unedited account is the one that should inform the conversation.

Why This Distinction Determines Roadmap Credibility

A roadmap built on confirmatory research carries a hidden liability. Every decision in it was made against a body of evidence that was designed to support it, which means the roadmap has never been genuinely tested. The team knows where they are going, but they have not established whether they should be going there.

That liability compounds over time. Early decisions shape later ones. Features built without genuine discovery create dependencies. And when the product meets real users at scale and the numbers tell a different story, tracing the problem back to its source is hard, because every decision in the history of the product was supported by research at the time.

We saw exactly this in our work on a dating app. Significant discovery had gone into onboarding, the verification and trust-building flows were thoroughly researched and carefully built. But the messaging feature received much less discovery attention and was built more generically. That gap created an internal contradiction: the onboarding was designed to prevent fake and automated accounts, but the messaging feature, built without the same rigour, allowed the exact behaviour the onboarding was meant to stop. The product was coherent in isolation at the feature level and incoherent as a whole.

A roadmap is only as credible as the research underneath it. According to a KPMG, 2021 survey, around 67% of executives reported ignoring computer-generated data because it contradicted their intuition. That self-reported figure describes a real pattern: intuition feels more trustworthy than data in the moment, especially when the data is inconvenient. Roadmaps that survive that pattern need research that was designed to be inconvenient from the start.

Conclusion

The distinction between research that informs and research that justifies is not always visible in the methodology. Both produce decks. Both cite participants. Both generate findings. What separates them is what happens when the data says something the team did not want to hear.

Getting this right is a structural and cultural problem. The brief needs to be written to allow challenging findings. The study needs to be resourced to produce them. The readout process needs to keep description and recommendation distinct. And the people receiving findings need to have agreed in advance on what evidence would be sufficient to change their direction.

We approach every engagement with that structure in place, because we have seen what happens when it is not. Projects where the research was thorough but treated as a formality, where the findings were real but the decision was already made, where the product launched on conviction and learned too late what discovery could have told them earlier and more cheaply.

Good research does not guarantee a good product. But research designed to discover, rather than to confirm, at least gives the product a chance of being built around what users actually need. That is the only condition under which the roadmap earns its credibility.

If you want to talk through how your current research process is set up and whether it is oriented to discover or to confirm, start that conversation with us.

Frequently Asked Questions