Original practice question. The scoring rubric is our teaching guide. How we research and score answers
TL;DR: Choose a real project where you made decisions that contributed to the outcome. Describe the situation briefly, be specific about what went wrong and your part in it, show how you responded, and finish with a learning that changed a process: pre-registered success criteria, evaluation before launch, kill criteria, or how you set expectations. Ownership and the changed process are what make the story worth telling.
How to approach it
Use STAR-L: situation, task, action, result, learning. Pick a story with real stakes and a clear cause you can explain. Avoid stories where you were a bystander, where the failure was trivial, or where the lesson is generic ("communication matters").
A strong answer
Employers say what they want here in their own words. Amazon's product manager interview guidance asks candidates for examples showing "how you've taken risks, succeeded, failed and grown", and its Earn Trust principle expects leaders to be "vocally self-critical, even when doing so is awkward or embarrassing" (both checked November 2026).
What to put in the story.
| They want | They avoid |
|---|---|
| Your decisions and their consequences | Blaming the model, the data team or leadership |
| A specific cause | Vague "it didn't get traction" |
| How you responded once you saw it | A story that ends at the failure |
| A learning that changed process | Platitudes |
An illustration of the structure (adapt to your own experience; never invent):
Situation. A team was building an AI assistant to draft responses for an insurance claims team. Leadership expected it to cut handling time by half.
Task. The PM owned launch and the success metric.
Action. The team launched to all claims handlers after a strong demo on curated examples. Within two weeks, handlers stopped using it: drafts were wrong on complex claims, and checking them took longer than writing from scratch. The PM read 100 real drafts with handlers, found that 70% of errors came from two claim types the demo set had not included, narrowed the assistant to simple claims, and built an evaluation set of 300 real claims.
Result. On simple claims, about 40% of all volume in this illustration, accepted drafts rose from roughly a third to over 70% and handling time on those claims fell by about a quarter; complex claims stayed manual. The headline target of halving handling time was missed; the narrower product worked. (Illustrative figures: use your own, and say what they were measured on.)
Learning. "I now build the evaluation set from real traffic before any launch and write the success threshold down before seeing results. I also present reliability as a separate milestone from the demo, so stakeholders do not anchor on a demo's numbers." That learning changed the team's launch checklist. Turning a lesson into a mechanism is a recognisable practice: AWS describes its correction-of-error reviews as focused on "corrective actions, not just documenting failures" (AWS blog, 2022). A learning that lives in a checklist other people use is stronger evidence than one that lives in your head.
Follow the flow, one stage at a time.
Illustrated sequence; animation speed does not represent processing time.Read diagram description
Give the situation briefly, state your own responsibility, describe what you did including your mistakes and how you responded once you saw the failure, report the honest outcome, and end with a learning that changed a process others now follow.
Tips. Keep the situation to two or three sentences. Spend most time on actions and learning. Use numbers where you have them. Be ready for follow-ups on what you would do differently.
What interviewers probe next
"What would you do differently if you started again?" Name the specific earlier decision (launching broadly on demo evidence) and the alternative (shadow mode on real claims first).
"How did you handle the stakeholders who expected 50%?" Explain how you reset expectations with data and a narrower plan, and what you said.
How it's scored
| Signal | Weak | Hire | Strong Hire |
|---|---|---|---|
| Ownership | Blames others or the model | Acknowledges a role | Names own decisions that contributed, without self-flagellation |
| Specificity | Vague failure | Clear cause | Diagnosis with evidence (traces, data) and a concrete response |
| Learning | Platitude | Personal lesson | Process change that others adopted, with how it was applied later |
Common mistakes
Choosing a "failure" that is really a success in disguise.
Blaming model limitations without describing your decisions.
Ending without a concrete change in how you work.
See STAR-L stories.