How to run research synthesis workshops that move cross-functional teams from raw data to aligned priorities in one session

Research teams frequently face the same frustrating pattern: weeks of careful interviewing and note-taking, followed by a slide deck that stakeholders skim and forget. The insights are sound, but they do not translate into product decisions because the people making those decisions were not involved in making sense of the data.

Research synthesis workshops address this gap directly. Instead of handing off a finished report, the researcher brings raw observations into a room with product managers, designers, and engineers, and the group works through the data together. Done well, the team leaves with a shared understanding of what users need and a clear sense of what to prioritize next.

This guide walks through the full process—from preparation to follow-up—so you can run a synthesis workshop that produces real alignment in a single session.

Why synthesis workshops work better than slide decks

The conventional research handoff—a polished deck or written report—has an inherent limitation. It separates the act of interpretation from the act of decision-making. The researcher interprets the data alone, then tries to persuade others to accept those interpretations.

This creates several problems:

• Stakeholders lack context. Reading a summary of an interview is not the same as grappling with the participant's actual words. Without that contact, stakeholders substitute their own assumptions.
• Priorities feel imposed. When recommendations arrive fully formed, product managers and engineers have no ownership over them. They may agree in principle but deprioritize the work in practice.
• Nuance gets lost. Slide decks flatten ambiguity. Complex or contradictory findings get smoothed over to create a clean narrative, which can lead to oversimplified product responses.

A synthesis workshop reverses this dynamic. Cross-functional team members handle the raw data directly, which forces them to confront what users actually said rather than what they expected to hear. The conclusions that emerge are co-owned, not handed down.

Preparing for the workshop

The quality of a synthesis workshop depends heavily on what happens before anyone enters the room. Preparation has two parts: curating the data and designing the session structure.

Curate observations, not conclusions

Before the workshop, the researcher should extract discrete observations from interview transcripts, notes, or recordings. An observation is a single, specific thing a participant said, did, or expressed—not a theme, not an interpretation.

Good observations look like this:

• "Participant 5 said she checks three competitor dashboards every morning because ours doesn't show trend data."
• "Participant 2 abandoned the onboarding flow at step 4 and said he didn't understand why his card was being charged before the trial ended."
• "Participant 8 described forwarding our report PDF to her VP every week because she couldn't share a live link with someone outside the account."

Bad observations look like this:

• "Users want better dashboards." (This is a conclusion, not an observation.)
• "Onboarding needs improvement." (This is a recommendation, not data.)

Write each observation on a separate sticky note—physical or digital. Aim for five to ten observations per interview. If you conducted 12 interviews, you might bring 60–100 observations to the workshop. That is a manageable volume for a group of six to eight people to work through in three hours.

If you use a tool like Dovetail to tag and organize interview data, you can pull observations directly from tagged highlights, which speeds up this preparation step considerably.

Pre-read materials

Send participants a brief pre-read 48 hours before the workshop. This should include:

• The research questions the study set out to answer
• A list of participants with one-line descriptions (role, company size, use case)
• A reminder that the workshop is about interpretation, not presentation—they will be working, not watching

Do not send conclusions or themes in advance. The point of the workshop is to build those together.

Set up the space

For in-person workshops, you need a large wall or whiteboard surface, sticky notes in at least three colors, dot stickers for voting, and markers. For remote workshops, use a digital whiteboard tool with enough canvas space for clustering. Either way, test the setup before the session begins.

Running the session

A well-structured synthesis workshop moves through four phases: orient, cluster, interpret, and prioritize. Each phase serves a distinct purpose, and skipping any of them weakens the outcome.

Phase 1: Orient (20 minutes)

Open the session by restating the research questions and briefly describing who was interviewed and why. Keep this short—five minutes at most.

Then give every participant 15 minutes to silently read through the observations. If you are working in person, spread the sticky notes across a table or wall so people can move around and read at their own pace. If you are working remotely, give everyone access to the board and ask them to read without commenting.

This quiet reading period is essential. It ensures everyone has direct contact with the data before any discussion begins. Without it, the most confident voice in the room will shape the group's interpretation before anyone else has had a chance to form their own.

Phase 2: Cluster (45–60 minutes)

Ask the group to start moving observations into clusters based on similarity. The instruction should be simple: "Group observations that seem to be about the same thing." Do not provide category labels in advance—let the clusters emerge from the data.

A few facilitation guidelines make this phase productive:

• Anyone can move any sticky. If someone disagrees with a grouping, they can move the observation to a different cluster or create a new one. No one owns a cluster.
• Duplicates are fine. If an observation seems to belong in two clusters, write a copy and place it in both.
• Work silently at first. Give the group 15–20 minutes of silent clustering before opening discussion. This prevents premature consensus and ensures introverted team members contribute equally.
• Name clusters last. Once the group has settled into a relatively stable arrangement, ask them to write a short label for each cluster. The label should describe the pattern, not prescribe a solution. "Users lack visibility into usage trends" is better than "Build a trends dashboard."

You will typically end up with eight to fifteen clusters. Some will be dense and clearly important. Others will have only one or two observations and may represent edge cases or areas that need more research.

Phase 3: Interpret (45–60 minutes)

This is the most intellectually demanding phase and the one that generates the most value. For each major cluster, the group discusses three questions:

1. What is actually happening here? What pattern does this cluster represent? Is it a workflow problem, a missing capability, a misconception, or something else?
2. Why does it matter? What is the consequence for users? What is the consequence for the business?
3. What don't we know? Where is the data thin or ambiguous? What follow-up questions does this raise?

The researcher's role during this phase is to add context that the raw observations may not capture—body language, emotional tone, things participants said off-camera. This is where having the researcher in the room (rather than just their report) becomes indispensable.

