How to run a research program review to identify gaps, themes, and opportunities across past studies

Research teams accumulate a lot of knowledge over time. User interviews, usability tests, surveys, diary studies, concept evaluations—each project adds to a growing body of evidence about customers, products, and markets. But without a deliberate effort to step back and look at the full picture, that knowledge stays fragmented. Individual studies answer individual questions. The connections between them go unnoticed.

A research program review is the practice of examining your team's past work as a whole. The goal is to understand what you collectively know, where the gaps are, what themes keep surfacing, and where the biggest opportunities for future research lie. It turns a collection of isolated studies into a coherent body of knowledge that can inform strategy.

This guide walks through how to plan and run a program review, from assembling your catalog of past work to communicating findings to stakeholders.

Why program reviews matter

Most research teams operate reactively to some degree. Product teams request studies, researchers scope and execute them, findings are shared, and the team moves on to the next request. Over months and years, this produces a patchwork of insights—some areas deeply understood, others barely touched.

A program review addresses several problems that accumulate under this model:

Redundant research. Without visibility into what has already been studied, teams sometimes re-investigate questions that were answered months ago. This wastes time and erodes confidence in the research function.

Blind spots. Certain user segments, journey stages, or product areas may have received little or no research attention—not because they are unimportant, but because no one specifically requested it. A program review makes these blind spots visible.

Disconnected findings. A usability study in January, a survey in April, and a set of customer interviews in August may all point to the same underlying issue. But if no one examines them together, the pattern stays hidden and the insight never reaches the people who could act on it.

Weak strategic alignment. Research priorities should reflect business and product strategy. A program review reveals whether the work your team has done actually aligns with what the organization cares about—or whether effort has drifted toward lower-priority areas.

Step 1: Build a catalog of past research

Before you can analyze your body of work, you need to see it. The first step is assembling a complete inventory of the research your team has conducted over a defined time period—usually the past 12 to 24 months, though the right window depends on your context.

For each study, capture a consistent set of metadata:

Study title and date
Research question(s) — What was the study trying to answer?
Method — Interview, survey, usability test, diary study, card sort, etc.
Participant profile — Who was included? Which user segment, persona, or market?
Product area or feature — What part of the product or experience was under investigation?
Key findings — A brief summary (2–5 bullet points) of what the study concluded.
Stakeholder or requester — Who initiated or sponsored the research?
Status of recommendations — Were findings acted on, partially acted on, or not acted on?

If your team maintains a research repository, much of this information may already be documented. Tools like Dovetail can serve as a centralized home for research data, making it significantly easier to locate past studies, review tagged findings, and pull together the kind of structured overview a program review requires.

If you do not have a repository, you may need to gather this information from slide decks, reports, Confluence pages, or individual researchers' files. This is more labor-intensive, but the exercise itself is valuable—it often reveals just how scattered institutional knowledge has become.

Practical tip: Keep scope manageable

If your team has produced hundreds of studies, reviewing every one in detail is not realistic. Focus on studies that addressed core product areas, strategic user segments, or high-priority business questions. You can always expand the review later.

Step 2: Map research coverage

With your catalog assembled, the next step is to visualize where your research effort has been concentrated and where it has not.

Create a simple matrix or grid. One axis represents the dimensions you want to evaluate coverage against. Common axes include:

Product area or feature (e.g., onboarding, checkout, settings, notifications)
User segment or persona (e.g., new users, power users, enterprise admins)
Journey stage (e.g., awareness, activation, retention, expansion)
Research method (e.g., generative, evaluative, quantitative, qualitative)

Plot your studies onto this grid. The result is a visual map that immediately highlights concentrations and gaps.

You might discover that your team has conducted eight studies on the onboarding experience but none on what happens after a user's first 30 days. Or that enterprise users are well-researched but small-business users have never been studied directly. Or that nearly all your work has been evaluative usability testing, with very little generative or exploratory research.

These patterns are not inherently good or bad. Some concentration is appropriate—your team should spend more effort on high-priority areas. But the map gives you the information you need to assess whether the distribution of effort has been intentional or accidental.

Step 3: Identify recurring themes

Individual studies produce findings. A program review produces themes—patterns that emerge across multiple studies, methods, and time periods.

To identify themes, review the key findings from each study in your catalog and look for concepts, problems, or observations that appear repeatedly. Some questions to guide this analysis:

What user pain points have surfaced in more than one study?
Are there behaviors or mental models that multiple studies have documented?
Do certain feature requests or unmet needs appear across different segments?
Are there contradictions between studies that need resolution?

Group related findings together and give each cluster a descriptive label. These labels become your cross-study themes.

For example, you might find that across five different studies over 18 months, users consistently struggled with understanding pricing—during onboarding, during plan upgrades, and when evaluating the product against competitors. No single study framed "pricing comprehension" as a major finding, but in aggregate, the pattern is clear and significant.

