Denver 2026: themes of the day

The Insights Executive Retreat met on Wednesday 7th October 2026 at Bigsby's Folly in Denver, Colorado, the day after the main insights conference in the city. Roughly 50 senior insight, analytics and research leaders took part. It was invite-only and held under the Chatham House rule: anyone may take the ideas back to their team, but not the name or company attached to them. The day mixed talks, panel discussions, short presentations, table discussions and a closing round of proposals. These notes were written from a transcript of the day, made so that the host could write Chatham House compliant notes. They pool the day's thinking by theme, with no participant names, companies or account of who spoke when. Where a view belonged to one person, it's reported as one person's view.

What the room arrived with

The day opened with everyone saying, in a sentence, what was on their mind.

One cluster was the next generation. If the tools now do the grunt work, how will new people learn the craft? Several feared that cutting graduate and intern roles would hollow out the pipeline of future leaders. Others asked how to develop mid-level people when headcount won't grow.

A second was value and influence: proving the team's worth to senior leaders, and becoming real members of leadership teams rather than people who hand over reports. One participant, having fought hard for influence, worried about keeping it. Another saw the widespread confusion as an opening for insight to become the trusted expert.

A third was truth and quality: tools that discourage critical thinking, quick answers that aren't accurate, research fraud, synthetic audiences trained on the wrong data, distinctive insight flattened into generic answers, and self-proclaimed researchers appearing across the business. One participant wanted explicit standards for new methods. Another suspected the excitement was masking older, unsolved problems.

A fourth was organisational: moving from individual tool use to a whole workforce working differently, budget uncertainty, and growth in difficult markets. Two raised the consumer: people using tools they don't trust, and the risk of repeating social media's failures of representation and harm.

Not all of it was worry. Some were plainly excited about understanding people better and deciding better. The host's response to the round set the tone for the day: many of the answers already exist among the people present. They just aren't evenly distributed.

So what for your team

• Ask your team the same one-sentence question. Worries about careers, value and quality need different answers.
• Assume a peer has already solved part of your problem. The quickest route is often a conversation.

Start with the decision, not the method

A thread ran from the morning into the closing proposals: begin with the decision. One participant argued that research should start from an agreed decision and definition of success, and that both should be revisited when the business brief changes. The test is whether anyone acts on it.

Others turned this into practice. One suggestion was to redesign the brief so the decision comes first, then the time horizon and the risk of not doing the work, with methodology last. Another was to ask what it costs to decide without understanding customers, not only what research returns. Naming the cost of inaction, one participant found, also helped junior colleagues past their fear of automation.

One discussion tackled research commissioned after the decision has effectively been taken, sometimes to validate something a leader already loves. The advice was to make sure the work still teaches stakeholders something new, which opens the door next time, and to ask which part of the decision is truly settled, because implementation may still be open. The host recalled losing an argument about a campaign's creative but winning one about where the product would be sold. When one choice is fixed, move your influence to another.

How hard should insight push? One view was that researchers should challenge a decision thoughtfully and support its implementation once it's taken, because customer evidence is one input among several. The counterweight was candid: when the evidence feels strong, accepting a different decision is genuinely hard.

So what for your team

• Put the decision, deadline and definition of success at the top of every brief, and the method at the bottom.
• Name the cost of inaction, not only the return on research.
• When the big call is made, find the smaller call that's still open.

A seat at the table isn't influence

Why do senior insight leaders still talk about a seat at the table? One answer: the seat is necessary but not sufficient, because access doesn't confer influence. Another: influence depends partly on how well the organisation understands the function.

When stakeholders don't listen, one participant argued, look first at your own communication. Adapt to how each leader likes evidence: numbers, stories, video or a pre-read. Address what they value, because careful evidence that ignores what a decision maker cares about gets ignored in turn. Another argued for presenting everyday customer needs in terms that connect with leaders' ambitions.

Language matters. One view favoured framing research as learning rather than as a pass-or-fail test, and weighing consumer evidence alongside colleagues' expertise and where the brand wants to go: today's expectations should inform a brand's future without defining it. With creative colleagues, prescribing the answer rarely works. Explain the audience and the landscape, fix the objective, and invite them to find a better route to it.

