Amazon Leadership Principles — Behavioral Stories (STAR)

Validating real customer workflows (bulk excuse creation)

• Amazon LPs — Customer Obsession · Dive Deep · Ownership · Learn and Be Curious
• Situation — Early on the attendance team, I built a feature for admins to create attendance excuses for students. In requirements I noticed admins had to search and add students one by one. I asked our PM; the explanation was that excuses were usually for individual students, so a search-and-select flow was considered sufficient.
• Situation — I accepted the assumption instead of validating it with actual customer workflows — looking back, that was my mistake. I should have asked for real usage examples or spoken to support before finalizing the design.
• Situation — After release, we received multiple support tickets. A common case was school trips or events where an admin needed excuses for over a hundred students at once. With only individual selection, they had to search and add every student manually — what should have taken minutes became a frustrating chore.
• Action — Once I understood the real workflow, I took ownership and designed a richer student selection interface: filter by grade, class, or year group, preview the selected students, and bulk-select instead of searching one at a time.
• Action — I also spotted an unraised usability issue: selecting 120 students where one already had an excuse only showed a generic conflict message — it didn't say which student. Putting myself in the admin's shoes, they'd have to inspect every selected student manually.
• Action — Though not in the requirements, I redesigned it to highlight the specific conflicting students directly in the UI and let admins remove them with a single click before submitting.
• Result — Related support tickets dropped significantly, and support confirmed schools completed bulk excuse creation much more efficiently; resolving conflicts became far easier and the workflow more intuitive.
• What I Learned — Implementing the documented requirement isn't enough — validate whether the workflow matches how customers actually use the product. Since then I spend more time understanding real customer scenarios before locking in an implementation.