post

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Successful product management in companies where it’s least understood

Measuring critical user journeys – Javier Andrés Bargas-Avila (UX Director, Google)

A new way to look at applied experiments

Product survey findings: Only 15% of users are embracing AI features 

Building high-performing product teams: The PDLC approach

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Overcoming the 20% feature usage challenge

Product Management

Three product leaders to learn from at #mtpcon inside Pendomonium

Emily brings nearly 15 years of product management experience to her role as Managing Director for Mind the Product. While she has worked across a variety of industries, she will always have a soft spot for the travel industry where she spent most of her early career building software for airlines and developing a leading consumer travel app, TripCase. Emily is passionate about the craft of product management and loves talking about new ways to make products people love.

Emily Tate

<p>As a product consultant and trainer, I hear a lot of similar questions over and over. Many are what you might expect and are regularly debated on Twitter: “What’s the difference between a product manager and a product owner?” “How should I manage my roadmap?” “Do product managers need to know how to code?”</p>
<p>But beyond these hot topics, there’s one question I think comes up even more consistently: “How should I manage bugs?” Bugs aren’t the sexiest of topics in the tech world, but we’ve all got them. So let’s talk about what to do with them.</p>
<h2>An Ounce of Prevention</h2>
<p>I live in Texas &#8211; land of hot summers and lots of mosquitos. You might say we have a bug problem! One thing we know for certain is that once you have mosquitos, they are nearly impossible to get rid of. And the earlier in the year that you spot your first mosquito, you know the worse it’s going to be as the season goes on. So we focus heavily on prevention &#8211; making sure there is no standing water for larvae to grow in, pre-treating spots where we can’t stop water collecting, and other tactics to try and avoid that first mosquito.</p>
<p>What does this have to do with software? Managing bugs is a lot like managing mosquitoes &#8211; you should avoid letting them into the environment in the first place. And the earlier you let a bug slip through in a project, the more bugs you’ll probably see as you go, and the harder it will be to clean them up.</p>
<p>This may seem like common sense, but how often have you had a story <span style="font-style: italic;">almost</span> finished at the end of an iteration, but just have a couple bugs left to fix? And how many times has someone suggested “Well let’s just go ahead and close the story and log the bugs for the next iteration.”? <span style="font-weight: bold;">Don’t do this!</span> If something is not working properly while you are developing functionality, or something you just built has now broken something else, it’s not a bug. It is unfinished code. Fix it now. (There is obviously some nuance here around edge cases that you might choose not to fix, but that is probably another post in itself.)</p>
<h2>There is no Magic Queue</h2>
<p>I find that people like to talk about bugs as though they exist in an alternate dimension, where working on them doesn’t detract from anything else. There is a temptation to give bugs a special status, allocate a specific amount of time in each iteration to them, or in extreme cases, put some false timeline on how quickly they should be fixed (“all reported bugs fixed within five days”).</p>
<p>The problem here is one of <span style="font-weight: bold;">opportunity cost</span>. At the end of the day, a bug is just another piece of work. Any time that your team spends fixing a bug is time that is not spent working on the next thing up on your roadmap. As product managers, we should always manage our backlog so that the <span style="font-style: italic;">next most important thing </span>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.</p>
<p>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.</p>
<p>So how do you manage this? I actually do recommend prioritizing bugs in their own queue, putting the highest priority bugs at the top. This keeps things clean for roles like customer support who regularly add to the list or add additional information. I can have discussions about which bugs are really causing the most pain and adjust accordingly. Then I prioritize my roadmap work. Once I have a list of the next several things up in my backlog, I look at my top bugs and start the evaluation &#8211; are any of these bugs a higher priority than the things at the top of my list? If yes, I figure out where they should fit, and my prioritized backlog is complete.</p>
<h2>To Estimate or not to Estimate</h2>
<p>Sometimes I’ll get into discussions with teams about whether or not you should estimate bugs. As with most things in product, my answer is, <a href="https://www.mindtheproduct.com/the-1-answer-in-product-it-depends/">it depends</a>. Although rather than depending on moving situations, this one depends more on the philosophy of your organization.</p>
<p>There are generally three ways people deal with estimating bugs:</p>
<ol>
<li>Estimate bugs like you do stories &#8211; give it a story point value by complexity and have it factor into your velocity</li>
<li>Give bugs some arbitrary point value (3?) and use that in your velocity calculation knowing some will actually be bigger than the assigned value and some smaller</li>
<li>Don’t estimate bugs at all, and don’t factor them into your velocity calculations</li>
</ol>
<p>The more a team cares about velocity, the more passionate the estimation debate becomes. Particularly in an organization where development teams get scrutinized over their velocity, the conversation over how to get “credit” for bugs becomes far more important. I am not a proponent of focusing on velocity in general (again, probably another entire post on this one!), so I tend to skew towards method 2 or 3. Chasing perfect estimation is futile in general, but if your reality is that you <em>have</em> to track how much work your team is doing, find some number that feels reasonable and move on. If you come across the mega-bug that ends up requiring a rewrite of an entire part of your system, then turn it into a story and account for it properly. Because as we discussed earlier, a bug is just another piece of work in your backlog, and you’re free to call it whatever you want!</p>
<h2>Why not Make a Bug Team?</h2>
<p>Some companies attempt to solve the bug problem by setting aside a portion of their budget and creating a standalone “Bug Team”, or more nicely named “Maintenance Team”, whose job is to fix bugs and do all of that pesky platform maintenance that needs to happen. In my opinion, this is the absolute worst of all the ways you could handle bugs.</p>
<p>First, you are still not dealing with opportunity cost or giving yourself the flexibility to prioritize the next most important thing. It may <em>feel</em> like you are in complete control of your backlog because those bugs are no longer intruding. But in reality, it is just hiding the work and still puts you at risk of working on bugs that are far less important than what those team members could be doing elsewhere.</p>
<p>Second, <em>no one wants to work on a bug team</em>. It would be no fun to clean up someone else’s bugs all day long, never getting to put your own fingerprints on what is getting built. It is easier for the development team to let a bug slip by when they know they won’t actually have to fix it. And most importantly, it is hard to motivate a team whose work doesn’t feel like it is actively contributing to the product vision. Doing a “rotating bug team”, where a couple of the regular development team members focus on bugs for a few weeks each, doesn’t work either. It becomes really easy to avoid fixing the messy bugs or work really slowly on one knowing if you can just stall long enough, it will be someone else’s problem soon. A terrible concept all round.</p>
<h2>Bugs Aren’t Special</h2>
<p>All of this talk about bugs really boils down to one primary concept: <strong>bugs aren’t special.</strong> We get into so many debates about how to manage them or how they should count or who should work on them, but what we really want is to build products that our customers enjoy using. Bugs can get in the way of that, but so can building the wrong thing, or bad UX, or making inaccessible products. Focus on what your customers really need in order to love your product, and fix the bugs that keep you from accomplishing that goal.</p>
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

core/freeform

Startup Roadmaps and Prioritisation, by Ahmed El-Sharkasy

Evidence-Based Product Backlogs, by John Pagonis

Roadmaps & Prioritisation – Lessons Learnt the Hard way, by Ren Yi Hooi

Embracing the Art of Prioritisation by Emily Tate

How to Start a Bank from Scratch by Megan Caywood

How to Start From Scratch and Prioritise by Marcel Britsch

Courtney Wylie – Building Your Business Model When Your Customer is not Your User

Prioritization: How to get rid of Those Pesky Bugs?

Emily Tate

Comments

Read next