Ownership Behavioral: Recovering From a Technical Call of Yours That Went Wrong

In an Amazon product manager interview, you are asked to describe a technical decision you made that later went badly wrong. Explain what you decided and why it looked right at the time, how and when the problem showed up, what you did to recover, and what you would do differently now. ```hint Own it, then fix it Pick a call that was genuinely yours and that genuinely failed. Keep the setup short and spend most of your time on how you spotted the failure, how you limited the damage and told the people affected, and the specific habit you changed afterward, without passing the blame to engineers or vendors. ``` ### Clarifying Questions - By "technical decision", do you mean a call about how something was built (architecture, platform, vendor, build versus buy), or does a product decision with major technical consequences count? - Should it be a decision I made alone, or is one I was accountable for as product manager after weighing the engineering team's options acceptable? - Are you looking for a failure that surfaced after launch, or does a decision that unraveled during development count as well? ### What a Strong Answer Covers - A real technical decision the candidate owned, with the context, the options considered and the reasoning at the time. - How and when the failure surfaced, its measurable impact, and an honest account of the candidate's own part in it. - The recovery: immediate mitigation, communication with the people affected, and the trade-offs in the fix. - The outcome after recovery, stated with numbers. - A specific lesson and a concrete change in how the candidate makes or de-risks technical decisions since. ### Follow-up Questions - Looking back, which signal available at the time should have told you the decision was risky? - How did you tell your manager and the affected teams, and what exactly did you say? - Describe a later decision where you applied what you learned. What did you do differently?