How to build a shared insight tagging taxonomy that scales across ten or more product teams
When one product team conducts research, the insights they generate are usually clear enough within their own context. Tags like "onboarding confusion" or "pricing objection" make sense to the people who ran the study.
But when ten, twenty, or fifty teams are all generating insights simultaneously—each using their own labels and conventions—the collective knowledge becomes fragmented. A customer pain point surfaced by one team may go unnoticed by three others working on adjacent problems, simply because they tagged it differently or didn't tag it at all.
A shared insight tagging taxonomy solves this problem. It provides a common vocabulary for categorizing qualitative findings so that insights are discoverable, comparable, and actionable across the entire organization.
Building one that actually works at scale, however, is harder than it sounds. This guide walks through the structural decisions, governance practices, and practical steps required to create a taxonomy that holds up across ten or more product teams.
Why tagging breaks down at scale
Before getting into how to build a taxonomy, it helps to understand why informal tagging systems fail as organizations grow.
Tag sprawl. Without shared conventions, teams create tags independently. You end up with "onboarding," "new user experience," "first-time setup," and "FTUE" all referring to the same concept. The insight repository becomes polluted with near-duplicates that make cross-team search unreliable.
Inconsistent granularity. One team tags everything as "usability issue." Another team tags at a much finer level: "button affordance," "form validation error," "navigation dead end." When someone tries to aggregate findings across teams, the data doesn't line up.
No shared mental model. Tags reflect how individuals think about problems, which varies by role, domain expertise, and even personal preference. Without a shared structure, tagging becomes a subjective act that produces inconsistent results.
Orphaned tags. As teams reorganize, rebrand features, or shift focus areas, old tags linger in the system. Nobody deletes them, nobody updates them, and they gradually erode trust in the taxonomy.
These are not hypothetical problems. They are the predictable outcomes of scaling qualitative research without investing in shared infrastructure.
Principles for a scalable taxonomy
A few foundational principles should guide every structural decision in your taxonomy.
Mutually exclusive, collectively exhaustive (MECE)
At any given level of the hierarchy, tags should not overlap. If "navigation" and "information architecture" both exist as top-level tags, contributors will constantly debate which one to use. Define clear boundaries between categories so that a given insight has an obvious home.
At the same time, the taxonomy should cover the full range of insight types your organization generates. Gaps in coverage force people to misapply existing tags or create ad hoc ones, both of which undermine consistency.
Hierarchical, not flat
A flat list of 200 tags is unusable. A hierarchy with three to four levels gives contributors a way to navigate from broad to specific. For example:
- Experience phase → Onboarding → Account setup → Email verification
- Insight type → Usability issue → Comprehension → Label clarity
Parent tags serve as aggregation points for reporting and cross-team synthesis. Child tags capture the specificity individual teams need for their own work.
Descriptive, not interpretive
Tags should describe what the insight is about, not what the team concluded from it. "Checkout abandonment" is descriptive. "Checkout needs redesign" is a judgment. Keeping tags descriptive ensures that multiple teams can apply them consistently, even if they draw different conclusions from the data.
Governed, not frozen
A taxonomy is a living artifact. It needs a clear process for adding, merging, deprecating, and redefining tags. But it also needs stability—if the taxonomy changes every week, people stop trusting it. The goal is controlled evolution, not rigidity and not chaos.
Designing the taxonomy structure
With principles in place, the next step is deciding what dimensions to tag along and how to organize them.
Choose your tagging dimensions
Most organizations find that a single flat set of tags is not enough. Instead, they tag insights along multiple independent dimensions. Common dimensions include:
Topic — What subject does the insight relate to? This is usually the primary dimension and maps to product areas, features, or user workflows (e.g., "search," "payments," "notifications").
Insight type — What kind of finding is this? Common types include usability issue, feature request, behavioral observation, mental model, unmet need, and positive feedback.
User segment — Which user group does this insight apply to? This might be based on persona, plan tier, geography, job role, or experience level.
Severity or impact — How significant is this insight? Some organizations tag severity (critical, major, minor) or business impact (high, medium, low) to support prioritization.
Journey stage — Where in the user journey does this insight occur? Awareness, acquisition, onboarding, core usage, retention, and expansion are common stages.
Not every organization needs all of these. Start with the dimensions that map to how your teams actually make decisions. You can add dimensions later as needs emerge.
Define the hierarchy for each dimension
For each dimension, sketch out two to three levels of hierarchy. A practical approach:
- Level 1 — Broad categories that are stable and unlikely to change with product evolution. These are your primary aggregation points (e.g., "Onboarding," "Collaboration," "Billing").
- Level 2 — More specific subcategories that map to product areas or workflows (e.g., under "Onboarding": "Account creation," "Team setup," "First-run experience").
- Level 3 — Granular tags for teams that need fine-grained classification (e.g., under "Account creation": "SSO configuration," "Email verification," "Role selection").
Most contributors should tag at Level 2. Level 3 is available for teams that need it but should not be required for every insight.
Audit existing tags before building from scratch
If your organization already has a body of tagged research, start by auditing what exists. Export all current tags, group them by similarity, and identify patterns. This exercise reveals the implicit taxonomy your teams have already been using—and the inconsistencies in it.
An audit also builds buy-in. When you can show teams that their existing tags map into the new structure, adoption feels less like a disruption and more like a cleanup.
Governance: keeping the taxonomy healthy over time
The taxonomy itself is only half the work. Without governance, it will degrade within months.
Assign a taxonomy steward
Someone needs to own this. In organizations with a research operations function, this is a natural fit. In smaller setups, it might be a senior researcher or a rotating role. The steward's responsibilities include:
- Reviewing and approving requests for new tags
- Identifying and merging redundant tags
- Deprecating tags that are no longer relevant
- Maintaining documentation and definitions
- Running periodic audits of tag usage
Establish a change request process
Anyone should be able to propose a new tag, a merge, or a redefinition. But changes should not happen unilaterally. A lightweight process works well:
- Contributor submits a request with the proposed tag, a definition, and a rationale.
- The steward reviews the request against the existing taxonomy—does a suitable tag already exist? Does the proposed tag overlap with others?
- If the change is straightforward, the steward approves and updates documentation. If it has broader implications, it goes to a brief review with representatives from affected teams.
- Changes are communicated in a changelog that all contributors can follow.
This process should take days, not weeks. The goal is to prevent uncontrolled sprawl while keeping the taxonomy responsive to real needs.
Run quarterly taxonomy reviews
Every quarter, pull usage data on your tags. Look for:
- Tags that are never or rarely used (candidates for deprecation or consolidation)
- Tags that are applied far more frequently than others (may need to be split into subcategories)
- Tags that are frequently applied together (may indicate a missing parent category)
- Inconsistencies across teams (same type of insight tagged differently by different groups)
These reviews are most effective when they include representatives from multiple teams, not just the steward working in isolation.
Rolling out across teams
A taxonomy that exists in a document but is not adopted by teams is worthless. Rollout strategy matters as much as structural design.
Start with a coalition, not a mandate
Identify three to four teams willing to pilot the taxonomy. Work closely with them to test the structure, refine definitions, and surface edge cases. Their feedback will improve the taxonomy before it reaches the broader organization, and their endorsement will carry weight with skeptical teams.
Write clear tag definitions
Every tag needs a written definition that answers: What does this tag mean? When should it be applied? What should be tagged with a nearby tag instead?
Ambiguous definitions are the single biggest source of inconsistent tagging. Invest the time to make them precise. Include examples of insights that do and do not belong under each tag.
Build tagging into existing workflows
If tagging is an extra step people have to remember after finishing their analysis, compliance will be low. Integrate tagging into the natural flow of insight creation. Tools like Dovetail allow researchers to tag highlights and insights as they work through data, which reduces the friction of maintaining taxonomy discipline across a large organization.
Provide lightweight training
A 30-minute walkthrough of the taxonomy structure, the tagging dimensions, and the governance process is usually sufficient. Pair this with a reference guide that people can consult when they are unsure which tag to apply. Avoid heavy certification programs—they create resistance and rarely improve outcomes.
Measure adoption, not just compliance
Track how many insights are tagged, how many tags per insight, and how consistent tagging is across teams. But also track whether the taxonomy is being used for cross-team synthesis. The ultimate measure of success is not that every insight has three tags—it is that teams are discovering and building on each other's findings.
Common mistakes and how to avoid them
Designing in isolation. A taxonomy built by one person or one team, without input from across the organization, will reflect a narrow perspective. Involve representatives from at least five teams in the initial design.
Over-engineering the hierarchy. Five levels of nesting with 300 leaf-node tags is a taxonomy nobody will use. Start lean. Add specificity only where there is demonstrated need.
Treating the taxonomy as permanent. Organizations change. Products evolve. User segments shift. A taxonomy that was perfect a year ago may need significant revision today. Build the expectation of change into your governance process from the start.
Neglecting tag definitions. Tags without definitions are tags that will be applied inconsistently. This is the most common and most avoidable failure mode.
Ignoring cross-functional contributors. Product managers, designers, customer success teams, and support teams all generate or consume insights. If they are excluded from the taxonomy design, they will either not use it or create parallel systems.
How tooling supports taxonomy at scale
Spreadsheets and wikis can support a taxonomy for a small team, but they do not scale. As the number of contributors, insights, and tags grows, you need a system that enforces structure, tracks usage, and makes tagged insights searchable.
Dovetail is built for this kind of work. It supports hierarchical tagging, lets teams tag data as they analyze it, and provides a searchable repository where insights from any team are discoverable by anyone else. When the taxonomy needs to evolve, changes propagate across the repository rather than requiring manual updates to dozens of individual files.
The specific tool matters less than the capability: whatever system you use should make it easy to apply tags consistently, search across teams, and maintain the taxonomy as a living structure.
Building a taxonomy is an organizational design problem
It is tempting to treat taxonomy design as an information architecture exercise—pick the right categories, define the right hierarchy, and the problem is solved. But the harder work is organizational. It requires alignment across teams on what counts as an insight, how granular tagging should be, who makes decisions about the taxonomy, and how the taxonomy connects to the way teams actually prioritize and build.
The organizations that succeed at this treat the taxonomy not as a research team artifact but as shared infrastructure—something that belongs to everyone who generates or uses customer insights. That shift in ownership is what makes the difference between a taxonomy that sits in a wiki and one that genuinely changes how an organization learns from its users.