How to structure a research repository for multi-product organizations

Research repositories solve a straightforward problem: they give teams a way to store, organize, and retrieve research findings so that past work stays useful instead of gathering dust in someone's Google Drive.

For organizations that manage a single product with a small research team, the structure of a repository can be relatively simple. But when an organization operates across multiple products, business units, or customer segments, structuring a repository becomes a genuine design challenge. The wrong structure makes insights hard to find, discourages contribution, and ultimately means teams repeat research that has already been done.

This guide covers how to think about repository structure when your organization has multiple products in play—and how to set things up so the repository actually gets used.

Why multi-product organizations need a different approach

A single-product company can often get by with a flat or lightly categorized repository. Studies are organized by date or project, and because everyone is working on the same product, context is shared and search is manageable.

Multi-product organizations face a different set of challenges:

• Overlapping customer segments. The same customer might use multiple products, and research conducted by one team may contain insights relevant to another.
• Inconsistent terminology. Different product teams may use different words for the same concept, making search unreliable.
• Scale. The volume of studies, interviews, and data grows faster. Without deliberate structure, the repository becomes a dumping ground.
• Competing priorities. Each team optimizes for their own speed and workflow, which can lead to fragmented systems if there is no shared approach.

The goal of a well-structured multi-product repository is not to impose rigid process on every team. It is to create enough shared structure that insights are findable across boundaries while giving individual teams the flexibility they need to work efficiently.

Choosing a structural model

There are three common approaches to structuring a research repository in a multi-product organization. Each has tradeoffs.

Centralized repository

All research goes into a single repository with a shared taxonomy. One team—usually a central research ops or insights team—owns the structure, tagging conventions, and governance.

Works well when: The organization has a dedicated research operations function, product teams share many of the same customers, and leadership values cross-product insight.

Risks: Can feel slow or bureaucratic to individual teams. Requires sustained investment in governance. If the taxonomy is too rigid, teams will work around it.

Federated repository

Each product team maintains its own workspace within a shared platform. Teams have autonomy over how they organize their own research, but they follow a minimum set of shared conventions—such as consistent tags, participant metadata, and a common problem-space taxonomy—that make cross-team search possible.

Works well when: Product teams are relatively autonomous, operate in different domains, or have different research maturity levels. The federated model balances flexibility with discoverability.

Risks: Requires clear agreement on what the shared conventions are and someone accountable for maintaining them. Drift is common without lightweight governance.

Decentralized (separate repositories)

Each product team uses its own repository with no shared structure or platform.

Works well when: Products are genuinely unrelated, serve completely different markets, and have no shared customers or strategic overlap.

Risks: This is rarely the right model. Even organizations with diverse product portfolios usually benefit from some cross-pollination. Decentralized repositories almost guarantee duplicated research and missed insights.

For most multi-product organizations, the federated model is the most practical starting point. It respects team autonomy while creating the conditions for cross-product learning.

Designing your taxonomy

Taxonomy is the backbone of any research repository. In a multi-product context, the taxonomy needs to do two things at once: help individual teams find their own research quickly, and help anyone in the organization discover relevant insights across products.

Shared dimensions

Establish a set of dimensions that every team uses when tagging or categorizing research. These typically include:

• Product or product area. Which product does this research relate to? Allow multi-tagging for studies that span products.
• Customer segment. Who was this research about? Use a shared segmentation model rather than letting each team define their own.
• Research type. Was this evaluative, generative, competitive, foundational? A consistent set of research types makes it easier to assess what kinds of knowledge exist and where there are gaps.
• Topic or theme. What subject area does this research address? Topics like onboarding, pricing, accessibility, or performance might span multiple products.
• Status. Is this study in progress, complete, or archived?

Team-specific dimensions

Beyond the shared taxonomy, allow teams to add their own tags or fields for concepts that are specific to their domain. A payments product team might tag research by transaction type; a communications product team might tag by channel. These team-specific dimensions add granularity without cluttering the shared taxonomy.

Keep it as simple as possible

The most common mistake in taxonomy design is overengineering it. A taxonomy with 200 tags will not be used consistently. Start with the minimum set of shared dimensions that enable cross-product search, then expand based on actual need. Audit your tags periodically—if a tag is never used, remove it. If the same concept is tagged three different ways, consolidate.

Structuring workspaces and projects

Within your repository, you need a consistent way to organize the containers that hold research. The specifics depend on your tooling, but the general principle is to separate the organizational unit (who owns this) from the research unit (what was studied).

Workspaces by product or team

Give each product team a workspace or top-level folder. This is their home base—where they create projects, store raw data, and manage their day-to-day research. It should feel like their space, not a shared commons they are borrowing.

Projects by study

Within each workspace, organize research by study or project. Each project should represent a discrete piece of research—a usability study, an interview series, a survey, a diary study—and contain all the artifacts related to it: raw notes, recordings, transcripts, analysis, and the final synthesis or report.

