Learning from Failure: Stories from Product's Biggest Missteps
Compilation
Katie Dill, Paul Adams, Tom Conrad, Sri Batchu
MULTI-PART
Trust First
Katie Dill's Leadership Lesson: Trust Over Force
"I hadn't earned their trust. So whether how right or how wrong what I was doing was is the key piece — I wasn't bringing the team along with me."
Came in "swinging" with ambitious plans to change the design org at Airbnb
Got called into a meeting where half the team read prepared feedback on her failures
The real issue: she was executing change without building trust first
Shifted approach: listen, understand what people care about, bring them along
Notable Disasters
Product Failure Patterns from Pets.com & Quibi
Pets.com: Great product execution, broken business math — couldn't acquire customers profitably at scale
Quibi: Made a bet that bespoke short-form content could drive subscription retention at scale — the equation was wrong, not the execution
Google+: Born from competitive fear, not from solving real user needs
Google Buzz: Privacy disaster that showed what happens when fear-driven products ship at scale
Tom Conrad on Quibi's Math"If the equation is fundamentally broken or a big swing in and of itself, no amount of iteration and execution can get you out of the failed outputs of the broken equation."
Paul Adams on Google's CultureMany failures came from a place of fear rather than solving user problems. Fear-driven product decisions lead to broken outcomes.
Build Culture
Ship Fast, Learn Faster, Embrace Failure
Design the culture you want: Intercom built a "ship to learn" philosophy that celebrates failure as long as you're learning
The craft-speed tension: High standards vs. fast iteration is a real trade-off; both matter
Big bets require big learning: If you make bold bets, you'll fail more often than not — design your culture to accept that
Fail conclusively: Design tests that can fail cleanly, not ambiguously
Paul Adams at Intercom
"We've high standards ourselves. We never want to be embarrassed by what we ship. So there's a real tension there between high standards and shipping fast."
The Steve Jobs analogy
Simple interfaces, infinite use cases, one quality bar — shipping fast doesn't mean low quality; it means focusing ruthlessly on what matters.
Experimentation
Fail Conclusively: Sri's Framework
Most experiments fail (~70% failure rate is normal)
Failure ≠ not learning. Failure = not knowing why it didn't work
Design tests to fail conclusively, not ambiguously
Maximize treatment effect: throw all possible tactics at the hypothesis, then optimize if it works
If it fails even with maximum effort, it's a real "no"
The ABM ExampleAccount-based marketing gets tried repeatedly without conclusive tests. Each new exec tries it halfway, it fails ambiguously, next exec tries again years later.
Contrarian
What Great Product Leaders Actually Believe About Failure
✗Good leaders minimize failureINSTEAD →✓ Good leaders design their team and culture to fail well. Make big bets, fail fast, learn hard.
✗Failure is the opposite of successINSTEAD →✓ Failure is part of the path to success. If you're not failing, you're not experimenting hard enough.
✗Perfect execution saves bad strategiesINSTEAD →✓ Even flawless execution can't save a broken business equation. Fix the strategy first.
✗Failing ambiguously teaches you somethingINSTEAD →✓ Ambiguous failure is a waste of time. Design experiments so they fail conclusively — then you own the answer.