Failure

We often obsess over the operating manuals of the world's most successful companies, analyzing their wins to reverse-engineer their growth. However, the most potent lessons often reside in the wreckage of projects that didn't make it. Success can sometimes be attributed to timing or luck, but failure usually offers concrete, actionable data on what not to do.

In a special compilation, product leaders from companies like Airbnb, Google, Stripe, and Quibi opened up about their most significant professional missteps. From high-profile product disasters to internal leadership mutinies, these stories reveal that failure is not just an inevitable byproduct of innovation—it is often the necessary precondition for future success.

Key Takeaways

• Build trust before inflicting change: New leaders often fail by attempting to overhaul teams immediately. Without first earning trust and listening to existing context, even well-intentioned changes can lead to mutiny.
• Fail conclusively: In experimentation, particularly in B2B, half-measures are dangerous. Maximize the variable you are testing to ensure that if it fails, you know it was the idea that failed, not the execution.
• Do not build from fear: Products born from a reaction to competitors (like Google+ responding to Facebook) rather than user needs rarely succeed.
• Verify the unit economics early: No amount of product polish or iteration can save a business model where the fundamental math is broken, as seen with Quibi and Airbnb Plus.
• Avoid the "Rewrite" trap: Attempting a full code rewrite is one of the most common and costly mistakes in product engineering. It almost always takes longer than estimated and rarely delivers the promised value.

The Human Element: Leadership and Trust

One of the most immediate points of failure for leaders, particularly those joining new organizations, is the failure to read the room. Product leadership is rarely just about roadmaps; it is fundamentally about people management.

The Cost of Coming in Swinging

Katie Dill, Head of Design at Stripe, recounted a humbling experience from her early days at Airbnb. Hired to lead a design organization that had previously reported directly to a founder, she identified low engagement scores and operational inefficiencies. Eager to prove her value, she immediately implemented changes.

The result was a revolt. A month into her tenure, she faced an "intervention" where half her team read prepared statements detailing everything she was doing wrong. Her mistake was not necessarily in her strategic assessment, but in her execution.

You can inflict change on people, but if you want to do it with them, you really know trust is the key element there. Instead of coming in swinging, come in listening.

The lesson here is that positional authority does not equal influence. By shifting her approach from directing to listening, Dill eventually turned the team’s engagement scores into the highest in the company. The failure was a necessary pivot point to understand that leadership requires bringing people along, not just pointing the way.

Resilience in the Spotlight

Public failure can be just as paralyzing as internal friction. Paul Adams, CPO at Intercom, shared a nightmare scenario: freezing on stage in front of thousands at the Cannes Lions festival. While the moment was mortifying, the aftermath provided a vital perspective. The career did not end; the reputation was not permanently destroyed. This resilience is essential for product leaders who must constantly pitch high-stakes bets that might fail.

Strategic Failures: When the Foundation is Flawed

Execution cannot fix a broken strategy. Several leaders highlighted instances where the product was built beautifully, but the reason for its existence—or the math behind it—was fundamentally unsound.

The Math Problem of Quibi

Tom Conrad, former CPO of Quibi, offered a candid look at one of Silicon Valley’s most notable recent collapses. While Quibi is often mocked for its content or format, Conrad argues the failure was rooted in a disconnect between capital and unit economics.

Quibi attempted to build a massive library of premium, Hollywood-quality content for a mobile-first platform. The hypothesis was that a bespoke library could drive subscriptions. However, the cost to produce sufficient content to retain users was astronomical.

If the equation is fundamentally broken... no amount of iteration and execution can get you out of the failed outputs of the broken equation.

Conrad noted that while product teams often focus on delight and user experience, a company is ultimately a math problem. If the cost of acquisition and content production exceeds the lifetime value of the customer—and requires billions rather than millions to prove—the risk profile becomes untenable.

Building from Fear vs. User Needs

