Aha! Roadmaps | Should I put bugs on my product roadmap?

We are often asked how to manage bugs in Aha! Roadmaps and we have a strong point of view, but in this case, the answer depends a little on your unique team. Ultimately, you the product manager need to decide how your team will handle bugs. There is no right answer in this case, just considerations to ponder and tradeoffs to make.

Click any of the following links to skip ahead:

• Questions to start with

• If you don’t trust the engineering team

• If you trust the engineering team

• Recommended approach

Questions to start with

We suggest that you start by asking yourself the following questions:

• Do I need to spend more time defining features than tracking bugs?

• Do I need to help the non technical folks in the company focus on and understand the new features?

• Is our product generally stable?

• Is our market competitive?

• Do I trust the engineering team?

The first four questions will help guide you to the answer, but ultimately trust is going to be the ultimate decider. Because even if you answer “Yes” to the first four questions but then “No” to the last one — you are going to feel compelled to carefully track and plan everything.

Top

If you don’t trust the engineering team

If you don’t trust the team, you will naturally be attracted to every discussion about what gets built. Ultimately, both features and bugs will find their way into your planning backlog and be reflected on the roadmap. While you may not put every little tweak or fix on your roadmap, you will need to be the authoritative source for everything that gets built. This means that you will need a consolidated view to stay sane and dictate. Most likely, you will act and be known as the product czar who roadmaps big ideas and spends lots of time on bugs as well. This approach can work, and in some organizations it’s actually preferred. The downside is that it’s a time suck for the product manager, visibility into bug fixes provides little value for the rest of the organization, and it’s confining for the engineers.

Top

If you trust the engineering team

If you trust the engineering team, you will happily acknowledge that every release has a “developer’s tax” or "technical debt" that will cost you between 10% – 20% of their time. You will not worry about that time and all of the little bits because you will have faith that engineering will focus on the enhancements and bug fixes that are most needed for customer happiness. This acknowledgement frees you to focus on the features that will create value for your customers, thought leadership in the market and ensuring the rest of the organization understands them. This approach further gives the engineers space to influence the direction of the product and feel accountable for decisions that get made to improve it.

Typically, the bug fixes will never need to be highlighted on a roadmap but our general rule is that if a bug is going to take more than one day for an engineer to fix or have a meaningful impact on a customer — you (the PM) should know about it. And at that point, you can decide to present it on the roadmap and release notes or not.

We suggest that a trust-based model is best for you, the engineering team, and your entire company. Even if you are not quite there today — recommending this approach to your engineering leads and trying it will create goodwill and build stronger relationships. Focus your time and the roadmap on features that create value for customers and the business and ultimately better products.

Top

Recommended approach

We suggest that a trust-based model is best for you, the engineering team, and your entire company. It's always better to start with or build towards a culture of mutual trust.

With that in mind, we see most teams choose one of the two approaches we've mentioned to handle this. As mentioned, it is typically driven by a sense of where a product manager can truly add value and the level of trust that exists between the product management and development teams.

If you would like to read more about our philosophy on how product managers and engineering teams can work together, scroll through our blog. We write regularly about how to achieve your strategic vision even when you have sophisticated cross-functional dependencies.

Top