Product managers face seemingly impossible choices when it comes to prioritizing bug fixes vs. new features for their next release. Asking them to choose between a critical evolutionary feature or fixing an app-breaking bug is like asking them to choose which pet to give back to the pound.
Luckily, you don’t really have to make this tough choice. After facing countless crisis scenarios, seasoned product managers have developed their own set of heuristics and workflows that make prioritization decisions infinitely easier.
We scoured the web looking for their responses to the question of “how do you choose between bug fixes vs. new features?” and here are the three best answers we found.
Assign Relative Weight to Bug Fixes vs. New Features
A former product manager and now project lead at QDelft in the Netherlands, gives the most complete answer for making prioritization decisions.
Firstly, he insists that teams should always be working on bug fixes in some capacity, or “the list will otherwise grow to become unmanageable.”
Secondly, he observes that feature requests can get greedy with your time if you try to tend to them all. “I get approx. one feature request per working day,” he assures, “so I cannot do or prioritize them all.”
Recognizing these two truths, he maintains a long list of possible features, which is generally sorted into categories. From this long list, he handpicks items to put on a shortlist, where items generally deserve more attention. These can be critical features that add huge value to the end-user experience, or they could be crippling bugs that make parts of their product unusable.
“I try to always do a number of items from the shortlist in each release,” he notes, adding that at least some requests from the customer base must end up in the shortlist. End users who see their bug complaints addressed or feature requests honored feel partial ownership, enhancing their perception of value with the product.
To decide which bugs most deserve his attention, he determined both importance and urgency:
- Importance refers to how much the bug impacts vital functionality or secondary functions. It must also acknowledge the availability of workarounds and how many users are affected overall.
- Urgency refers to how long a bug can wait on the backburner. Is it preventing users from accessing necessary functionality? Is there a deadline where they need access again?
Urgency comes first, but importance helps assign relative weight.
As for features, he calculates a version of ROI. This formula equates to the value to end users. For commercial products, value equals things a customer would be willing to pay money for. For free (or mostly free) web services, value equals the amount of time a customer would spend using it.
Divide value by the amount of time or effort a feature costs to implement. Features that bring a middling level of value but are easy to implement therefore take priority over high-value features that require effort.
Additionally, he recommends using the MoSCoW method: things your product Must have, Should have, Could have, or Won’t ever have.
Finally, he advises the old toolset of CS + GI: Common Sense and Gut Instinct.
Use Hierarchies, Not Buckets
Another perspective comes from a startup guru and an experienced product manager who cautions against assigning vague category “buckets” for priorities. The problem is, you still end up making prioritization decisions within each bucket.
“Let’s say you have two tasks marked as ‘important’ in your backlog,” he postulates. “Now, you add a third important one. You’re ending up with 3 important tasks, which literally provides you with no information.”
This type of situation can force you into choice paralysis. Therefore, instead of assigning priority levels, decide an order of priority for each bug or feature. Number them: 1, 2, 3, etc. Do the top one first.
“If you prioritize by order,” he explains, “you naturally admit that if you decide to put the new task on top, the other ones must be less important.”
Setting up your priorities like this overrules nitpicky categorizations, and it also lets you grab one or two things from the top of the list, no questions asked.
Keep Resources for Both Bug Fixes and New Features at All Times
As a final recommendation, we turn to a Technical Product Manager at Atlassian.
He observes that both features and bugs deserve your constant attention. If you’re asking yourself or your team to constantly jump between the two, you create transitional friction that leads to lower productivity.
Instead, he recommends you create a persistent bug fix team proportional to the feature building team. “As an example, you might decide that, for every 8 engineers on a feature team, you’ll staff 2 on bug fix,” he suggests, and to “try different ratios to work out what is best.”
Rotate out engineers between teams so they keep a holistic mindset. Also, establish a “warranty” period for new features where feature teams have to fix any new bugs they create. Otherwise, the feature team will pass problems and technical debt off to the fixers.
There you have it! Three different ways to break down those seemingly impossible choices into manageable heuristics.
We’d love to hear if any of these worked for you or if you have your own prioritization tools to add, so let us know in the comments!