Similarly, Paul Adams discussed his time at Google working on Google+ and Google Buzz. In hindsight, these projects failed because they were motivated by "competitive fear" of Facebook rather than a genuine desire to solve a user problem. When a product strategy is reactive rather than proactive, it often misses the nuance of what users actually want. The team spent energy building features to match a competitor, missing the opportunity to build something unique that solved a distinct communication need.

The "Solution First" Trap

Jiaona Zhang (JZ) of Webflow shared the story of Airbnb Plus. The goal was to solve a trust problem: users wanted consistent quality. The solution the team fixated on was physical home inspections. This approach ignored the company's core competency—being a platform, not an operations-heavy managed marketplace.

By locking themselves into a specific solution (inspections) rather than iterating on the problem (trust), they built a product with upside-down unit economics. A better approach would have been leveraging what Airbnb already had: guest reviews, or perhaps cheaper signals of quality like verifying internet speeds or amenities, rather than deploying a global fleet of inspectors.

The Science of Failing Well

If failure is inevitable, the goal should be to extract maximum learning from it. Shri Batchu, former Head of Growth at Ramp, argues that the worst kind of failure is the inconclusive kind.

The Necessity of Conclusive Failure

In B2B environments, you often lack the massive sample sizes (the "N") that consumer companies like Facebook possess. This makes statistical significance harder to achieve. When running an experiment, if you only change one small variable (e.g., the subject line of an email) and it fails, you are left wondering if the strategy was wrong or if the copy was just weak.

Batchu suggests maximizing the "treatment effect." When testing a new hypothesis, throw every resource at it. Customize the email, change the design, alter the landing page, and increase the outreach.

If with all of that it didn't work, then you can say... we're not going to try this again because we literally did try everything that we could.

This allows a team to "fail conclusively" and move on, rather than getting stuck in a cycle of re-testing the same hypothesis because previous attempts were too timid.

The Hidden "B-Side" of Careers

Gina Gotthilf, formerly of Duolingo, introduced the metaphor of the "A-Side" and "B-Side" of a career. We tend to broadcast our A-Side: the successful launches, the acquisitions, and the scaling stories. The B-Side contains the layoffs, the visa struggles, the depression, and the failed campaigns.

Gotthilf shared a tactical failure at Duolingo regarding gamification. Her team debated adding badges for months but deprioritized it due to high engineering costs. Eventually, they ran a "lean" test: a simple pop-up badge upon sign-up. It had zero impact. The team concluded badges didn't work.

Months later, they realized the failure was in the experiment design—they hadn't "dogfooded" the feature to realize that a badge for merely signing up felt meaningless. Once they implemented a robust badge system, it became a massive driver of retention. The lesson: Efficiency shouldn't come at the cost of common sense. If you test a "minimum viable product" that is too minimal to be valuable, you will get a false negative.

Operational Pitfalls to Avoid

Beyond strategy and leadership, there are recurring tactical traps that product teams fall into. Maggie Crowley, VP of Product at Toast, highlighted the danger of the "Rewrite."

The Sunk Cost of Rewrites

Engineers and product managers are often tempted to rewrite legacy codebases to clear technical debt. The promise is always the same: "It will take six months, and then we'll move twice as fast."

Crowley shared a story where a six-month rewrite turned into a two-and-a-half-year slog that paralyzed the roadmap. The team skipped discovery, assumed they knew the requirements, and got bogged down in feature parity. The advice is stark: Don't do it. Refactor incrementally, but avoid the "side-by-side" rewrite at all costs.

Conclusion

The common thread across these stories is that failure is rarely fatal if it is treated as data. Whether it is Tom Conrad realizing the math doesn't work at Quibi, or Katie Dill realizing her leadership style needs adjustment, the failure provided the necessary signal to correct course.

For product leaders, the goal isn't to avoid failure—it is to fail conclusively, fail cheaply when possible, and ensure that every stumble contributes to a stronger intuition for the next big bet. As Paul Adams noted, companies that embrace a culture of "shipping to learn" eventually outpace those paralyzed by the fear of being wrong.