Pulling Yourself Out of the Fires

Pulling Yourself Out of the Fires

If you’re like most Product Managers, you find yourself constantly struggling to manage incoming priorities, especially when there are problems that directly impact your clients, customers, and ongoing plans.  It’s way too easy to wind up getting caught up in the constant firefighting efforts that happen on a day-to-day basis, and extricating yourself from the constant miasma of yelling, screaming, hair-pulling, and general chaos can often seem impossible.

There are some very simple things that you can do, starting immediately, that can help you to build a more rigorous and structured approach to these issues, and that can pull you out of the constant firefighting that you’re facing on a daily basis.

Manage Expectations

The best thing that you can do to step out of the role as fire-fighter is something that you should be doing every single day — managing the expectations of everyone around you.  As someone who leads through influence, as all Product Manager are, it’s important that we proactively define, refine, establish, and re-establish the expectations of everyone around you.  This means that you have to work at letting people know when, where, and how to communicate with you in order to be heard. It means that you have to think about when, where, and how you respond to others who come to you for assistance.  And it means that you have to understand how these choices and requests will affect the type of feedback you’ll get and how you’ll have to respond to it.  If you’re the kind of person who always drops everything to help whoever is standing at your desk asking you for assistance, that’s precisely the kind of interaction that you’re going to continue to have, so long as you permit it.  As a Product Manager, you’re the master of your own domain, and you need to be aware of what you’re doing, how you’re doing it, and what kinds of behaviors you’re encouraging — either directly or indirectly — that are making you a prime target for fire-fighting requests.

Establish a Triage Process

One of the worst things that we can do as Product Managers is establish ourselves as the sole or primary decision-maker on what needs to be fixed now, what needs to be prioritized in as soon as possible, and what can wait until later.  Rather, we should surround ourselves with a process that’s clearly established, and a system that involves more than just Product Management influence and input.  For example, one of the absolute easiest things that you can do to reduce the number of fire-fighting incidents that you face is to simply put a weekly, standing meeting in place with the right set of stakeholders.  That meeting is the proper forum for urgent issues, and those people are the ones who will decide what needs immediate action versus what can wait.  This meeting really serves two primary purposes — first, it separates you from the decision, so that if something really bad happens and it can’t be fixed the blame doesn’t fall entirely on you; and second, it establishes a feeling of buy-in to the decisions and to the product process as a whole with the people involved.  Also, and this is important, it lets these other teams see what’s being reported across the board — so they realize that their “one small request” is actually just one of a hundred that you got that week from all across the company and the customers.

Focus on Root Causes and Be Proactive on Them

It’s really tempting when you’re faced with a truly urgent problem — or worse, a series of urgent problems — to just try to knock each one down as they pop up, so that you can get back to your regular work.  The problem with this approach is that the issues that cause so much trouble with fire-fighting are often more like hydras than they are snakes — for each head you cut off, two more will grow to replace it.  Thus, it’s absolutely essential that for every issue that you and your triage team decide to tackle, you spend some significant amount of time and effort to determine what the root cause of the problem was.  This allows you to not just fight the symptom, but to identify and target the specific disease that’s causing it, and to prevent recurring issues from popping up again and again.  If it’s a training issue, you know what to update people on; if it’s a documentation issue, you know what to update in your Support Center; if it’s a technical issue, you’ll know what to slot in with a future sprint to resolve.  Keep your eye on these kinds of things, and challenge your triage teams to identify root causes — something as basic as database blocking conditions can surface as a variety of issues and can be relatively easy to resolve.

Make Decisions Based on Objective Data, not Subjective Feelings

Above all, don’t be afraid to insist that someone justify the work that they’re asking you to do for them.  Don’t hesitate to demand specific impacts, even if they aren’t the most detailed and reliable numbers.  How many items aren’t selling because of the issue?  How much in lost revenue opportunity is this causing the company?  How many people are spending how many hours doing workarounds because the issue isn’t functioning as expected?  All of these are reasonable questions to ask as a Product Manager who is being asked to redirect resources to solve someone’s problem that’s not in the plan.  And at the same time, don’t forget that you have a backlog, a tactical plan, and a strategic goal.  If someone is asking you for something that threatens your ability to deliver on any of these, it’s their responsibility to convince you to redirect those resources.  It’s your responsibility to balance the needs of the few with the needs of the many.  If someone can’t put numbers to their pain, then either (1) it’s really not as painful as they’re claiming, and/or (2) they don’t want to be responsible for the resulting decision — both of which are indicators that giving in on such a request probably isn’t in your (or your product’s) best interest.

Back To Top