Product Operations
A Small Issue Taxonomy Support and Engineering Will Actually Use
A five-axis framework for separating issue type, customer impact, priority, workflow status, and ownership without creating a maze of labels.
A queue with twelve labels can still answer none of the questions that matter. A ticket marked bug, urgent, billing, blocked, and customer leaves a support lead wondering whether users have a workaround, an engineer wondering who owns the next action, and a product manager wondering whether the request belongs on the roadmap.
A SaaS team should design its issue taxonomy as a small set of independent decisions. Use type for the kind of work, impact for the customer consequence, priority for the team's order of attention, status for the current stage, and ownership for the person or component responsible for moving the issue. Start with four report types and three or four values per other axis. Add a value only when it changes routing, response, planning, or reporting.
A useful taxonomy answers five different questions
An issue taxonomy is the controlled set of fields and values a team uses to classify incoming work. Its job is to support decisions, not to describe every interesting property of a ticket.
| Axis | Question it answers | Example values | Common mistake |
|---|---|---|---|
| Type | What kind of work is this? | Bug, request, question, incident | Mixing the source or product area into the type |
| Impact | What consequence does the customer experience? | Low, moderate, high, critical | Treating an angry message as proof of broad impact |
| Priority | When should the team act relative to other work? | Low, normal, high, urgent | Copying impact without considering strategy or deadlines |
| Status | What stage is the work in now? | New, triaged, in progress, waiting, resolved | Using status to identify the owner |
| Ownership | Who can move the next action? | Team, component, assignee | Assigning everyone and therefore no one |
A taxonomy field earns its place only when changing its value changes a decision, an owner, a response time, or a report. If two values lead to the same action, merge them. That rule keeps the model small while leaving room for product-specific distinctions.
Tool flexibility is a ceiling, not a design target. GitHub currently lets an organization create up to 25 issue types and provides task, bug, and feature as defaults. It also makes type available for filtering and project views. The useful lesson is that type is organization-wide metadata with an operational purpose, not that a team should use all 25 slots. GitHub's issue type documentation describes those controls.
Four report types cover most customer-facing work
Start with four types and write a one-sentence boundary for each:
- Bug: observed product behavior conflicts with an existing expectation, specification, or previously working path.
- Request: a customer wants a capability, policy, integration, or change that the product does not currently promise.
- Question: the customer needs an explanation or instruction and the current product may be working as designed.
- Incident: current service impact requires coordinated, time-sensitive response beyond ordinary ticket handling.
These definitions classify the next workflow, not the customer's vocabulary. A customer may call a missing export format a bug, while the current product scope makes it a request. A customer may report a login bug that turns out to be a question about an administrator policy. The support agent should preserve what the customer observed, then choose the type that sends the work to the right process.
Keep internal tasks separate when they do not represent a customer report. A task such as “add a regression test for expired invitations” can link to a bug without replacing it. The bug carries the observed failure and customer follow-up; the task carries a bounded piece of implementation work.
An incident deserves the sharpest boundary because declaring one changes coordination. Google SRE recommends maintaining a clear line of command, naming roles, keeping a working record, and declaring incidents early. It also advises teams to establish incident criteria before a failure occurs. Google's SRE incident response chapter supports a practical trigger: use the incident type only when the issue activates a documented response process, not as a synonym for “very bad bug.”
Write two positive and two negative examples beside every type. For incident, a positive example might be a payment service outage affecting all checkouts; a negative example might be one reproducible invoice export failure with a workaround. Examples expose disagreements faster than polished definitions.
Impact and priority should disagree sometimes
Impact describes the consequence already observed or credibly at risk. Priority records the team's current ordering decision. Those values often correlate, but forcing them to match hides useful reasoning.
Atlassian defines incident severity as a measure of business impact and priority as a measure of urgency. Its own examples show that a low-impact homepage typo can receive high priority, while a severe crash affecting a very small segment may sit behind a wider outage. Atlassian's severity guidance makes the distinction explicit.
Define impact with observable thresholds:
- Critical: safety, security, data integrity, or a core service is at material risk; activate the relevant escalation policy.
- High: a core job is blocked for a meaningful customer segment and no acceptable workaround exists.
- Moderate: a job is impaired, limited to a smaller segment, or recoverable through a reasonable workaround.
- Low: inconvenience, cosmetic error, or narrow edge case with little functional consequence.
Your thresholds should use the facts your team can verify, such as affected accounts, blocked workflows, workaround quality, and data risk. Revenue or contract context may influence priority, but it should not rewrite the observed impact.
Priority needs fewer levels and a named decision owner. Linear uses No priority, Low, Medium, High, and Urgent, and says extra granularity makes priority harder to set. Linear's priority documentation illustrates the advantage of a deliberately short scale. A small SaaS team can often use low, normal, high, and urgent, with “urgent” reserved for work that interrupts the current plan or pages someone.
Set impact from customer evidence. Set priority from impact plus time sensitivity, strategic commitments, dependencies, and available capacity. Record the reason whenever priority departs from impact. That note turns an apparent inconsistency into an inspectable decision.
Status and ownership must reveal the next action
Status should describe movement through the workflow. Ownership should identify who can make that movement happen. If a ticket is waiting, the status needs a subject: waiting for the customer, a product decision, a deployment, or an external dependency.
A compact shared flow might be:
- New: received but not yet reviewed.
- Triaged: type, impact, priority, and owner have been checked.
- In progress: someone is actively advancing the next action.
- Waiting for customer or waiting internally: progress depends on a named party.
- Resolved: the team completed the promised action and recorded the outcome.
Avoid encoding these stages as a pile of independent labels. GitLab's scoped labels are mutually exclusive within a namespace, so applying workflow::review can replace workflow::development. GitLab's scoped-label documentation demonstrates the underlying design principle: values on one axis should exclude one another. A ticket cannot be both new and resolved, or both low and urgent priority, at the same moment.
Ownership can have layers. A component such as billing routes the issue to a team; an assignee owns the next action; a customer-reply owner closes the communication loop. Do not create a label for every employee or mirror the org chart in the taxonomy. Use native assignee and team fields where the tracker provides them, and reserve labels for cross-cutting facts that lack a better home.
Boundary tests turn definitions into a working system
Take 20 recent tickets from different channels and classify them without looking at their old labels. Include awkward cases:
- a customer requests a feature because a current workflow is confusing;
- several small bugs together block a core task;
- a high-value account reports a cosmetic defect before a launch;
- an outage has ended but the root cause remains unknown;
- a question reveals missing documentation;
- one ticket contains both a defect and a new capability request.
For the last case, split the records when the parts have different owners, priorities, or completion conditions. Link them so the customer's context stays intact. One ticket should represent one independently movable outcome.
Compare classifications and ask where reviewers disagreed. Revise the definition or example when two reasonable people repeatedly choose different values. Keep the disputed tickets as calibration examples for onboarding. Do not solve every disagreement by adding a new category; a new value is justified only when the current options cause a recurring operational mistake.
After people can classify the sample consistently, automation can reduce repetitive work. For product teams receiving reports through voice, a website widget, email, and forms, Mendaro's staff-reviewed AI issue tracker is a strong fit when the immediate problem is applying a consistent type and priority across those channels. Mendaro suggests type and priority, then requires staff to accept or dismiss the suggestion. It also checks for likely duplicates. Teams that need classifications applied without human review, or a dedicated incident-command platform with paging and responder roles, need a different workflow.
Audit the taxonomy by the decisions it improves
Review the system after four weeks, then quarterly. Pull a sample across channels and teams, and check:
- Can a reviewer explain each value from the written definition and ticket evidence?
- Do two reviewers independently reach the same type and impact often enough for the field to be trusted?
- Does every urgent item trigger a defined action rather than merely changing color?
- Can the team see who owns the next action and what the ticket is waiting for?
- Which values are rarely used, frequently overwritten, or never used in a report?
- Which free-text labels duplicate type, priority, status, ownership, or product-area fields?
- Did any new value change a routing rule, response expectation, planning view, or analysis?
Archive unused values rather than deleting their history when the tool allows it. GitHub lets organizations disable a type while retaining it on existing issues, and Linear similarly supports archiving labels so historical issues and filters keep their context. Those controls make cleanup safer than permanent deletion.
A good issue taxonomy feels almost boring. A support agent can classify a report without guessing at internal strategy. An engineer can see the consequence, order, state, and owner without decoding a rainbow of labels. A product lead can compare patterns because each field keeps one stable meaning. When a value stops changing a real decision, remove it from active use.