More than one participant argued for bringing to colleagues the curiosity researchers bring to customers. Everyday warmth and interest in leaders' lives build trust that lasts years.

Most of the advice was about insight adapting to leaders. One participant called that one-way: leaders may also need to update an outdated view of what insight can do.

So what for your team

• Map how each key stakeholder likes evidence, and what they value.
• Replace pass-or-fail language with the language of learning.
• In creative decisions, fix the objective and leave the execution open.

Proving value

How should the function show its worth? One participant asked whether insight should commit to an expected financial outcome for each recommendation and then measure what followed. A separate suggestion was to prioritise requests by the size of the opportunity. Another widened the definition: value includes mistakes avoided and time, effort and money saved, not only revenue gained.

Not everyone accepted the return-on-investment frame. One participant challenged the reflex to demand a financial return for every project, arguing that understanding customers is fundamental. They wanted a better framing and said candidly they didn't yet know what it was. Another added that research changes how people work and sparks ideas, none of which attributes neatly to a number.

The risk is that others tell the story instead. One concern was that defining insight only as a data function could commoditise it. One participant described advisers and vendors warning senior leaders the insight team is outdated, then approaching that same team to sell a solution. Another argued that the sharper internal threat isn't technology teams but strategy teams armed with the same tools, so insight has to articulate the value of an objective customer perspective. Defending jobs, a third warned, is a weak argument with executives. The argument has to rest on capabilities and the decisions that drive growth, made by insight leaders who are in the room when the function's future is discussed.

So what for your team

• Decide how you'll show value before someone else does: committed outcomes, risk avoided, effort matched to opportunity.
• Argue for growth, not headcount, and watch strategy teams as closely as technology teams.

What should insight call itself?

Branding came back again and again, from the opening round to the closing proposals. On stage it was a short exchange. In the conversations around it, the host said at the close, it went deeper, and he called it a big thing he was taking away: how to describe what insight does, and how to position it to stakeholders.

The problem. The host put it to the room directly: the profession has a branding problem. "Insights" is a good word, but it describes knowledge, not action. Teams call themselves insights, analytics, strategy or still market research, as does the conference that hosts the retreat. With that spread of names, he said, it's hard to blame stakeholders for not knowing what insight teams do. One participant had asked the same question earlier in the morning: are we consumer insights, market research, or something broader about understanding people?

Why it has got harder. Two causes were offered. The first is that the word has escaped. Teams across the business now say they deliver insights, so leaders get "an insight" from several places and can't tell who owns it, or what separates an insight from data or a factoid. The suggested answer was to show the difference through the work. The second is that the job has moved underneath the name. One participant described the work shifting from conducting research towards influencing decisions now that data is abundant, and said they now recruit for interpersonal skills alongside data skills.

Our own worst enemy. One participant argued that the profession damages its own brand through its vocabulary. "Testing", and red, amber and green traffic lights, frighten marketers, creative directors and agencies; ask instead what they want to learn. Another label, the voice of the consumer inside the organisation, was offered as an alternative and questioned in the same exchange: it carries baggage too.

Renaming in practice. Some participants have renamed their teams or are doing so. One argued that a new team name needs sustained explanation of what the team is for. Another described moving their team's name away from "market research" to reflect a remit that has already widened, which means working out how the team's findings plug into other teams' work, and theirs into its own. A conversation at the break made the wider point: a rebrand is the start, not the change.

What a better brand would say. The suggestions pointed the same way. Describe the function by the decisions it improves and the action it provokes, not the knowledge or methods behind it. Present the team as builders, not only deliverers: research changes how people work, sparks ideas and widens the options a decision considers, and not all of that fits a return-on-investment case. One table's closing proposal joined the two halves: start by rebranding the function, then earn the name by staying involved through activation, as partners and co-creators, and by writing insight into the documents decisions already run on.

The room didn't settle on a name. The host left it as an important unresolved question.

