Guide··5 min read

Feature requests vs. bug reports: triage without a full-time PM

Most teams collecting feedback don't have a dedicated product manager sorting it. Here's a triage system that holds up anyway.

The moment you turn on a feedback widget, you have a new problem: a growing pile of bug reports, feature requests, and one-off complaints, and no one whose job it is to sort them. Most small teams don't have a PM running formal triage. That doesn't mean the pile has to turn into noise.

Two buckets, not ten

The instinct when you first set up a board is to build out categories: UI, performance, onboarding, billing, mobile, and so on. Resist it early on. Two types cover almost everything that comes in: Bug (something is broken) and Feature (something doesn't exist yet). A third catch-all for everything else keeps the count at three. More categories than that just means more clicks per item and more decisions about which bucket something belongs in, decisions that don't actually change what you do next.

Votes tell you what's popular, not what's next

A voting board is genuinely useful because it turns "someone asked for this once" into "forty people asked for this." But treat the vote count as one input, not a queue you work top to bottom. A bug affecting 5% of your users' checkout flow can outrank a 200-vote feature request even at a fraction of the votes, because the cost of leaving it alone is different in kind, not just degree.

  • Review the board on a fixed cadence (weekly is enough for most teams), not continuously — continuous triage is how it eats your day
  • Anything reported independently by more than one or two users jumps the queue regardless of vote count, even a single-vote bug
  • Close stale requests with a one-line reason instead of leaving them open forever — an honest "not planned" is more useful than a silent pile
  • Let votes break ties between equally-important items, not decide importance on their own

What changes as the pile grows

Eventually you'll want more structure: custom columns beyond Open, In Progress, and Done, or labels for the specific part of the product something touches. Add those when the two-bucket system is visibly costing you something, not before. The point of triage isn't to build a taxonomy, it's to spend your limited attention on the right five items this week.

Try it with what you already have

If you're running Upstep, this is the default: Bug, Feature, and General, sorted by votes, with Open, In Progress, and Done to move things through. You don't need to configure anything to start triaging this way, just to resist the urge to over-configure it.

Start collecting feedback today

Free plan. 2-line integration. Your API key is ready the moment you sign up.

Get started free