
Research repository - How NOT to fail
About
How often have you been told that investing in a research repository isn’t worth it? Undoubtedly, this is a hot topic in the ResearchOps community, and many companies are struggling with knowledge management. At Appfire, we established a research repository to track, analyze, and summarize our findings while working on the BigPicture PPM app. We’d be happy to discuss our results with anyone considering how to centralize their data meaningfully. We’ll walk you through our process for creating such a repository and all the problems and challenges we encountered.
Watch the full talk
Watch this WaysConf session, then continue with related talks or explore the current programme.
Talk in brief
A research repository creates value only when its taxonomy, contribution rules, and communication habits match how an organization uses evidence. This Polish-language case study follows a product team from scattered qualitative studies to a tagged repository that supports discovery, evaluation, and cross-team learning. It explains how to start with existing questions, evolve navigation tags through hands-on use, distinguish jobs and responsibilities, attach source evidence to insights, and invite other knowledge producers without sacrificing shared standards.
Key takeaways
- 01
Define the repository by the work it supports
A repository can be any organized evidence store; its usefulness depends on helping teams answer recurring product questions rather than its software.
Watch from 1:56 - 02
Start from real organizational questions
Requests about users, needs, and product gaps reveal which research outputs should be discoverable first.
Watch from 6:56 - 03
Let taxonomy emerge through use
Initial tags should be tested against real studies and revised when researchers cannot navigate or retrieve evidence reliably.
Watch from 12:16 - 04
Store evidence beside each insight
Video, transcript fragments, study context, and discussion make an insight easier to trust and reuse without losing its origin.
Watch from 28:26 - 05
Scale contribution with shared rules
Other teams can add knowledge when definitions, metadata, ownership, and quality expectations remain consistent.
Watch from 33:59
Video chapters
- 1:56What counts as a research repository
The repository is defined as an organized place for evidence, metadata, and research outputs.
- 6:56Questions that created the need
Growing qualitative research and repeated product questions expose the cost of scattered knowledge.
- 12:16Building the first taxonomy
Project tags become the starting point for a navigable organizational structure.
- 17:29Learning from a repository hackathon
Hands-on population reveals missing navigation tags and ambiguous categories.
- 22:47Jobs and responsibilities as a core category
User work and intended product use provide a durable way to organize findings.
- 28:26Evidence, comments, and insight circulation
Source fragments and collaboration features help teams inspect and discuss findings.
- 33:59Opening contribution beyond researchers
The repository expands to other knowledge producers under the same quality rules.
Read edited transcript highlights
These concise notes were edited from automatic captions and checked against the talk structure. They are not a verbatim transcript.
A repository is an organizational capability
The tool is not the defining feature of a research repository. A drive, database, specialist platform, or even a physical archive can play the role if it stores evidence and metadata in a way that supports retrieval and reuse. The real design problem is creating a shared memory that helps people answer product questions without repeating the same investigation.
Watch from 1:56Repeated questions reveal the information architecture
As qualitative research increased, product teams repeatedly asked who their users were, what mattered to them, where the product failed, and how concepts performed. Those requests became evidence for the repository’s structure. Rather than inventing categories in isolation, the researchers used the organization’s actual questions to decide what needed to be visible.
Watch from 6:56Taxonomy improves when people try to retrieve evidence
A focused repository-building session quickly exposed weaknesses in the first tag set. Broad project labels were not enough; people needed navigational tags that described reasons for use, collaboration, and other recurring contexts. The lesson was to treat taxonomy as a product that is tested and revised, not as a one-time classification exercise.
Watch from 17:29An insight needs its source and conversation
A reusable insight should retain the evidence behind it, including relevant video or transcript fragments and study context. Visibility and comments show whether others have examined the finding and allow designers or product partners to ask for clarification. That connection prevents concise summaries from becoming unsupported statements detached from the research.
Watch from 28:26Broader participation still needs governance
Researchers are not the only people who generate customer knowledge. Product, support, sales, and other teams can contribute, but expanding access should not produce a second wave of disorder. Shared metadata, definitions, review expectations, and ownership allow contribution to scale while preserving the repository as a dependable source.
Watch from 33:59

![Photo of Iga Mościchowska, UX consultant and trainer at WITFLOW & [ation] center](https://cdn.sanity.io/images/f4b7shkz/production/1d1cd68b3c41006e2ed46515604f853887df5776-1365x2048.jpg)
