Don’t fix bugs just because they’re bugs

Written by Better product building

Reading Time: 3 minutes

A common mistakes product teams make is around prioritising bugs, tech improvements, and tech debt. The mistake is to treat them as separate entities from features, and prioritise them through a different process.

It typically looks like this:

  • Features get prioritised by the team (led by the PM) on a quarterly basis, and the order is decided throughout the quarter.
  • The team is given some tech improvements to do by tech leadership, that they complete at some point in the quarter.
  • The team sets aside a certain amount of hours/people per sprint to deal with bugs as they come up. These are sometimes triaged by someone to determine if they can be ignored.

It can feel natural to treat them separately, because they do feel different. Features improve the value you give to users, and ideas for these come from the team, or users. Bugs are typically gaps in your product that hurt the value it provides, although they also come from users. Tech improvements typically don’t provide immediate value anywhere, and come from engineering leadership as “engineering projects”.

They feel hard to prioritise against each other as they’re essentially different things, so it’s maybe tempting to give them different categories, give each category a set amount of resource, and prioritise within those categories.

But it’s wrong to treat them as different entities.

Bugs are not special because they are bugs. 

Bugs stop a user from getting value from the product. Whether it’s a broken feature, a spelling mistake, or your whole service being down – these all just prevent users from getting value. By fixing these things you unlock value, which is exactly the same thing you do when you ship a feature improvement.

Every time you pay attention to a bug because it’s a bug, rather than the value you unlock, you’re lowering the team’s impact. Triaging bugs will prevent you from fixing a spelling mistake on a page that gets 10 page views per month, but it still leaves a system that values things differently because they’re bugs.

Equally importantly, if you have multiple high-impact bugs, you shouldn’t push back on them because you’ve used up your allotted bug time this sprint. You should evaluate everything on its impact.

Tech improvements aren’t special just because engineering leadership wants them.

Nothing should get done, unless the value they bring can be clearly articulated. Tech improvements should get sold-in and built based on the value they unlock.

Tech improvements don’t typically create user value as quickly as features or fixing bugs. Instead, they make it faster for engineers to ship in future, or unlocks a big new feature. These should be prioritised based on the value they unlock, just like you do with features and bugs.

If the team sets aside a standard amount of time to engineering projects each quarter there is a risk of working on low-impact projects, or missing out on high-impact projects just because of their “type”.

Engineering projects that aren’t prioritised based on value put an added strain on the product manager. They don’t know how to prioritise them within the quarter, and aren’t necessarily bought-into the project. But if PMs don’t do it, or push back, it can get a bit political.

Evaluate all potential projects together 

Features, bugs, and tech improvements all need to be prioritised based on how much value they bring. They bring them over different time-scales, but balancing short-term and long-term value should be bread-and-butter for a PM.

This gives you consistent prioritisation criteria, which makes makes it easier to debate, and easier to get buy-in from the team doing the work.

Having a PM involved for everything, also means that they get a macro view of issues. If a bug keeps occurring, but a different engineer looks at it in isolation, it’s hard to draw conclusions that help fix it for good.

This process does mean that PMs need to be able to effectively understand and evaluate technical improvements, and bugs, but they should understand all the work that their team undertakes anyway.

This simple change to managing bugs and tech improvements drastically improve team output, as well as make teams more empowered.