So what for your team

• Ask five stakeholders what your team is called and what it does. The gap between their answers and yours is your brief.
• Audit your own vocabulary. Replace "test" and traffic lights with what the business wants to learn.
• If you rename, plan the explanation and change how the team works, or the new name won't stick.
• Describe the team by the decisions it improves, not the methods it uses.

Automation reaches the action

The tools no longer stop at information. A person used to act on the analysis; now the system can act. Some participants said their organisations had begun building agentic workflows. So who owns the decision when an automated action is wrong, or consequential in ways nobody intended?

One contribution argued that greater automation still needs human judgement, and that someone has to own the outcome.

A related worry was about what goes into the machine. One participant argued that automated workflows embed assumptions about how the business grows without anyone stating them, and should make those assumptions explicit and allow them to change. Another wanted a coherent account of how the business grows before anything is built on top of it. That's also the opportunity: insight teams could design the decision frameworks that data then feeds, and should get to know whoever is building the decision infrastructure.

The consumer may delegate too. If people hand their shopping to agents, researchers will need to understand how the agents decide, not only the people. One participant suggested that willingness to share personal data rises when the purpose and benefit are clear.

So what for your team

• Decide who owns the outcome of each automated decision that matters.
• Write down the growth assumptions inside your automated workflows, and revisit them.
• Start studying how agents choose on consumers' behalf.

The apprenticeship problem

A recurring worry came back all day. Much of the craft was learned through routine work: writing a report by hand forces a long series of small decisions, and that's where judgement was built. If the tools take the routine work, the learning goes with it unless someone replaces it on purpose. The host revised his own position at one table: leaders now have to teach judgement deliberately, possibly with the tools' help. Another view made the same point from the other side: automate the routine, but protect space for junior people to think, learn and contribute to strategy.

What should teams recruit for: storytelling, data science, technical fluency or research craft? The answers leaned to mindset over expertise. Curiosity about people still matters, but so does how candidates use the tools now and how they expect their work to change. A realistic task can show what an interview misses, and an ambitious personal project is good evidence of curiosity.

For the people already in the team, the suggestions were practical. Ask for the human thinking first, then use the tools to improve it, rather than accepting an unexamined generated draft. Let colleagues teach one another.

The tables disagreed on several points:

• Does the tool erode thinking or build it? One view held that people who already think critically use the tools well. The counter-view was that the tools can develop critical thinking if the person wants to think and is encouraged to, treating it as a dialogue rather than accepting the first answer.
• Who is harder to change? Two participants, in different discussions, put the real resistance with process-bound middle managers and long-tenured staff rather than juniors. Others worried that future entrants may need more help thinking independently, offered as a concern, not a demonstrated effect.
• Is this new? Two participants recalled the same anxiety when spreadsheets, dashboards and analytics arrived. Producing reports was never the mission; helping decisions was.

So what for your team

• List the judgement your juniors used to learn from routine work, and design a deliberate replacement for each piece.
• Ask for a human first draft before the tool's draft.
• Don't assume the resistance is generational. Look hard at the middle.

What people say and what they do

A methodological thread asked whether research measures actually help business decisions. A measure needs a clear link to commercial outcomes before anyone acts on it.

Two cautions belong here. One contribution recommended investigating why customer behaviour changed before settling on the obvious explanation: talk to the people whose behaviour changed, not the loudest voices. Another cautioned that a poor business decision doesn't establish whether research was absent or simply ignored.

Qualitative and emotional evidence also had defenders. One contribution argued that qualitative research can reveal motivations that numbers miss. Another held that more data doesn't mean more truth.

So what for your team

• Check that your most important measures connect to the decisions they are meant to inform.
• When behaviour shifts, talk to the customers who changed, not the loudest voices.

New methods, old standards

Views on synthetic and automated methods were finer than for or against. One participant found research-grade synthetic personas more faithful than a marketer pasting a report into a general tool, and useful for scenarios and narrowing options, with quality still to be checked. One suggestion was that time saved by the tools can go back into direct human research. Another was to combine human synthesis with tool-assisted checking, so that teams share a common starting point for decisions.