Thematic analysis across a research program is structurally similar to thematic analysis within a single qualitative study, just at a higher level of abstraction. If your research artifacts are tagged and stored in a platform like Dovetail, you can search across projects for recurring tags, highlight clusters, and trace themes back to their source data—which makes this step considerably faster than working from disconnected documents.

Watch for weak themes

Not every recurrence is a meaningful theme. A finding that appears in two studies with small sample sizes and different contexts may not warrant the same attention as one that appears in six studies across multiple segments. Weight your themes by the volume and quality of evidence behind them.

Step 4: Surface knowledge gaps

Gaps are the inverse of themes. They are the important questions your research has not yet answered.

Some gaps will be obvious from your coverage map—entire product areas or user segments with no research. Others are more subtle. You may have studied a topic but only from one angle, or only with one method, or only at one point in time.

To surface gaps systematically, consider these prompts:

What questions do stakeholders keep asking that you cannot answer with existing research?
What assumptions is your product team operating on that have never been validated?
Which product areas have changed significantly since the last time they were studied?
Are there user segments whose needs are inferred from adjacent research rather than studied directly?
Where has the business strategy shifted in ways that outpace existing research coverage?

Document each gap with enough context that someone unfamiliar with the research program could understand why it matters. A gap is not just "we haven't studied X." It is "we haven't studied X, and this creates risk because Y."

Step 5: Connect findings to strategic priorities

A list of themes and gaps is useful, but it only becomes actionable when connected to what the organization is trying to achieve. This step is where the program review earns its strategic value.

Take your current product roadmap, company objectives, or strategic priorities—whatever framework your organization uses to define what matters—and map your themes and gaps against it.

Ask:

Which themes reinforce or challenge current strategic bets?
Which gaps represent the highest risk to current priorities?
Where does the organization lack the evidence it needs to make confident decisions?

This mapping transforms your review from an internal research exercise into a strategic document that product leaders, designers, and executives can engage with.

A theme like "users across segments consistently struggle with pricing comprehension" becomes far more compelling when connected to a strategic priority like "improve conversion from free to paid plans." A gap like "no research on the needs of IT administrators" becomes urgent when the roadmap includes an enterprise-tier launch in Q3.

Step 6: Prioritize future research opportunities

With themes, gaps, and strategic context in hand, you can now build a prioritized list of research opportunities—studies or initiatives that would address the most important unknowns.

Prioritize based on:

Strategic alignment — Does this research support a current organizational priority?
Evidence gap severity — How much risk does the current lack of knowledge create?
Feasibility — Can this research be executed with available resources and timelines?
Cross-functional demand — Are multiple teams asking for this knowledge?

The output of this step is not a rigid research roadmap. It is a well-reasoned case for where the research team's effort would create the most value. This gives research leads a strong foundation for planning conversations and resource allocation.

A program review is only as useful as its reach. If the findings stay within the research team, the exercise was worthwhile for internal planning but misses the larger opportunity to shape organizational thinking.

Prepare a summary document or presentation that includes:

A high-level overview of research activity (volume, methods, coverage)
The key themes identified across studies, with supporting evidence
The most significant knowledge gaps and their strategic implications
Recommended research priorities for the next planning period

Tailor the depth and format to your audience. Research team members may want the full thematic analysis. Product and design leaders may care most about gaps and recommended priorities. Executives may only need the strategic implications and a clear ask for resources.

Share the review in a format and location that allows people to revisit it. A living document in your research repository or knowledge base is more durable than a slide deck presented once in a meeting.

Common pitfalls to avoid

Treating the review as an audit of researcher performance. A program review evaluates the body of work, not the people who produced it. Frame it as a forward-looking strategic exercise, not a backward-looking evaluation.

Trying to review everything at once. If your catalog is large, scope the review to a specific time window, product area, or strategic theme. A focused review completed well is more useful than a comprehensive review never finished.

Skipping stakeholder input. Researchers see the research landscape clearly, but stakeholders see the decision landscape. Their input on which gaps matter most is essential for producing actionable recommendations.

Letting the review gather dust. Schedule a follow-up to revisit the findings after one or two quarters. Did the recommended research happen? Did new themes emerge? A program review is most valuable as a recurring practice, not a one-time event.

Building the habit

Running a research program review for the first time takes real effort—cataloging past work, mapping coverage, synthesizing themes. But each subsequent review becomes easier, especially if your team maintains consistent documentation practices and uses a centralized platform to store and tag research findings.

Over time, the program review becomes a natural part of how a research team operates: a regular checkpoint that ensures individual studies add up to something larger than the sum of their parts. It helps research leaders articulate the value of their team's work, advocate for resources, and ensure that the questions being asked are the ones that matter most.