Don’t have a separate “queue” for bug prioritization

Emily Tate’s article on the best ways to prioritize bugs comes at the problem with a Scrum lens, but many of the points are more broadly applicable to product management. I particularly like her assertion that there’s nothing “special” about bugs, and as such they should be prioritized just like any other idea/feature:

As product managers, we should always manage our backlog so that the next most important thing is at the top of the list. Many times, the bug you would work on is less important than other things on your backlog. By working on the lower priority bug, you are deferring the more important work that can help you reach your strategic goals.

The flip side of this is also true: sometimes the next most important thing may be five or six bugs that really need to be fixed before adding yet another feature on top of a fragile platform. If you live in a world of separate queues or say you’ll always devote 20% of the team’s time to bugs, you actually lose the opportunity to say “this week, we are squashing these bugs that have been plaguing us before we do another thing.” In reality, you will likely have a mix of bugs and features in your backlog, but the most important thing is that you prioritize strategically and intentionally, not letting a false constraint determine what the ratio of your backlog looks like.