Fixing Bugs and Tech Debt in the Product Flow

Fixing Bugs is a fact of every product manager’s life. You have to allot a certain amount of time to paying down tech debt, or else it becomes way too hairy and eventually you end up having to just refactor your codebase. And no one likes a refactor.

I get the question all the time, however, how to manage all the bugs and other snags that your product accumulates. 

Fixing bugs shouldn’t be part of your product strategy.

One thing I always point out is that, technically, fixing bugs isn’t part of your product strategy. They’re part of “business as usual”, and just something that the engineering team should be tackling as part of their day-to-day work. This makes it part of your company’s tech strategy, usually, something owned and championed by your CTO. It’s an important distinction, and it’s helpful to delineate and show how a good technical strategy enables a strong product strategy to take hold. 

In order for your developers to keep on top of fixing bugs, they need to be given time and space to do this. 

And this is where a critical but hard truth comes in: You, the product team, don’t own 100% of dev capacity. In fact, way less than that. And that should be by design. 

Your engineers should be working in a way that allows them to deliver good quality code, and to spend time refactoring and fixing code as it comes. A certain amount of slack needs to be built in to account for this, and the more slack there is, the less likely you’re going to end up with rushed code, missed bugs, and the accumulation of new tech debt. 

If you’ve already got a heavily tech-debt-ridden product, it might be important for the devs to spend a good 50% of their time on maintenance and new bugs that pop up. Maybe you’re lucky and you can get away with less dedicated time than that, particularly if you’re working on newer code bases or have been giving a fair amount of slack along the way. After all, it’s easier to prevent tech debt than it is to pay it off later!

How much time should your devs be spending on fixing bugs?

Approximately 10-20% is generally the bare minimum, even for well-maintained and relatively new products. Remember, you’ll always have bugs and other DevOps tasks that need to be done. These will have nothing to do with the user stories and experiments you’re crafting for future product improvements.  

Your job as a product team is to make sure that, whatever time you do have of the dev team’s capacity, you’re not wasting it. You’re making sure that you’re prioritizing the right problems to solve, and breaking things up into small, testable experiments. 

In reality you might actually spend a good chunk of your time catching and documenting bugs and communicating these to the dev team. Just because you’re doing this and you hold the title Product Manager, doesn’t mean that this is product management work. Think of the time spent on bug hunting as a time when you’re wearing a special QA hat. Ideally, your company would have a QA person in a QA role for that job, but we’re not all that lucky. Instead, mentally separate out your QA hat tasks as ‘development QA time’, versus your regular product management hat. You wear your product management hat when you’re being product-led with your research, spec’ing, and crafting of experiments and product iterations.

How do you capture bugs on your roadmap?

Short answer: You don’t! 

Your roadmap communicates your product strategy. It’s not designed to try to show every nook and cranny that’s being fixed and tweaked with the code, and as soon as you try to load in that much information, your roadmap loses its ability to be an effective tool for communicating and checking assumptions about your strategy. 

Your roadmap should express problems to solve and the experiments you’re lining up to try to solve those problems. These form a part of your product strategy, and should show your product-led time. 

After all, your roadmap isn’t a task manager. 

At the end of the day bugs are simply tasks to do that the development team needs to tackle in due time, and the business needs to make sure they’re given time to do it. That’s why bugs live in your development task tracking tool (like Jira, AzureDevops, or Trello), and are usually seen in the more granular release plans. 

But your release plan is not your roadmap.

What’s in a good technical strategy for bugs?

As I said, bugs are always going to exist. As a product team, there’s not much point trying to get too granular about trying to track every bug that passes by. (unless you’re also your team’s defacto QA person, at which point, remember, you’re wearing a different hat for this – this isn’t strictly product management)

Think about bugs, not in terms of the individual bugs, but how much time your engineering team is spending on solving them. Some teams express this as a number of points per sprint, or a percentage of their time, or others like to have ‘bug crush’ sprints every few sprints. There are lots of variations that work—do whatever’s needed to pay down tech debt and keep bugs at bay in your own product’s context.

This percentage or way of working is something that should be strategically set. It’s part of your technical strategy, and should be informed by your wider business strategy. 

As a product person, you can help influence this by advocating for a strong technical strategy that encompasses time for bug crushing. And you should, because it’ll enable your own product strategy to come to fruition. After all, you won’t be able to build a viable, desirable product if you’re constantly battling bugs! 

This way of working gives the engineering team autonomy to prioritize fixing tech debt based on factors they see around them. This includes what the business (including the product team) is trying to achieve, as well as having a more holistic view of the codebase. Ideally, they should be able to spot problem areas and get in there with refactors before other business units start leaning on those chunks of code too heavily. 

A typical sprint might include a mixed bag of work, including some new code to cut to create some in-app experiments that the product team is setting up, a handful of bugs reported by the QA folks or support team, and a sprinkling of fixes and other DevOps tasks filed in directly from the dev team themselves, based on their knowledge of the platform and the business’s needs. 

This is the domain of the ScrumMaster, lead developer, or whoever else is managing the project end of your sprints. (Again, this might be you, mighty product manager of many hats, but remember that you’re wearing a different hat yet again if you see yourself in this role) 

The last thing they need is a product manager trying to micromanage all of these tasks and lay them out in a roadmap.

Keep on assessing tech debt and adapting!

Over time, the time allotment might change. If your code continues to accumulate tech debt, adjust your tech strategy to account for more time tackling bugs. If your strategy is working and tech debt is diminishing, you might be able to carve out more time for truly product-led work! 

As with anything, this should be a reflective process. As part of your regular retros, size up how your team is faring with the current split of work, and be ready to adjust as you learn more and your product adapts. 

Get in touch if you’d like more information or to discuss your own tech strategy.