The 6 Jobs a Feedback Taxonomy Owner Does Every Week

Ask a team what taxonomy maintenance involves and most will describe the old version of the job: someone reading through tickets, applying tags, and cleaning up what the tagging missed. That work has largely disappeared on platforms that classify feedback automatically. What replaced it is smaller, less predictable, and considerably more consequential.

The recurring work now breaks into six jobs: reviewing proposed theme changes, resolving merge and split decisions, arbitrating theme names across teams, watching the catch-all bucket, adding structure after product launches, and answering volume questions for planning. None of them are full-time. Together they are the difference between a taxonomy that stays useful and one that quietly stops describing your product.

What the job looks like once classification is automated

The shape of the work changes rather than the amount of judgment it requires. Automatic classification removes the volume problem: every record gets categorized, in every channel, without anyone touching it. What it does not remove is the question of whether the categories are the right ones.

That leaves an owner with a weekly rhythm that looks more like code review than data entry. Changes get proposed, the owner accepts, adjusts, or rejects them, and the structure moves forward. The load is concentrated in decisions, not keystrokes.

The 6 jobs a feedback taxonomy owner does every week

1. Review proposed theme changes

When a platform detects emerging themes on its own, those proposals need a reviewer. The job is to check whether a new theme describes a real, distinct customer problem or whether it is a restatement of something already tracked. A good review takes minutes per theme. Skipping the review for a quarter is how taxonomies end up with forty themes where fifteen would do.

2. Resolve merge and split decisions

Two themes collecting the same feedback should usually be merged. One theme collecting three different problems should usually be split. The judgment is whether the distinction changes what someone would do about it. Slow performance and unpredictable performance sound similar and point at different engineering work, so they stay separate. Two themes that differ only in the words customers happened to use should not.

3. Arbitrate theme names across teams

Support calls it a login failure, product calls it an authentication defect, and CS calls it an onboarding blocker. All three are describing one problem. Someone has to pick a name. The rule worth holding: the name should carry the problem, not just the topic. A theme called Billing tells you nothing. A theme called Invoice totals do not match the subscription tells you what to fix.

4. Watch the catch-all bucket

Every taxonomy has a general or miscellaneous category, and its size is the single best health indicator available. A catch-all that grows faster than overall volume means feedback is arriving that the structure has no home for, which usually means the product moved and the categories did not. Checking it weekly takes a minute and catches drift earlier than any scheduled audit.

5. Add structure after product launches

A launch introduces language customers have never used before. Until the taxonomy has somewhere to put it, that feedback lands in adjacent themes or the catch-all, and the launch looks quieter than it is. Adding the structure ahead of or immediately after a release is the highest-leverage maintenance task on the list, and the one most often forgotten in the week a launch actually ships.

6. Answer volume questions for planning

The owner is who the room turns to when someone asks how many customers asked for this. That question is harder than it sounds, because the honest answer depends on whether the theme is fragmented, which channels are connected, and whether you are counting records or accounts. See how to answer how many customers asked for this in a roadmap review for the mechanics.

The work that disappears and the work that does not

The parts of this job that scale with feedback volume are the parts automation removes. Reading, categorizing, and retagging are volume work, and volume work is exactly what a system that learns the taxonomy from the data handles without help. Teams still doing it by hand pay the hidden costs of tagging feedback by hand in analyst hours and in trend lines that break every time a tagging convention shifts.

The parts that scale with product complexity do not go away. A company shipping into four business units has more naming disputes, more merge decisions, and more launches to structure for than a single-product company, regardless of how good the classification is. That is the load to plan for.

Two things make the difference between an hour a week and a recurring project. The first is whether theme operations sit in the owner's hands or require engineering support to execute. The second is whether changes are reversible. An owner who can rename, merge, and split directly, review the change before it goes live, and roll it back if the result is wrong will make decisions quickly. An owner who has to file a ticket and wait will let the structure drift instead.

How to size the role

For a single-product company with automated classification, this is a few hours a month, concentrated around launches. For a multi-product company, it is closer to a few hours a week, and it belongs to someone senior enough to end a naming argument.

What it is not is a headcount request. Teams that size this job as a full-time analyst role are usually still budgeting for the tagging work, which is a sign the tooling decision and the staffing decision are being made in the wrong order. Decide how classification happens first. The staffing answer follows from it. For how this changes as feedback volume grows, see scaling customer feedback management.

FAQ

Is taxonomy maintenance a full-time job?

Rarely, once classification is automated. The recurring work is decision-heavy and low-volume: reviewing proposals, settling merges, naming themes, and adding structure after launches. Teams that find it consuming a full role are usually still doing manual categorization underneath.

What is the most important weekly check?

The size and growth rate of the catch-all category. It is the earliest signal that feedback is arriving with no home in the current structure, which almost always traces back to a product change the taxonomy has not caught up with.

How often should the whole taxonomy be reviewed?

Quarterly for a full pass, plus an unscheduled review after any significant launch or repackaging. The weekly jobs handle drift at the edges. The quarterly pass is for the structural questions, like whether the top level still matches how the product is organized.

How does Enterpret reduce the work?

Enterpret's adaptive taxonomy learns the structure from the feedback and keeps classification current as customer language changes, so none of the six jobs involve tagging. The customer context graph attaches account, segment, and revenue context to every theme, which turns the volume question from a counting exercise into an impact answer.

Who should this job report to?

Wherever the decisions the taxonomy feeds are made. If the primary consumer is the roadmap, it belongs near product. If it is an executive customer program, it belongs with the program owner.

If you are evaluating how much maintenance your current setup demands, see platforms for a unified feedback taxonomy.

‍