As a Product Manager, you will know that demands on your time are high. New projects are constantly landing in your inbox and it can be easy to spend a lot of time on tactical activities and fixing issues – often known as firefighting.
Firefighting is a common practice in product management. It’s a topic we have covered before (see our blog from 2016 here). Since then, the problem seems to have increased. Our most recent industry survey shows that respondents felt that 52% of their time is spent firefighting.
When you’re firefighting, in many respects, what you are actually doing is ‘papering over the cracks’ of an inefficient organization. In an ideal world, there would be processes and teams that deal with any ‘business as usual’ issues. This would allow product management to focus on the more strategic challenges of understanding customers and crafting the product vision for the future.
Firefighting has the potential to monopolize the majority of your time. At its worst, it can consume most of the resources from the entire product team and create a culture where firefighting becomes the assumed and accepted norm.
So, what can you do to break the firefighting cycle and become a more proactive product management function? In this blog, I will examine some of the tools that will help you to stop firefighting.
While firefighting is particularly prevalent in new product functions, where the role of product management is not clearly defined, it can affect more mature teams too. As product teams, we work with lots of other functions across the business. If those functions aren’t clear about what product management does, they can view any incoming issues that touch on the product as being the responsibility of the Product Manager to sort out. This is very attractive to them, as it gets the issue off their plate!
Often, the very act of firefighting perpetuates this perception! If product managers are seen to be firefighters, that’s what others assume their job is. And, occasionally we make life worse for ourselves because we want to be seen as the hero – the one who rides to the rescue to sort out any issue. It makes us feel good, yet, this again perpetuates an incorrect perception of the function.
So, how can we change this perception? The best way to start is to say “no” more often. This sounds simple but saying no is often harder in real life – particularly where a firefighting culture is deeply embedded, or when we’re trying to create a good impression in a new job.
If someone says to you, ‘any product issue – the product manager should sort out’, maybe your response should be, ‘any product issue – the product manager should sort out who sorts it out’. Yes, we need to make sure it’s fixed – but only by finding its most appropriate home so that when it happens again someone else deals with it.
I don’t think you can ever eliminate firefighting from product management, but you can minimize it by evangelizing what product management’s role is and the value it brings when working more strategic activities. See our thoughts on this – Selling the value of product management.
As a Product Manager, I was once accused of having ‘slopey shoulders’. At the time, I’m pretty sure it was not meant as a compliment! But changing perceptions will encounter some resistance at first. I certainly didn’t feel like I was ‘passing the buck’. I felt that I was placing the issue in the most appropriate place.
In hindsight, this ensured that I was utilizing my time effectively while allowing the relevant expert to fix the issue. This was good product management instincts. Chances are, in a cross-functional environment, it will be far more appropriate for another team to pick up the corrective action.
The 5 Whys
Finding the most appropriate person to resolve the issue becomes more apparent when you understand the root cause. A famous technique for establishing the root cause of any problem is the ‘5 Whys’.
The 5 Whys is a bit like the technique that small children use to understand the world. Children keep asking ‘why’ until you reach exasperation point and say, “Because I said so!”
At its most basic level, it’s about asking why until you drill down the levels to the core issue. 5 levels always seem to be enough to reach this root cause. The classic example given to illustrate this technique is to consider why a monument in Washington DC was deteriorating. The stonework was crumbling and, as a major tourist attraction, lots of money was being spent to keep it looking good.
The 1st why – Why was the monument deteriorating? Harsh chemicals were repeatedly used to clean the monument.
The 2nd why – Why were harsh chemicals needed? They were needed to clean off a large number of bird droppings plastered over the monument.
It would be easy to stop here and come to the conclusion that some form of bird-scaring device was needed. But if we continue through the process we can find another option that addresses the true root cause.
The 3rd why – Why were there a large number of bird droppings on the monument? There was a large population of spiders in and around the monument. These were extremely tasty and abundant for the birds to eat.
The 4th Why – Why was there a large population of spiders? Vast swarms of insects, on which the spiders feed, were drawn to the monument at dusk.
The final and 5th why – Why were swarms of insects drawn to the monument at dusk? The answer, the lighting of the monument in the evening attracted the local insects.
So, the solution was to change how the monument was lit-up in the evening to prevent swarms of insects.
From this example, we can see why it’s important to drill down to the root cause and not the first cause we come across. When stuck in a cycle of firefighting, the temptation can be to put in a sticking plaster solution so that the immediate problem is off your desk, but that may not stop it coming back again in the future.
Just as we know not all projects that will pass over our desks are created equal, we should also realize that it’s the same with problems. Not all problems are deserving of your time and attention.
When a new issue or request comes to you, do you have a process for deciding how you should act? A little mental checklist that you go through to try and avoid ‘knee-jerk’ reactions and ‘time sinks’.
Particularly if you are new to product management, the temptation is to think, “It’s to do with my product, so it must be my responsibility.” By having a quick method of analyzing incoming requests it will help you avoid this trap.
The following method allows you to analyze incoming issues and make decisions on how to prioritize them.
When the problem arises, first think if you are the right person to handle this, or is it better sat somewhere more appropriate, with the specialist skills to resolve?
If it should sit with you, is it the right time to deal with it? Sometimes you can wait on a problem and it will go away or resolve itself. But, if it doesn’t go away, you can plan an appropriate time to devote your attention to the problem.
Another key thing to consider is whether you have enough info to progress it. Often you will need to do research before you can fix something. This could be reading up on possible solutions, but often it will involve bringing others into this discussion. Even if it is most appropriate that the problem sits with you, it should not stop you from leveraging the skills of others to resolve it. You should always be thinking ‘how are we going to solve it’ rather than ‘how am I going to solve it’.
A final thought on prioritization is to make sure to organize your daily activity. Knowing whether you have adequate time to devote to fixing an issue, depends on you knowing what your output for each day should look like.
One thing I do at the end of each day is to create a to-do list of the things I want to get done tomorrow – the things that will help me achieve my important goals. The next day when I break for a coffee and return to my desk, I review it and ask myself if what I’m going to work on next is really the best option. This is a great habit to get in to and will allow you to make better decisions on prioritizing your time.
So, how do you leave the firefighting behind and become more proactive and strategic? Firstly, it is important that we educate the business and change perceptions around what a product management team does.
Then we need some tools that will help us find the root cause of a problem, what the solution should be, and where that corrective action should sit. The 5 Whys will help you find a home for it, giving you more time to concentrate on your strategic activities.
Finally, becoming more proactive and strategic in your work makes it a more rewarding job. It feels much better than constantly being reactive – cleaning up the messes left by others. And you’ll be providing more value to the business and, in turn, making yourself worth more to the business!
Director, Product Focus