How to talk about setbacks honestly

Choose a setback you can explain clearly

A useful example might be a feature customers didn’t use, a deadline you committed to too early, or a customer problem you misunderstood.

Choose something where you can discuss your own decisions. If most of the story is about what another team did wrong, it may be difficult to explain what you learned.

Before drafting, ask yourself:

• What were we trying to achieve?
• What fell short?
• What did I do—or fail to do—that contributed?
• Who was affected?

You don’t have to choose the worst experience of your career. Pick one with enough detail to explain what went wrong and how you handled it.

Name your part without taking responsibility for everything

Projects can go wrong for several reasons. Explain the relevant circumstances, then be clear about your contribution.

For example:

“The engineering team discovered a dependency that delayed the release. I’d already shared a launch date with sales before checking whether the estimate included that dependency.”

That gives the interviewer both the situation and the mistake you made.

You can explain why you acted as you did. Perhaps you thought an estimate was final or relied on a small amount of customer feedback. Keep the explanation focused on what you understood at the time and what you missed.

Walk through what you did next

Here’s an illustrative answer:

“I recommended building a saved-search feature after hearing repeated requests from a few customers. I assumed the need was more widespread than it was and didn’t check how other customers searched.

“After release, usage was low. I spoke with customers who’d tried it and some who hadn’t. Those conversations suggested that many changed their search criteria each time, so saving a search wasn’t especially useful to them.

“I brought that finding back to the team and recommended pausing the enhancements we’d planned. We’d already spent time on the first version, and we had to reconsider what to work on next. On my next discovery project, I included customers who hadn’t requested the feature and asked them to show me their current workflow before discussing a solution.”

The answer explains the assumption, the disappointing result, and the response. It also gives a specific example of how the PM changed their approach.

The original feature still underperformed. The learning doesn’t erase that.

Make the lesson something someone could observe

“I learned to communicate better” might be true, but it doesn’t explain what changed.

Think about what you did on a later project:

• Did you check dependencies before sharing a delivery date?
• Did you test a rough version before committing to a full build?
• Did you speak with customers beyond the people requesting a feature?
• Did you raise a concern earlier instead of waiting for the next review?

Choose the change that came from this experience. Explain when you used it and, if you know, how it helped.

If you haven’t had a chance to apply the lesson yet, say what you would do next time. You can be thoughtful about an experience without claiming you’ve already proved that your new approach works.

Prepare for the uncomfortable follow-up

An interviewer may ask, “Why didn’t you check that earlier?” or “What would you do differently now?”

Take those questions seriously. Return to the decision you made:

“I treated the repeated requests as enough evidence to build. Looking back, I should have checked how common the problem was before committing the team’s time.”

Then explain the check you would add. Who would you speak with? What would you test? What would make you reconsider?

A specific answer is easier to follow than a long defence of why the mistake was understandable.

Try a four-part outline

Write a few notes under:

1. What fell short: The gap between the intended outcome and what happened.
2. My part: The decision, assumption, or missed step you were responsible for.
3. My response: What you did once you understood the problem.
4. What changed afterward: Something you did differently, or what you would do next time.

Say the answer aloud. Check that you’ve explained the consequence as clearly as the lesson.

If background is taking over, use this guide to making a long answer clearer. You can work through the details in Remi before practising how to tell the story.