User inputs: Role: Senior Product Manager at Stripe Experience: "Last year I launched a new self-serve onboarding flow for SMB customers. I was sure it would lift activation by 15%. I deprioritized a concern from our data scientist about a cohort-tracking bug because I wanted to ship before Q3. After launch, activation actually dropped 12%. Took me 2 weeks to find out the bug masked the real metrics. I rolled it back, redesigned with the data team, relaunched 6 weeks later — got +9%. Question type: Failure." Answer length: Standard 🎯 Likely Question Phrasing Most probable version (for Stripe): "Tell me about a time you shipped something that didn't work. What did you learn?"Variant 2: "Walk me through a project that failed. What would you do differently?" Variant 3: "Describe a decision you made that turned out to be wrong. How did you handle it?"🔍 Experience Audit ✅ Strong: Clear ownership, concrete numbers (-12% then +9%), specific recovery action. ⚠️ Missing: What you learned about your own decision-making — Stripe interviewers want the meta-lesson, not just the fix. ✂️ Cut: "I was sure it would lift activation by 15%" — comes across as ego, weakens the opener. 💎 Hidden gold: You ignored a data scientist's warning. Naming that mistake explicitly is the strongest signal you can send — Stripe rewards intellectual honesty. 🎬 Core Answer"Last year I shipped a self-serve onboarding flow I was convinced would lift SMB activation by 15%. It dropped it by 12%. The hard part wasn't the metric — it was admitting why it happened. Three weeks before launch, our data scientist, Maya, flagged a cohort-tracking bug. I deprioritized her concern because we'd committed to a Q3 ship date. The bug ended up masking the real activation signal, and I shipped on bad data. When I saw the rollback dashboard, I called Maya first — not my manager — and said: 'You were right, and I should have listened.' We rebuilt the instrumentation together, relaunched six weeks later, and got +9%. The real lesson wasn't about data hygiene. It was that I'd learned to discount engineering concerns when they slowed me down. Now I have a rule: if my IC raises a concern twice, I stop and run it down — even if it costs the ship date."Word count: 178 Spoken duration: ~75 seconds🔄 Follow-up AnswersFollow-up A: "Walk me through the moment you decided to roll it back. What was the call?""Day 14 post-launch, activation was still down 12%. I had two options: keep iterating live or roll back and rebuild. I chose rollback for one reason — I no longer trusted my instrumentation, so I couldn't trust any improvement I'd see. I'd rather lose six weeks than make another decision on bad data. I told my manager that morning, then told the team in standup. Hardest part was the 'I was wrong' Slack message to the leadership channel. But shipping again on bad data would have been worse."Follow-up B: "What if Maya hadn't flagged the bug — would you have shipped anyway?""Probably yes, and that's the scarier answer. The bug would have shown up eventually, but maybe two months in, when we'd built three features on top of it. That's actually what changed how I run reviews now. I don't just ask 'are there concerns' — I ask each engineer directly, by name, what they'd want to push back on if they had unlimited political capital. It surfaces things people self-censor in group settings. Maya pushed back even though I'd implicitly told her not to. I shouldn't need that level of bravery from my team."🎤 Delivery Tips Pause for emphasis: After "It dropped it by 12%" — let the number land. Failure stories work when the candidate doesn't rush past the bad result. Money line (memorize verbatim): "I'd learned to discount engineering concerns when they slowed me down." Trap to avoid: Don't make the story about the bug. Stripe interviewers will read it as deflection. Keep the story about your decision to override Maya — that's the lesson they're scoring.