I’ve found that no matter what, part of the product manager interview process involves asking the failure question to prospective candidates.

The popular failure question usually looks like the following:

“Tell me about a time when you failed.”

It’s a daunting question, especially if you’re not used to interviewing as a product manager!

In the past, whenever I heard this question, I went immediately on the defensive. To me, it felt like the interviewer was out to get me.

But now that I’ve been on the other side of the interview process as an interviewer, I finally understand why employers ask this thorny question about failure.

So, let me first share with you the reasons for why employers ask this question, so that we understand what they’re trying to get at. Then, I’ll share a framework for how to best address the question.

Why do hiring managers ask about my failures?

Let’s clear up a common misconception about why hiring managers ask the failure question as part of the product manager interview.

Hiring managers aren’t asking this question to make you appear weak. There’s no power dynamic at play here.

After all, if the hiring manager has already invested so much time into you to bring you into the interview, they’re already invested in your success.

If they were really out to get you, they wouldn’t have even interviewed you in the first place.

The key thing to keep in mind about product management is that product managers are also products. So, we need to understand the pain points of our customers – and here, our customer is the hiring manager.

Why is it that hiring managers ask the failure question? What pain do they have, and how does this question help them solve their pain?

Product managers fail all the time – it’s just part of the job. And, given that product is multiplicative, failures have resonating downstream impacts within the hiring organization.

So, the hiring manager is looking for antifragility.

What is antifragility? It means that you get stronger with every failure, rather than weaker with every failure.

Hiring managers need to ensure that their organizations become more and more robust and resilient over time.

If they bring someone who will crumble under failure, that crumbling will spread like a disease across the organization.

If they bring someone who handles failure with gracefulness, maturity, and wisdom, the organization will most assuredly continue its growth.

So, hiring managers want to see that you have the humility to admit mistakes.

They want to see whether you have the courage to self-reflect.

They want to see whether you have the ability to adapt and course-correct.

And finally, they want to see how effective you are at drawing lessons from failures, and in applying those to the organization to make the organization antifragile as well.

That’s why they ask you the failure question. It’s not to assess whether you’re perfect or not, but whether you’re antifragile or not.

Now that we’ve established the primary reason for why hiring managers want to know about your past responses to failure, we can talk through a framework for how to address the question.

Framework

Remember that when answering product management questions, you’ll want to approach them with frameworks.

After all, product management is all about twists and shifts in context, so you don’t want to have a canned response – you’ll want to be able to speak to failure easily on the fly.

Below is a framework that we highly recommend for discussing previous failures.

1. Provide the context and the situation that led to the failure.
2. Discuss the failure and its impact on the organization.
3. Highlight your contribution to the failure.
4. Walk through how you mitigated the failure.
5. Reflect on how you made your organization more resilient to future failure.

Note that a solid answer to the failure question will take about 10-20 minutes to discuss, so be sure to practice with that timing in mind.

In other words, if you have a 1 hour interview ahead, you’ll likely need to address a behavioral question (such as this one) and a case question (such as the popular Metrics Analysis interview question).

Why do we suggest this framework for tackling the failure question? I’ll break it down piece by piece.

Context

First, context is crucial in product management. Interviewers need to understand that you know how to frame a narrative.

They’re assessing how quickly you can bring others up to speed, even if they had no prior context to start.

Impact

Second, you don’t want to bring a non-impactful failure up for discussion. Again, the hiring manager doesn’t expect you to be perfect.

It’s more important for you to demonstrate that you have the ability to survive a catastrophic failure.

So, you’ll want to make sure that you talk about one that is quite meaty and has impacts on the organization.

After all, product managers don’t work in vacuums. Their failures and successes flow downstream into the rest of the organization and into their customer base.

You want to demonstrate to hiring managers that you have awareness and empathy for your downstream stakeholders, and that you understand the magnitude of your responsibilities.

Ownership

Third, you want to demonstrate ownership. You want to show that you can handle the pressure and that you have humility.

Product management requires intense self-control over your own emotional state. After all, you’re working every day in high-stress situations.

So, when you admit to your failure, you don’t want to sound defensive or angry.

But at the same time, you also don’t want to beat yourself or attack yourself. Furthermore, you don’t want to claim the blame for events or factors that were outside of your control.

If you do that, then it demonstrates that you don’t have a good sense of what your areas of control are.

As you talk through your failure, do so dispassionately. Openly and humbly admit your flaws and contributions to demonstrate your ownership.

Mitigations

A failure isn’t necessarily bad in the long run, as long as you mitigated the impact and extracted maximum learnings from the situation.

