Product Managers, on average, spend 52% of their time firefighting or on ‘unplanned’ activities. This means that more than half of their time is spent reacting to problems, rather than on strategic, value-creating activities. This is a shocking statistic that reveals an underlying problem with Product functions in most companies, where Product Managers are unable to provide the strategic value that they were hired to provide.
Product Managers tend to work in fast paced environments, within which a level of “firefighting”, or time spent resolving issues is a normal part of the job, however when this starts to encroach on a Product Manager’s productivity and/or morale, it becomes a huge problem that can derail the chances of success for the Product.
At my first Product Management role, I probably spent around 70% of my time firefighting. Below are the 3 biggest reasons why I fell into this trap and what I think I should’ve done differently:
1. I didn’t set daily or weekly goals
A normal day at work for me started by checking my email and Slack messages. I responded haphazardly to whichever messages seemed most important and my general goal was to get my unread messages down to 0, before I even began to think about what I actually wanted to accomplish on that day.
As the sole Product Manager in my company at the time, I was the de-facto source for all Product related questions and queries and so I often had a lot of demands on my time. However, I thought that my ‘busyness’ meant that I was being productive. I let other people dictate my priorities for the day and so ended up in a cycle where I was only able to work on my actual tasks once I was done tending to everybody else’s needs.
What I should have done differently:
I should have started every week and every work day, with clear goals in mind. These goals should have been related to strategic, value-creating Product work, i.e. analyzing new opportunities, scoping out solutions to existing problems, roadmapping our vision for the next quarter etc.
I should have blocked out time in my calendar, to work exclusively on the above goals and only then made time for answering all other non urgent messages in the time remaining.
2. I didn’t have a system for bug prioritization
In my early days as a Product Manager, I treated every bug equally. In fact, every time I would see a Jira notification for a new bug report pop-up in my email, I would stop what I was doing to read it. This was an absolute productivity killer. Not only was I interrupting my flow state, I was also then spending further time on trying to recreate the bug myself and then speaking with Developers on how quickly we could fix it.
When I was new to the world of software development, I assumed that what we were working towards was a state of having 0 bugs. I didn’t understand that this was a statistical impossibility and not the right goal to be aiming for.
Bugs were prioritized based on whichever ones the reporter made the biggest fuss about. Developers had changing priorities on an almost daily basis, and no one in the wider team had much transparency about what was broken, what was being fixed and what our upcoming priorities were. Our development team was constantly busy but together with the Product team, we delivered very little actual value to customers.
What I should have done differently:
I should have had a process for bug prioritization, one that was transparently communicated to the whole organization.
At a later Product gig, this was the bug prioritization framework that I used that served me well:
We defined a process for ‘critical bugs’ and a separate process for everything else. ‘Critical bugs’ were defined as anything that stopped a customer from using our product/service or an internal team member from performing a critical part of their role.
For example if customers could not place orders, this was classified as a critical bug. On the other hand, if our warehouse team could not use our shipping platform to print shipping labels and therefore could not ship orders, this would also be classified as a critical bug. We defined our core business as the ability for our customers to place orders and for our team to ship those orders to our customers and so anything that impacted this core ability, had to be looked at immediately.
We made our QA responsible for reading every bug ticket that was created. If it was a critical bug, then the QA would alert the Product Manager who would then decide on the next course of action.
All other bugs went into our bug backlog. Every 2 weeks, we had a meeting where as a team,we would go through all the new bugs that were reported, and determine whether their impact was high, medium or low. At all times, we made sure there was a prioritized list of the top 5 bugs we wanted fixed – usually these would be the ‘high’ impact ones, but on rare occasions we also decided to prioritize some quick fixes as well. If that list of prioritized bugs was less than 5, we would decide which new bug from our backlog to pull into that list.
In every biweekly sprint, developers had 1 day’s capacity to work on the bugs that were on the list. So slowly but surely, we made progress on fixing bugs, while making sure that ‘critical bugs’ were never put on the backburner. How much sprint capacity was dedicated to bug fixing, could be changed depending on the needs of the business at the time (ie it could be more leading up to a major launch and much less during more stable periods), but we tried not to stray from the 1 day capacity too often.
3. I didn’t understand the strategic nature of my role as a Product Manager
At my first Product Management role, I tried to be everything to everyone. I worked at a fast growing startup where everyone was expected to be resourceful and to plug whatever gaps they could. To me, that meant that I needed to be the de-facto problem solver for everything related to the Product, and as an early stage startup, there were Product related problems galore. From issues on our internal platforms that frustrated our teams and impeded their ability to perform their day to day tasks, to customers seeing incorrect pricing when they switched currencies, everyday felt like a battle to put out the biggest fires. All day long, colleagues would come to my desk to ask me for an update on an existing issue, tell me about a new problem they’d encountered or a new feature they wanted to see built. In the midst of this, I became a glorified ‘request handler’ and lost track of what I was hired to do to begin with, which was to create value for the business and our customers.
This is not an uncommon problem at early stage startups, where the Product function has not yet matured. The entire organization, including the Product Managers themselves can lack an understanding of what Product Managers are meant to be doing. Product Managers should be spending the majority of their time on tasks that will maximize value to their customers and to their company, tasks like; talking to customers & understanding their pain points, researching market opportunities and trends and driving product innovation. When this primary purpose gets lost, it can stunt the growth of both the Product and the Product Manager.
What I should have done differently:
I should have created processes that promoted a sense of transparency around mine and the Product team’s work. For updates on existing requests, no one should have had to come to my desk. Instead, our Jira workflow should have been structured in a way that clearly showed to anyone who was interested what the status of a specific request was.
The same level of transparency should have applied to the Product roadmap and all the Product initiatives that were being undertaken. While the roadmap was created in collaboration with the senior management, it was never explicitly shared with the rest of the company. As someone leading the Product function, I should have regularly and proactively shared the Product team’s vision with the rest of the company, along with the reasoning and justifications behind our Product initiatives. Without giving the rest of the company this look into our broader work, how did I expect them to see us as anything more than glorified bug fixers? Sharing the roadmap widely would also have created a stronger commitment to it – we would be highly discouraged from chopping and changing it in response to the latest fire or issue that we thought was important unless we had a very strong reason to do so. Wherever your roadmap lives, whether that’s on a Google Sheet or on a roadmapping tool like Aha, make sure it’s visible to the entire company.
In the face of constant fires, our instinct as a Product team was to put our heads down and silo ourselves. Instead, more transparency around our work would have helped. I should have shared with the team, my conversations with customers, the research I had done on our competitors and the results of the design workshop that we had taken part in so that the company could come to appreciate the larger role that the Product team had to play within the company.
Conclusion
It’s easy to get caught up in a constant state of fixing one fire after another when you work as a Product manager in a fast-moving and high-growth environment. However, Product Managers are hired to create strategic value for the company and for the customer and this needs to always be top of mind. Product Managers can do this by setting & focussing on weekly goals before they tend to day-to-day problems, having clear processes around bugs and other critical issues and also by proactively & transparently sharing their work with the rest of the company.
Do you have any other tips to share about how to reduce the time you spend firefighting? Let me know in the comments below:
Leave a Reply