As Product Managers, we’re often right on the front lines when things start to go sideways — when the demo fails in the middle of a big customer presentation, when the Ops team can’t deploy the “fully-tested” and “ready for production” release, or when your customer acquisition and retention numbers start to dip.  But rarely do we really talk about or adequately prepare ourselves for how to properly deal with these kinds of situations — the best Product Managers I’ve known have been optimistic and pragmatic, but when emotions are hot and fires are burning, how can we effectively jump in with productive direction and effective problem-solving skills?  Here are some ideas…

Diffuse the Emotion, Focus on Facts

Disasters are emotional — people respond immediately and rashly when things start to go sideways, and these irrational responses often make things worse more often than they make them better.  As the Product Manager, we need to be not only the practical hub around which the product revolves, but we also need to be the emotional rudder of the team, keeping them driving as close to center as possible.  When things are flying fast and the plane seems to be going down in flames, our emotions get in the way of actually getting into the cockpit and pulling on the stick.  Most often, the emotional responses are simply driven by a lack of a central resource for information — we need to be that resource, because we are usually in the best position (and with the best relationships) to collect information and facts dispassionately and without people worrying about the results of sharing information.  Remember, when things are going bad the people above are angry and the people below are scared.  We need to work to buffer between those two extremes, and provide a conduit of facts and conclusions that drive us toward solving the problem, and not hiding information out of fear or making rash decisions our of anger.

Regular, clear communication of these four points is essential to managing a catastrophe effectively:

• What exactly happened — what failed, when, and where.  No names, that’s for later (see below).
• What is the impact — what customers are impacted, how much revenue is at risk, what’s the scale of the damage.
• What is the plan — what is being done right now to effect change, when is it planned to be done, and what will the result be.
• When is the next update — based on the plan, when can the team expect to know more.

I’m a firm believer in hourly updates sent when something is really going wrong — more frequent if absolutely necessary — and sent whether there’s new information or not.  This sets a cadence that makes input more manageable and constrains the flow of information so that rash decisions are less likely and expectations can be managed.

Create a Vision and Drive Toward It

When things are going wrong, everyone is focused on the problem at hand and the damage that it’s causing (perceived or real).  As Product Managers, we need to exert our influence and spend some of that social capital that we’ve built up to turn this around and point people toward the end state that we all want to get to — what does resolution look like, from a realistic perspective.  Is the goal a rollback of the code to a prior state?  Make that vision clear to everyone.  Is the goal to have developers working in the live environment to fix the problems?  Then make that vision clear to everyone.  Focusing people on what success looks like changes their lens on the situation, even in the face of complete and abject failure.  We don’t want people focused on how bad things are, because they’re actually likely to make things worse as a defeatist attitude sets in; rather, we want people to see the light at the end of the tunnel while they’re working to fix the problems.  This gives them motivation to make that vision happen and to bring it to life.  Negativism in the face of a disaster feeds on itself, and that’s something we simply can’t allow to happen.

Put Off Blame and Root Cause Until the Fire’s Out

There’s a time and a place to perform a root cause analysis and to determine who’s responsible for whatever may have happened.  That time is not in the middle of the problem.  Even if it was a specific person who did a specific thing to cause the situation, shaming or punishing that person while the problem exists is pointless.  They may actually be the best person to actually fix the problem, so “putting them into their place” isn’t going to make them particularly happy about solving the problem.  We want a culture that’s focused on results, not blame; we want everyone on the team focused on the problem at hand, not the safety of their jobs; we want people focused on doing whatever they need to in solving the problem, not second-guessing themselves so that they don’t become the next target of scorn at the hands of the CEO.  You don’t see arson investigators wandering through a burning building — and we shouldn’t be digging in the embers while the fire’s still burning around us.  There’s more than enough time to perform root cause analysis and retrspectives on the situation after the fire is out.

Keep decisions factual, keep the team focused on solving the problem, and then dig into what went wrong and how to prevent it.

To mangle Smokey the Bear’s famous line: “Only YOU can prevent Product fires.”