How to Handle Failure as a Product Manager

As a product manager, your team looks to you for guidance, support, and leadership. It’s your job to not only shepherd a project from initial concept to a fully formed product; it’s also up to you to inspire your team, give them the tools and support they need to do their best work, and help them maximize their impact on your team’s goals.

But what about when things go wrong?

Failure can often be significantly more valuable from an educational perspective than runaway successes. Despite this, far too few companies and product teams spend enough time analyzing and learning from their failures. Even fewer product managers make embracing failure a central part of their product management style — so how are you supposed to handle failure if hardly anybody wants to talk about it?

In this post, we’ll be looking at several ways to handle failure as a product manager. We’ll be looking at some of the most common reasons for failure in product teams, as well as how you can view failure differently to learn more from your mistakes — and hopefully avoid them in the future.

Acknowledge ‘Who’ and ‘Why’ — but Focus on ‘What’

When we make mistakes, it’s all too easy to focus on why things went wrong and who is responsible.

Seeking out and assigning blame is often one of the first steps managers take when presented with failure. However, although it’s important to acknowledge why something went wrong and who was responsible, this information is of limited utility.

Put another way, rather than singling out an individual for making a mistake, you should focus on what you’re going to do about it and what you should learn from the experience.

When we assign blame, we might feel better about identifying the person responsible for the mistake, but we gain very little in terms of actual solutions. Figuring out who screwed up does little to actually solve the problem besides finding someone to deal with it, and can often result in the person who made the mistake feeling singled out or attacked. This, in turn, can make your team members reluctant to admit mistakes or speak up if they’re not sure about something.

“What” questions, on the other hand, are incredibly valuable. In the case of determining what went wrong, “what” questions are often the first step in identifying an actual solution to a tangible problem. They’re also highly instructive; examining what went wrong often reveals underlying problems, such as incomplete user research data or a flawed hypothesis, that should serve as the starting point for solving the problem.

In short, be sure to acknowledge the who and why when things go wrong — but make sure you’re laser-focused on what you’re going to do about it and what you can learn from it.

Make Sure Your Goals Are Realistic

One of the most common reasons for failure in product development is setting overly ambitious (or even impossible) targets.

Setting unrealistic goals doesn’t do anybody any favors. It puts your team under immense pressure to achieve a result that might not even be feasible. It can create toxic, punishing work environments and cause intense stress, both of which can have a detrimental impact on your product. Unattainable goals can also cause division in teams and highlight disconnects between a product manager’s vision for a product and the team responsible for developing that product. This can create tension, resentment, and bitterness, none of which will motivate your team to work harder or smarter.

Unrealistic targets also call your leadership as a product manager into question. There’s certainly nothing wrong with setting ambitious targets and pushing your team to exceed them, but consistently punching above your weight can be indicative of poor planning or misaligned expectations.

As a general rule, it’s better to under-promise and over-deliver than it is to set targets your team has little chance of meeting. By all means implement stretch goals, but stay focused on what your team can realistically deliver.

Get Out of Your Own Head

Many product managers are highly analytical, introspective thinkers. Attention to detail, a fastidious work ethic, and an analytical mind are all incredibly valuable assets for any product manager — but they can also result in overthinking even the smallest problems.

Although it’s vital to truly understand why something went wrong, it’s just as important to know when to move on and walk away. Overthinking problems not only wastes time you could use more productively, it can also create “tunnel vision” in which you can’t see the forest for the trees.

Given that your team looks to you for guidance, this can be a serious problem.

When things go wrong — and they will — it’s important to remember that your primary role as a product manager is to provide strategy and vision for an entire product, not just certain elements of that product. The more time you spend stuck in the weeds micromanaging a problem or overthinking an issue, the less time you’re spending actually guiding your team toward the finish line.

Of course, forcing yourself to stop overanalyzing things can be a tall order, especially if you’re a keenly analytical thinker. That’s why choosing the right team members is so crucial; you should be able to confidently delegate analytical tasks to your subordinates and ask them to figure out why something went wrong while you focus on the bigger picture.

Accept Responsibility — Even When It’s Not Your Fault

As hard as it can be to take your hands off the wheel and delegate responsibilities to your team members, it’s important to remember that ultimately, the buck stops with you.

There are situations in which you will be held accountable for the mistakes of others. However, willingly assuming responsibility for your team members’ mistakes can be an excellent way to demonstrate humility and integrity, as well as proving to your team members that you’ve got their back.

However, although assuming responsibility for your team can demonstrate strong leadership, it’s important to do so in the right way. Rather than falling on your sword for every little mistake, ask yourself why your team members made the mistakes they made. Did they genuinely drop the ball, or did you fail to give them the resources or support they needed to achieve their goal? Did someone misunderstand a task to be completed, or did you fail to explain it sufficiently? Did a team member fail to ask for help, or did you fail to hear them?

Accepting responsibility for others’ mistakes can be very difficult, especially if you genuinely weren’t responsible for what went wrong. Throwing your team members under the bus might save you some face (or even your job, in extreme cases), but it will accomplish little besides undermining your leadership and creating tension between you and your direct reports.

Put another way, try to fail — and learn — as a team.

Communicate Problems Early and Proactively

Sometimes, we make mistakes so serious that there’s very little we can do to contain the fallout. Most of the time, however, the potential impact of a mistake can be mitigated by proactively communicating with key stakeholders.

One way to think about this is to consider it a matter of solutions versus excuses.

Let’s say one of the developers on your team tells you about a critical security flaw in your product’s two-factor authentication system. The developer tells you that the vulnerability is very serious, but can be fixed — but it will take more time than you have.

Essentially, you have two options. You could either:

• Proactively inform project stakeholders of the security flaw, provide an overview of the proposed solution, and offer a provisional timeline for that solution
• Wait for the deadline to pass, apologize, and offer excuses after the fact

If you were an executive or key stakeholder, which of these two options do you think would have the better result?

Exactly.

Most of the time, the sooner you sound the alarm about a potential problem, the more understanding stakeholders are likely to be. Proactively communicating about serious issues not only gives more people more time to devise a solution, but also demonstrates that you’re aware of emerging issues and are on top of managing them.

Missed deadlines and unexpected problems can be unavoidable, but how you choose to respond to and manage these issues can make an immense difference.

Fail, Learn, Repeat

Seeing mistakes as an unavoidable inevitability is the first step toward acknowledging that there is only so much you can directly influence and control. Oftentimes, the only thing we can control is how we respond to failure and how we learn from it.

Ideally, you should structure your product roadmaps in a way that allows for mistakes to be made. When that isn’t possible, all you can do is support your team as best you can, offer guidance, leadership, and support to your team when they make mistakes, and try to see the value in what mistakes can teach you.

If you found this article helpful, you may also like what we do at Collie — Collie is calm engineering management for teams who love async communication 🤜🤛