Start with the stakeholders, not the report

There is good reason to think more carefully about this. In our Research Effectiveness Review 2026, based on the views of more than 1,000 client-side research stakeholders across the UK and US, senior leaders were 1.57x more likely than specialists to describe their organisation's research as highly effective.

There are several possible reasons for that gap, but it raises an interesting question: are we paying enough attention to how research is experienced by different people across the organisation?

Stakeholder mapping shouldn't just tell us who needs to be involved in the research; it should tell us what each of those people will eventually need from it.

Before the methodology has been finalised, it is worth establishing who will use the research, the decisions they are trying to make and, crucially, what they will need in their hands afterwards. For one team that might be a clear set of priorities; for another, the language customers naturally use; for another, the commercial implications distilled into a handful of decisions.

Thinking about those needs upfront also means the research can be designed to capture what each audience will eventually require, rather than reaching the end of a project with one comprehensive report and trying to make it work for everyone. If a communications team will need authentic customer language, for example, the research needs to capture it; if a product team will need to prioritise different features or experiences, the research needs to give them the evidence to make those trade-offs.

Adoption starts at the brief, not the debrief.

One research project doesn't need one research output

For years, the industry has talked about shortening the enormous research deck, but simply turning 100 slides into 30 doesn't necessarily make the research any more useful. The more important question is what each stakeholder actually needs to do their job.

Take a hypothetical piece of research exploring how people experience a new product or service. The underlying insight may be the same, but different teams will need different aspects of that learning brought to the fore if they are going to use it.

A context map could show the moments and situations in which people's needs change, while a language bank could capture the words they naturally use to describe their experience, giving communications and creative teams language grounded in the customer rather than the organisation.

For product teams, signal prioritisation could highlight the features, cues or experiences that matter most, while a relationship map could show how different needs, perceptions and behaviours interact. The same findings could feed a messaging framework that helps marketing translate the insight into communications, or a consumer mood board that brings the emotional context behind the findings to life.

The point isn't to create six deliverables where previously there was one, but to recognise that the report is only one possible expression of the insight. Sometimes the most useful output will be a report; sometimes it will be a framework, tool, language bank or visual that allows a team to put the learning to work.

The format should follow the application, not the other way around.

Design for adoption from the outset

Designing research for adoption doesn't mean simplifying everything until every audience receives the same three bullet points. It means preserving the quality and integrity of the insight while thinking more deliberately about how different teams will put it to work.

It's one of the wider questions raised by our Research Effectiveness Review Digest: when we assess whether research is working, are we looking far enough beyond the quality of the research itself to what happens once it enters the organisation?

If adoption is part of the ambition, a useful place to start is with six questions:

The research adoption checklist

1. Who will use this research? Map the important stakeholder groups, not only the person commissioning the project. ‍

2. What decisions do they need to make? Be specific about what the research should enable, change or clarify.

3. What will they need from the research? Identify where stakeholder needs overlap and where they differ.

4. Does the research design capture it? If teams will need language, priorities, behaviours or contextual cues later, make sure the methodology can uncover them.

5. What is the most useful output for each audience? Decide where a report is enough and where a framework, language bank, prioritisation tool, map or other format would make the insight easier to apply.

6. What happens next? Agree who owns the next step and how you will know whether the research has actually influenced a decision or action.

The report shouldn't be the finish line

There is a natural sense of completion when the final presentation has been delivered: the fieldwork is finished, the analysis is complete, the findings have been presented and the report has been circulated.

From an adoption perspective, however, that is when the next stage begins. Did the product team know what to prioritise? Did marketing have something they could apply? Did leadership make a more informed decision? Did the research challenge an assumption that had been shaping strategy?

Ultimately, what happened differently because the research existed?

That is a higher bar for research effectiveness, but it is also where much of its value lies. Research shouldn't be designed simply to produce a report that everyone receives; it should be designed around the people who need to use it, with the outputs shaped around the decisions and actions it needs to support.

The insight should remain consistent. How we help different stakeholders use it doesn't have to be.

‍