Trust the Engineers — Do Not Put Bugs on Your Roadmap

A very bright product manager at a startup asked me this morning: “Should bugs exist on my roadmap?” This is a fascinating question that comes up every few days or so. In the past, I have written about other seemingly simple questions like, “What is a product?” or “What is a release?” So, I figured it was time to take on this key question.

I responded to this customer with a hearty congratulations. It takes deep thought to ask what can appear to be the most basic of questions. I have interacted with over 1,000 product and engineering leaders about Aha! — so I know a good question when I hear one. And this is one of those questions that every PM grapples with, either knowingly or unknowingly. That is because the answer has a real impact on engineering.

Here is what I wrote:

You have touched on an important philosophical question….

There is no doubt — this is a question of personal philosophy. If you read my blogs, you will not be surprised to find that I have a strong point of view on this topic. But you ultimately need to decide how you and your team want to handle this. There is no right answer in this case — just considerations to ponder and tradeoffs to make.

So, I 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 my company focus on and understand 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 trust in your engineering team will be the ultimate decider. Because even if you answer, “Yes” to the first four questions, but say, “No” to the last one, you will feel compelled to carefully track and plan everything.

With that in mind, I see most teams choose one of two approaches to handle this. And as I mentioned, these approaches are based on the level of trust that exists between the product management and development teams.

Here are the two approaches based on where you fall:

I do not trust the engineering team If you do not trust the team, you will naturally be attracted to every discussion about what gets built. This means that 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. So, you will also need a consolidated view to stay sane and dictate which work is in vs. out.

You are most likely going to act and be known as the product czar who roadmaps big ideas and spends lots of time on the bugs, too. This approach can work, and in some organizations, it is actually preferred. The downsides are that it is a time suck for the product manager, visibility into bug fixes provides little value for the rest of the organization, and it is confining for the engineers.

I trust the engineering team If you trust the engineering team, you will happily acknowledge that every release has a “developer’s tax” that will cost you between 10 percent and 20 percent 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 acknowledgment also frees you to focus on the features that will create value for your customers and thought leadership in market — and make sure the rest of the organization understands them.

This approach gives the engineers more room to influence the product’s direction and feel accountable for decisions to improve it. And typically, the bug fixes will never need to be highlighted on a roadmap. The exception is situations where these fixes will impact customers. In these cases, you should certainly know about them, as should your colleagues who support the customers. And obviously, if you or someone else generates release notes, the fixes should be documented.

Even with a trust-based model, my 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 — I want to know about it.

At that point, I can decide to present it on the roadmap or not. Otherwise, I completely focus my time and the roadmap on features that create value for customers and the business.

I suggest that a trust-based model is best for you, your engineering team, and your entire company. Is your team not quite there today? Recommend this approach to your engineering leads anyway. Being proactive and trying it will create goodwill, build stronger relationships, and — ultimately — result in better products.