So, you need to demonstrate to the hiring manager that you know how to manage crises and how to mitigate impact.

If you don’t have anything to say about how you fixed the failure, it means that you’re probably not being proactive enough in your day-to-day work. If that’s the case, you may want to take some additional time to gain those experiences in crisis management and impact mitigation before you attempt to interview as a product manager.

Growth

This portion comes last, because it happens last chronologically. However, it’s the most important part of the question. 

After you finish discussing the reality of the failure, talk through your learnings.

You want to demonstrate that you’re a fast learner and that you understand how to prevent situations like this from happening again.

In other words, you should be conducting a retrospective on your failure. Identify the root cause of your mistakes, and demonstrate that you have the capacity to learn from your mistakes and to self-improve.

You don’t just want to talk about what you could do better next time, however. You need to discuss what you actually implemented to ensure that the organization grew from your failure. 

Again, part of your job as a product manager is to implement processes that will make the organization stronger.

Using failure to create strength is the very definition of antifragile. Therefore, you should discuss the new strengths that your organization gained from your failure.

Example Response

As an example, here’s a time when I did something completely wrong as an associate product manager – and how I talked about it in interviews to demonstrate my capabilities.

As part of a roadmap exercise that I was doing as an internal platform product manager, I had planned on migrating and centralizing all of our internal-facing functionality into the internal Salesforce platform I owned, since that was something that our executives had asked for and it was something that I thought would make sense.

With centralization, we wouldn’t have to deal with distributed code, and our tools would all be able to draw on the same databases and the same types of functionality.

The executive team had explicitly asked me during our monthly product meeting that I should come to the next meeting with a clear project plan of how to get everything onto Salesforce, and to determine how long it would take and what sequencing to use for the projects.

However, what I had failed to realize was two things: the complexity of the work, and the cost of doing things with Salesforce Apex.

There aren’t many good Salesforce Apex engineers, so I was essentially bottlenecking all of our capabilities on whether we could recruit more Salesforce engineers.

That’s a bad bet – I should have considered that other kinds of developers are more readily available.

In fact, I should have considered whether I could have taken more of our code out of Salesforce into Javascript since that would have given us higher velocity at lower cost.

The other thing that I failed to understand was that Salesforce is not a relational database, so using it to perform queries is non-performant and prone to breakage. Much of that work could have been done in Javascript instead.

But, because my executives wanted it, I figured I should do it. I hadn’t dug deeper into understanding the pain that they had – essentially, that they perceived our velocity was too slow, and that centralizing would help to save on costs. 

If I had dug deeper into their pain points, rather than accepting their mandate to centralize all things on Salesforce, I would have come up with a better solution. 

It was after my engineering lead and I talked that I found out I had made a grave mistake in trying to centralize all things on Salesforce. From there, we analyzed what would make sense and what didn’t make sense, and crafted a talk track to defend the decision and to provide insight on how we could make the company go faster at lower cost.

The price of my mistake was that I caused our executive team to thrash. In other words, I caused them to need to change directions.

They were gearing up to kick off a hiring spree for Salesforce engineers, and that wasn’t the right strategy at all. That’s a lot of time wasted from the most senior people at my company.

On top of that, I hurt my relationship with my engineering lead, who I should’ve kept in the loop for talking through something as technically challenging as a platform roadmap.

I learned from that experience that I should always dig deeper for the root pain point, even if the mandate comes from the executive team.

Also, I learned that I as I build roadmaps, I should loop in engineering so that we have a better sense of the tradeoffs.

From that point on, each roadmapping session I did was alongside my engineering lead, which meant lots of saved time and a more unified stance and a more bought-in team.

On top of that, we learned not to cave in to executive pressure.

We implemented a new gut check for every roadmap planning session after this experience. When considering whether to tackle an initiative or not, we would acknowledge out loud whether part of the reason why we were doing something was because our executives had told us so.

If we found that we weren’t taking the due diligence to come to the conclusion ourselves that it was the right thing to do, then we would take an action item to go talk through the mandated initiative with executives to better understand why they were asking for it.

Summary

The amazing thing about life is that failures are so jam-packed with learnings, and learnings are the key ingredient to success.

It’s totally fine to fail, as long as you know how to extract the maximum in learnings and minimize the impact of the failure.

Product managers constantly face failure, so it’s important that we can demonstrate to our future employers that we can handle failure and use it as a powerful learning opportunity to make our organizations become even stronger.

As you practice the failure question in preparation for your interviews, you’ll find that you become better at everyday product management too. Keep it up!

 

---

 

Interested in learning how to dominate these types of product manager interview questions and land the product manager job? You might want to check out our popular course: One Week PM.