Document the group's interpretation for each cluster on a shared surface. A simple format works well:

• Theme: One-sentence description of the pattern
• Evidence strength: Strong (consistent across many participants), moderate (present but not universal), or emerging (based on a few data points)
• Implication: What this means for the product or business

Phase 4: Prioritize (45–60 minutes)

The final phase translates themes into priorities. This is where the cross-functional composition of the group pays off—engineers can speak to feasibility, product managers can assess strategic fit, and designers can evaluate whether a theme suggests a UX overhaul or a small interaction fix.

A simple prioritization exercise works best under time pressure. Give each participant five dot votes (physical stickers or digital equivalents) and ask them to place their votes on the themes they believe the team should address first. They can distribute votes however they like—all five on one theme if they feel strongly, or spread across several.

After voting, discuss the results. The vote itself is not a final decision; it is a conversation starter. Themes that receive broad support are natural candidates for the next planning cycle. Themes where votes are concentrated among a subset of the group (e.g., only engineers or only the PM) may indicate misalignment worth exploring.

End the session by documenting three to five clear priority statements. Each should name the theme, explain why it matters, and indicate a rough scope—is this a quarter-long initiative, a quick fix, or a topic for further research?

Common mistakes and how to avoid them

Inviting too many people

Groups larger than eight tend to fragment. Side conversations form, clustering takes twice as long, and prioritization becomes a negotiation rather than a discussion. If more than eight people need to be involved, consider running two separate workshops with different groups and then reconciling the outputs.

Jumping to solutions during clustering

It is natural for product-minded people to start generating solutions the moment they see a pattern. The facilitator needs to gently redirect this energy: "That is a great idea—let's capture it in the parking lot and come back to it during prioritization." Solutions generated before the group has fully interpreted the data tend to be shallow.

Treating the workshop output as a final answer

A synthesis workshop produces directional alignment, not a validated product roadmap. The priority statements that come out of the session still need to be evaluated against business constraints, technical architecture, and data from other sources. Frame the output as "what we believe is most important based on this research" rather than "what we are definitely building next."

Skipping the documentation step

If no one writes up the results within 24 hours, the shared understanding built during the workshop decays rapidly. Assign someone—usually the researcher—to produce a concise summary: the themes, the evidence behind each, the priority ranking, and any open questions. Distribute it to all participants and relevant stakeholders the next day.

Tools like Dovetail can help here by connecting workshop outputs back to the original tagged data, so anyone reviewing the summary can trace a priority statement all the way back to the specific interview moments that informed it.

Adapting the format for remote teams

Remote synthesis workshops require a few adjustments but can be equally effective:

• Use a digital whiteboard with structured zones. Set up clearly labeled areas for raw observations, clustering space, interpretation notes, and the parking lot before the session begins.
• Extend the silent phases. Reading and clustering take slightly longer when participants are working on screens rather than standing in front of a wall. Add five to ten minutes to each silent phase.
• Use breakout rooms for interpretation. If the group is larger than six, split into pairs or trios to discuss two or three clusters each, then reconvene to share interpretations with the full group. This prevents the session from becoming a series of monologues.
• Record the session. Remote workshops generate fewer physical artifacts. Recording the discussion ensures that context and nuance are preserved for the documentation step.

What happens after the workshop

The workshop is not the end of the synthesis process. It is the point where synthesis transitions from a research activity to a product planning input.

Within 48 hours, the researcher should produce a short written summary that captures the themes, priorities, and open questions from the session. This document serves as the connective tissue between research and the product backlog.

Product managers can use the priority statements to write problem-framed briefs or create backlog items. Designers can reference the clustered observations when exploring solution concepts. Engineers can review the themes to flag technical constraints or opportunities early.

If the workshop surfaces significant open questions—themes where the evidence was thin or contradictory—those become inputs for the next research cycle. This creates a feedback loop where each round of research builds on the shared understanding established in prior workshops.

Building synthesis into your research practice

Running a single synthesis workshop can feel revelatory for teams accustomed to the readout-and-forget pattern. But the real value comes from making synthesis workshops a regular part of how your team operates.

When cross-functional teams routinely participate in making sense of user data, several things change. Product decisions get grounded in evidence rather than opinion. Researchers spend less time selling their findings and more time deepening them. And alignment stops being something you chase after the fact—it becomes a natural byproduct of how the team works together.

The format described here is a starting point. Adapt the timing, the exercises, and the group composition to fit your team's context. What matters is the underlying principle: bring the people who make product decisions into direct contact with the data that should inform those decisions, and give them a structured way to make sense of it together.

Most effective synthesis workshops run between three and four hours. Anything shorter tends to force the team to rush through clustering and prioritization, which undermines alignment. Anything longer leads to fatigue and diminishing returns. If you have a large volume of data—more than 20 interviews, for example—consider having the researcher pre-cluster observations into themes before the workshop so the group can focus its time on interpretation and prioritization rather than raw sorting.

Invite people who will directly influence the product decisions that follow. This typically includes the product manager, one or two designers, an engineering lead, and the researcher who conducted the interviews. Adding a stakeholder from marketing, customer success, or sales can be valuable when the research touches go-to-market or retention questions. Keep the group between five and eight people. Smaller groups lack sufficient perspective diversity; larger groups make consensus difficult and slow down exercises.

A readout is a one-directional presentation where the researcher shares findings and recommendations with stakeholders. A synthesis workshop is a collaborative working session where the team collectively interprets data, debates meaning, and arrives at shared conclusions. Readouts are efficient for communicating finalized insights, but they do not build the shared understanding that drives alignment. Workshops require more preparation and time, but they produce stronger buy-in because every participant has a hand in shaping the outcome.