Sample quality remained contested. One contribution asked whether current alarm exaggerates a long-standing problem that responsible agencies already mitigate. Another urged checking findings against business knowledge: if a result makes no sense, question the sample. A third asked what, if anything, separates questioning synthetic personas from letting persona-tuned models answer a survey. Either way, it's essential to be explicit about how synthetic responses are used and declared.

Exploratory research, one contribution argued, can reveal emerging needs that structured questionnaires miss. Several described a shift from projects that end in a deck to continuous learning, which raises a practical problem: nobody can keep every deck current. One hope was a searchable evidence base, kept separate from the formats people use to reach it.

So what for your team

• Declare the source of every response: human, synthetic or tool-assisted.
• Use business knowledge as a quality check. If a finding makes no sense, interrogate the sample.
• Invest in a searchable evidence base rather than ever more decks.

Adoption is an organisation problem, not a tool problem

Are organisations automating all they could, or sitting on the fence? One view was that transformation stays incremental because leaders aren't bold enough to change ways of working or fight for budgets. Fear for jobs makes some people resist; legal and technology permissions also slow things down, though some of those barriers are receding. The host floated a radical option: have capable people rebuild a version of the organisation separately, with its own technology and legal arrangements.

Demonstrations alone don't guarantee lasting change. One participant described a large middle waiting to see practical success; the reply was that people can be impressed by a demonstration and still return to old habits. Gains also leak at the joins between teams, so one team sprinting ahead doesn't make the organisation faster. A quieter cost: the promise of doing more with the tools makes extra headcount harder to win.

Capability spreads through people. The host described winning over a sceptical senior figure by finding a use that mattered to them personally. One participant recommended informal peer exchange to spread practical uses of the tools.

So what for your team

• Change one whole workflow, handoffs included, rather than speeding up one team.
• Show results to the waiting middle, then build the new way into the working week.

Stop, start, protect

Tables were asked for one thing to stop, one to start and one to protect, and reminded that an interesting conversation isn't an action. What follows pools their reports. They were proposals from individual tables, not actions the whole room agreed.

Stop. Doing nothing to develop talent. Reactive behaviour, perfectionism and overthinking. Territorial fights over repeatable testing, which can be automated. Silos, and hoarding information as power.

Start. Rebranding the function, then earning the name. Becoming a source of growth ideas, not research activity. Staying involved through activation, as partners rather than suppliers. Writing insight into the documents decisions already run on, such as product requirements and marketing briefs. Mentoring, shadowing and exposure to good practice, especially where remote work hides how decisions are made. Room for younger people to fail safely and learn. Inviting junior colleagues to challenge existing work, with explicit permission to be bold.

Protect. Critical thinking, learning agility and data integrity. Rigour, credibility and objectivity as the role broadens. Bravery in difficult conversations. The team's own voice and the customer's, because the tools amplify whatever behaviour is already there.

So what for your team

• Run the exercise with your own team, and let the most junior name what should stop.
• Get insight written into one decision document the business already uses.

What was left open

The close was candid. Rising expectations of speed and scale weren't fully addressed. The human contribution, when the tools do so many tasks, wasn't settled. How to describe and position the function remained open, and the host called it a big thing he was taking away. In the host's summary, consumer evidence sits alongside stakeholder expertise, commercial reality and brand, and insight influences decisions without owning them. He found the balance of serious concern and practical answers encouraging.

If there is only one page

• Start with the decision, not the method, and count the cost of inaction.
• A seat at the table isn't influence: speak the decision maker's language, and fix objectives rather than executions.
• Show value before others define it.
• Insight has a branding problem. Name the function for the action it drives, and change the work, not just the label.
• As automation reaches the action, give every consequential decision a human owner and visible assumptions.
• If routine work no longer teaches judgement, teach it deliberately, and look hard at mid-career resistance.
• Make sure your measures inform decisions, and declare where every response came from.
• Adoption fails at the joins between teams. Change whole workflows, and spread capability person to person.