Your user research is worth millions. You can't find any of it.

A product team commissions a user research study for a major feature initiative. They conduct twenty interviews, run a survey with 500 respondents, do a competitive analysis, and synthesise the findings into a report. The research costs $30,000-$50,000 in researcher time and participant incentives. The insights are sharp, specific, and valuable. They inform the feature design, shape the roadmap, and justify the investment to stakeholders.

Six months later, a different product team is working on a related initiative. They need insights about the same user segment, the same workflow, the same pain points. They search the shared drive and don't find the previous study because it's titled with the original project's codename and filed in the original team's folder. They commission new research. The same interviews. The same questions. The same $30,000-$50,000.

This is duplicate work at its most expensive, because research is one of the highest-cost knowledge activities in a product organisation. The duplication happens because the research is findable during the project it was created for and invisible to everyone else, forever after.

Why research disappears

User research is typically organised by project rather than by theme. The "Q3 Enterprise Onboarding Discovery" folder contains everything related to that project: interview transcripts, survey data, synthesis documents, presentation slides. Finding something within that project is easy. Finding it from outside the project, when you don't know the project existed, is effectively impossible.

The researcher who conducted the study may have moved to another team or left the company. The synthesis document uses terminology specific to the original project. The folder is in the original team's shared drive, which other teams don't have bookmarked or don't have access to.

The knowledge existed. The investment was made. The retrieval failed because the research was organised for the people who created it rather than for the people who might need it later.

What a research repository looks like

A research repository that prevents duplication and makes past insights available for future decisions has three properties:

Searchable by theme and question, not by project. When a product manager searches "enterprise user onboarding friction," they should find every piece of research that touches that theme, regardless of which project generated it, when it was created, or which team commissioned it. Semantic search handles this because it finds by meaning rather than by filename or folder location.

Comprehensive across formats. Interview transcripts, survey results, usability test recordings, synthesis documents, annotated screenshots, competitor analysis, and customer feedback all belong in the same searchable library. A research repository that only covers formal studies misses the informal research (customer calls, support tickets, Slack conversations with clients) that often contains the most useful insights.

Connected to product decisions. Research insights are most valuable when they're linked to the decisions they informed. A decision record that cites the research it was based on, and a research finding that links to the decisions it influenced, creates a traceable chain from evidence to action.

Building the repository

The practical approach: connect the sources where research already lives into one searchable library.

Google Drive (where synthesis documents and presentations typically live), Slack (where research insights are discussed and shared), meeting recordings (where research is presented to stakeholders), and Notion (where some teams maintain research databases) all feed into one semantic search. The research stays where it was created. The search makes it findable from anywhere.

New research also enters the repository automatically through self-writing documentation. When a research debrief meeting is recorded and transcribed, the key findings become searchable documentation. When research insights are discussed in a Slack channel, they're captured alongside the formal synthesis.

Over months, the repository accumulates a rich, searchable body of user understanding that no single study could provide. The question asked in Q4 draws on insights from Q1, Q2, and Q3. The investment in past research compounds rather than depreciating.

Frequently asked questions

How do we encourage researchers to use the repository? The key design principle is that the repository should require no extra work to contribute to. If it's populated automatically from the tools and channels where research already happens (Google Drive, Slack, meetings), the contribution happens without anyone changing their workflow.

What about research quality? Not all research is equal. The repository should capture everything searchably but allow the team to flag the quality and methodology of different studies. A rigorous 500-person survey and an informal five-person interview set are both valuable but in different ways. The metadata helps the searcher evaluate the strength of the evidence.

How does this relate to product ops? Maintaining the research repository is one of the core functions of product ops. In teams without a dedicated product ops function, the repository needs to be largely self-maintaining, which is why the automated capture and search approach matters.

Related reading: How to build a product knowledge base, Duplicate work is the most expensive kind, The cost of scattered knowledge. Related pages: For user research, For product managers, Market research, Competitive research.