Cross-product collections

Create a separate layer for cross-product views. These are curated collections or saved searches that pull together insights from across workspaces based on shared tags. For example, a collection called "Onboarding insights" could aggregate findings about onboarding from every product team, regardless of when or where the research was conducted.

This separation is important. Teams work in their own workspaces, but the organization learns through cross-product collections.

Managing insights vs. raw data

A research repository holds two fundamentally different things: raw data (interview transcripts, session recordings, survey responses) and synthesized insights (tagged findings, themes, recommendations). The structure needs to support both without conflating them.

Raw data

Raw data should be stored within the project where it was collected. It needs to be searchable, but it does not need to be browsable to the entire organization. Most people are looking for synthesized insights, not raw transcripts from a study another team ran six months ago.

Synthesized insights

Insights are the primary unit of value in a repository. An insight is a discrete finding—tagged with metadata from your taxonomy—that can stand on its own outside the context of the study that produced it. Good insights include enough context to be understood without reading the full report: what was found, who it applies to, how confident you are in the finding, and where the supporting evidence lives.

When insights are properly tagged and separated from raw data, they become the building blocks of institutional knowledge. Teams can search for insights about a specific customer segment or topic and find relevant findings from across the organization, not just from their own studies.

Tools like Dovetail are designed around this distinction. They allow teams to analyze qualitative data within individual projects and then surface tagged insights across the entire repository, making it possible to see patterns that no single team would notice on their own.

Governance without bureaucracy

A repository that nobody maintains will decay. Tags drift, naming conventions break down, and teams stop contributing because they cannot find anything. But heavy-handed governance—requiring review committees or mandatory training—creates friction that kills adoption.

The right level of governance for most multi-product organizations includes:

A repository owner

Assign one person (or a small team) accountability for the health of the repository. This is often a research operations specialist or a senior researcher. Their job is not to police contributions but to maintain the taxonomy, onboard new teams, monitor adoption, and resolve structural issues.

Lightweight contribution guidelines

Document the minimum expectations for adding research to the repository. This might include: every project needs a title, product tag, customer segment tag, and at least one synthesized insight. Keep the guidelines to a single page.

Periodic taxonomy reviews

Schedule a quarterly review of the taxonomy. Look at which tags are used frequently, which are never used, and where inconsistency has crept in. Involve representatives from each product team so the taxonomy reflects how people actually think about their work.

Onboarding for new teams and researchers

When a new team or researcher joins the organization, walk them through the repository structure and contribution expectations. This 30-minute investment pays for itself many times over in consistent, findable research.

Getting teams to adopt the repository

Structure and governance matter, but the repository only works if people use it. Adoption in multi-product organizations is usually the hardest part—not because people disagree with the idea, but because contributing to a shared repository feels like extra work on top of an already full plate.

A few practical strategies help:

Reduce the cost of contribution. The less work it takes to get research into the repository, the more likely it is to happen. If your repository tool integrates with the platforms teams already use for note-taking, transcription, or synthesis, the barrier drops significantly.

Show the value of cross-product search early. Find a concrete example where one team's research answered a question another team was about to investigate separately. Share this story widely. Nothing builds adoption like a visible example of time saved or a decision improved.

Make the repository part of the research workflow, not an afterthought. If adding to the repository is a final step done after a project is complete, it will be skipped when deadlines are tight. Instead, structure the workflow so that data goes into the repository as research happens—during analysis, not after delivery.

Get leadership buy-in. When product leaders and executives reference repository insights in their own decision-making, it signals that the repository is not just a research team initiative but an organizational asset.

Common mistakes to avoid

Building the taxonomy in isolation. A taxonomy designed by one team and imposed on others will not reflect how those teams think or work. Co-design the shared dimensions with representatives from every product team.

Treating the repository as an archive. If the repository is only a place to store finished reports, it will not be searched or maintained. The repository should be a living system that supports active analysis and ongoing synthesis.

Over-investing in tooling before defining structure. No tool will compensate for a poorly defined taxonomy or unclear governance. Get the structural decisions right first, then choose tooling that supports them.

Ignoring participant and consent management. In a multi-product organization, the same participant may be interviewed by multiple teams. The repository should track participant interactions to prevent over-contacting and to ensure compliance with consent agreements.

Summary

Structuring a research repository for a multi-product organization requires deliberate decisions about taxonomy, workspace organization, governance, and adoption. The federated model—shared conventions with team-level autonomy—works well for most organizations. A consistent taxonomy with a small number of shared dimensions enables cross-product discovery without burdening individual teams. And lightweight governance, combined with visible value and low contribution friction, is what turns a repository from a well-intentioned project into an organizational habit.

The payoff is significant. A well-structured repository means researchers spend less time re-doing work that has already been done, product teams make decisions with the full breadth of available evidence, and the organization builds compounding knowledge instead of letting insights evaporate between projects.