What This Template Is For
Most product teams do research and then lose it. Interview notes live in someone's Google Drive. Survey results sit in a Typeform dashboard. Usability test recordings gather dust in a Loom folder. Six months later, a new PM asks "What do we know about how enterprise users handle permissions?" and nobody can find the answer, so they run the research again.
A research repository is a centralized, searchable archive of research findings. Not raw data (transcripts, recordings, survey CSVs), but synthesized insights: what you learned, how confident you are, and what it means for the product. The repository turns research from a one-time event into a cumulative asset that gets more valuable over time.
This template provides the structure for building a research repository. It covers the taxonomy (how to categorize and tag findings), the insight card format (a standardized way to document each finding), the linking system (connecting insights to product areas, user segments, and original research), and the governance model (who adds entries, how quality is maintained, and how the repository stays current).
The repository sits at the center of your discovery practice. Every customer interview, usability test, survey, and benchmarking study should produce entries here. The Product Discovery Handbook describes how the repository integrates into the continuous discovery cycle.
When to Use This Template
- When you have more than 2 PMs. A single PM can keep research in their head. Two or more PMs need a shared system.
- When research is being repeated. If you have heard someone say "I think we studied that last year but I can't find it," you need a repository.
- When onboarding new team members. A repository lets new PMs, designers, and engineers absorb months of accumulated user knowledge in days instead of starting from scratch.
- When stakeholders question research-based decisions. A repository provides a citation system. Instead of "Users told us X," you can say "Interview series #12 (Jan 2026, 8 participants) consistently found X. Here is the insight card with supporting quotes."
- When scaling a research program. As research volume increases, the cost of unorganized findings grows faster than the volume. A repository prevents knowledge loss.
How to Use This Template
- Choose a tool. Notion, Dovetail, Airtable, or Confluence all work. The tool needs: searchable text fields, tags/filters, and linked records.
- Set up the taxonomy. Define your product areas, user segments, research types, and confidence levels.
- Create the insight card template. Every finding gets a card. Standardize the format so entries are consistent regardless of who writes them.
- Backfill key findings. Start by adding the 10-15 most important findings from the past year.
- Establish the habit. After every research activity, the researcher adds 2-5 insight cards within one week.
The Template
Part 1: Repository Setup
| Field | Details |
|---|---|
| Repository Name | [e.g., "[Product] Research Repository"] |
| Tool | [Notion / Dovetail / Airtable / Confluence / Other] |
| Owner | [ResearchOps lead, PM lead, or designated researcher] |
| Contributors | [Who has write access? Typically all PMs, designers, and researchers.] |
| Viewers | [Who has read access? Typically the full product and engineering org.] |
| Review Cadence | [Monthly quality review of new entries recommended] |
Part 2: Taxonomy
Define the classification system. Every insight card is tagged with these dimensions.
Product Areas
| # | Product Area | Description |
|---|---|---|
| 1 | [e.g., Onboarding] | [First-run experience, signup, initial setup] |
| 2 | [e.g., Core Workflow] | [Primary value-delivery workflow] |
| 3 | [e.g., Collaboration] | [Team features, sharing, permissions] |
| 4 | [e.g., Reporting] | [Analytics, dashboards, exports] |
| 5 | [e.g., Admin / Settings] | [Account management, billing, configuration] |
| 6 | [e.g., Integrations] | [Third-party tools, APIs, webhooks] |
| 7 | [e.g., Mobile] | [Mobile app experience] |
User Segments
| # | Segment | Description |
|---|---|---|
| 1 | [e.g., New Users (< 30 days)] | |
| 2 | [e.g., Power Users (daily, 50+ sessions)] | |
| 3 | [e.g., Admin / Buyer] | |
| 4 | [e.g., End User / Individual Contributor] | |
| 5 | [e.g., Enterprise (500+ employees)] | |
| 6 | [e.g., SMB (10-100 employees)] |
Research Types
| Type | Description |
|---|---|
| Interview | 1:1 qualitative interview |
| Usability Test | Task-based usability study |
| Survey | Quantitative or mixed-method survey |
| Analytics | Data analysis of product usage |
| Support Data | Patterns from support tickets or NPS comments |
| Benchmarking | Competitive analysis or benchmarking study |
| Field Study | Ethnographic observation |
| Experiment | A/B test, fake door, or prototype test |
Confidence Levels
| Level | Criteria |
|---|---|
| High | Supported by 3+ independent sources (interviews, data, and/or surveys). Consistent across segments. |
| Moderate | Supported by 1-2 sources. Consistent within one segment but not validated across segments. |
| Low | Single source or anecdotal. Useful as a hypothesis, not as a decision basis. |
| Outdated | Evidence is >12 months old and the product or market has changed significantly. Needs revalidation. |
Part 3: Insight Card Template
Every finding in the repository uses this format.
Insight ID: [Auto-generated or sequential, e.g., INS-2026-042]
Title: [One-sentence headline, e.g., "Enterprise users create workaround spreadsheets to track permissions changes"]
Insight: [2-3 sentences explaining the finding. What did you learn? Be specific.]
So What: [1-2 sentences on the product implication. What should the team do with this information?]
Evidence:
| Source | Type | Date | Participants | Key Data Point |
|---|---|---|---|---|
| [e.g., "Enterprise Permissions Interview Series"] | Interview | [YYYY-MM-DD] | [8] | [e.g., "6 of 8 participants described a manual tracking process"] |
| [e.g., "Q4 Support Ticket Analysis"] | Support Data | [YYYY-MM-DD] | [N/A] | [e.g., "47 tickets related to permission confusion in Q4"] |
Tags:
| Dimension | Values |
|---|---|
| Product Area | [e.g., Admin / Settings] |
| User Segment | [e.g., Enterprise, Admin / Buyer] |
| Theme | [e.g., Permissions, Workarounds, Trust] |
| Confidence | [High / Moderate / Low] |
| Status | [Active / Outdated / Superseded] |
Supporting Quotes:
- "[Verbatim quote 1]" (Participant ID, Date)
- "[Verbatim quote 2]" (Participant ID, Date)
Related Insights: [Links to related insight cards, e.g., INS-2026-038, INS-2025-119]
Linked Research: [Links to full research reports, recordings, or raw data if available]
Added By: [Name]
Last Updated: [YYYY-MM-DD]
Part 4: Research Study Index
Track every research study conducted. Link studies to their insight cards.
| Study ID | Study Name | Type | Date | Researcher | Participants | Insights Generated | Link |
|---|---|---|---|---|---|---|---|
| RS-001 | [Link to full report] | ||||||
| RS-002 | |||||||
| RS-003 |
Part 5: Repository Health Dashboard
Track these metrics monthly to ensure the repository is being used and maintained.
| Metric | This Month | Last Month | Target |
|---|---|---|---|
| New insights added | 10+ | ||
| Insights viewed (unique viewers) | 20+ | ||
| Insights cited in PRDs or decisions | 5+ | ||
| Insights marked Outdated | Review all >12 months | ||
| Contributors (unique authors) | 3+ | ||
| Research studies indexed | All studies |
Part 6: Governance
| Role | Responsibility | Who |
|---|---|---|
| Repository Owner | Maintains taxonomy, runs monthly quality reviews, onboards new contributors | [Name] |
| Contributors | Add insight cards within 1 week of completing research | [All PMs, designers, researchers] |
| Quality Reviewer | Reviews new entries for completeness, correct tagging, and clarity | [Owner or designated reviewer, rotating monthly] |
| Archiver | Marks entries as Outdated when evidence is stale (> 12 months without revalidation) | [Owner, quarterly sweep] |
Quality checklist for new entries:
- ☐ Title is a clear, specific statement (not a question or vague phrase)
- ☐ Insight is 2-3 sentences with concrete details
- ☐ "So What" connects the finding to a product decision or opportunity
- ☐ At least one evidence source with date and participant count
- ☐ All taxonomy tags are filled in
- ☐ Confidence level is justified (not inflated)
- ☐ At least one supporting quote (for qualitative research)
- ☐ Related insights are linked (if any exist)
Filled Example: B2B Analytics Platform
Context. A B2B analytics platform maintains a research repository in Notion. Here is one example insight card and the repository health metrics after 6 months of operation.
Example Insight Card
Insight ID: INS-2026-042
Title: Enterprise users create workaround spreadsheets to track dashboard permission changes because the audit log does not show who changed what.
Insight: 6 of 8 enterprise admins interviewed maintain a separate spreadsheet logging when dashboard permissions are changed, by whom, and why. They do this because the product's audit log only shows login events, not permission changes. Two participants described incidents where a dashboard was accidentally shared company-wide, and they had no way to trace how it happened.
So What: Adding permission change events to the audit log would eliminate a manual workaround used by 75% of enterprise admins in our sample. This is a low-effort, high-impact improvement for enterprise retention.
Evidence:
| Source | Type | Date | Participants | Key Data Point |
|---|---|---|---|---|
| Enterprise Admin Interview Series Q1 | Interview | 2026-02-15 | 8 | 6 of 8 described manual permission tracking |
| Q4 Support Tickets | Support Data | 2026-01-10 | N/A | 47 tickets about permission confusion |
| Enterprise Churn Exit Interviews | Interview | 2025-11-20 | 5 | 2 of 5 cited "lack of admin controls" |
Tags: Product Area: Admin/Settings. Segment: Enterprise, Admin. Theme: Permissions, Workarounds, Audit. Confidence: High. Status: Active.
Quotes:
- "I have a Google Sheet called 'Dashboard Permission Log' that I update manually. It is the only way I know what happened." (P3, 2026-02-15)
- "Someone shared our revenue dashboard with the entire company. It took us two days to figure out who did it and why." (P6, 2026-02-15)
Repository Health (6-Month Snapshot)
| Metric | Month 6 | Month 1 | Trend |
|---|---|---|---|
| Total insights | 87 | 15 | Growing |
| Unique contributors | 6 | 2 | Growing |
| Insights cited in PRDs | 12 | 0 | Growing |
| Insights marked Outdated | 3 | 0 | Healthy |
| Avg. views per insight | 8.4 | 2.1 | Growing |
Key Takeaways
- The insight card format is the backbone. Consistent formatting makes the repository searchable, scannable, and trustworthy. Every entry should answer: What did we learn? How confident are we? What should we do about it?
- Start by backfilling 10-15 key findings. Do not try to archive everything from the past year. Pick the findings that are most frequently referenced in team conversations and document those first. Momentum matters more than completeness at the start.
- The "So What" field is the most important. An insight without a product implication is trivia. Force every contributor to articulate what the team should do with the finding. This makes the repository actionable, not just archival.
- Tag rigorously. The value of the repository scales with its searchability. If a PM can type "enterprise permissions" and find 6 relevant insights from the past 12 months, the repository is working. Sloppy tagging destroys that value.
- Review monthly. The repository owner should spend 30 minutes per month reviewing new entries for quality, updating confidence levels, and marking outdated findings. Without maintenance, the repository becomes a dumping ground that nobody trusts.
- Cite insights in PRDs and roadmap documents. The link between the repository and product decisions is what justifies the effort. Use the RICE framework to score opportunities identified in the repository. Reference insight IDs when justifying roadmap items to stakeholders.
About This Template
Created by: Tim Adair
Last Updated: 3/5/2026
Version: 1.0.0
License: Free for personal and commercial use