On Prioritising Bugs

I wish I wrote this three years ago, when I was dealing with this problem at a customer. Bug reports from their customers, sales reps and customer success poured in on a daily basis. They interrupted everyone’s work, eventually creating huge delays in shipping. It was a vicious cycle of the worst kind. At least writing this now gives me the benefit of emotional detachment and hindsight. If you are struggling with prioritising bugs, I hope this will be useful to you now.

What in hindsight is obvious, is rarely so when you are in the trenches. Life as a start-up PM can be overwhelming. Especially when you inherit a ton of technical debt from your initial go-to-market phase. It means that the daily struggle of handling incoming bug reports is real. You start your day hoping that today is the day you can work 3 hours straight on the feature you need to ship next week.

I had to fix it. There was no way we could continue to work the way we had been up to then. Sales and Customer Success people pinged developers directly on Github, Slack and via phone to solve urgent bugs. Oddly, it seemed like we didn’t have any non-urgent bugs. Sounds familiar? Keep reading.

I tend to say that 80% of problems are communication problems. Because we didn’t have a simple shared understanding of the word urgent in the context of bugs, everything was urgent. We needed a shared definition.

The change we made was so simple you may be disappointed. We separated bugs into two categories: critical bugs, and everything else. Of course, now you have to agree about what a critical bug is. Sales has a problem in their sales demo: is that critical? One customer has a log-in issue, is that critical? How about the CEO, who found a translation issue; critical?

We started from team behaviour. What should we do when a critical bug report comes in? We didn’t discuss this for very long. The answer was: drop everything you’re doing and fix the bug. OK. Reasoning from there, everyone including the sales team realised that we couldn’t handle all bugs as if they were critical. It would mean the company would never make progress on the roadmap because of constant interruptions.

What we did instead was start from a new definition of Critical bugs:

A core business process is non-functional for all customers.

Every organisation has core business processes. So does their software. Defining these could be an article by itself, but I’m sure you will come to a pretty clear conclusion if you discuss this with leaders from Sales, Customer Success and Product & Engineering. We made a list of what we thought were core business processes. This list also served as a starting point for creating more automated tests, so it is a good exercise to do anyway.

All is well in the end? There is still a road to travel. Sometimes we will have a discussion about a bug we didn’t anticipate, that creates a real problem for a large customer. Rules and process are great, but you still have to know when to bend them a little in order to be practical. Product management remains part process, part art. But the number of interruptions has reduced with 80%, so I would say that was a big first step.