When your biggest launch of the year fails publicly, do you know what to do first? Two product leaders share what they got right—and what they wish they'd done differently.
Your biggest feature just shipped. Week one metrics come in: 8% adoption. Negative NPS. Support tickets everywhere. Your CEO wants answers. Your team is demoralized.
What do you do?
Most product leaders have a version of this story. Few talk about it openly. On Episode 2 of the Product Leaders Lab, Christine Itwaru (VP of Product at Userflow) and Matt LeMay (formerly a Senior Product Manager at Bitly) did exactly that — sharing the full, unfiltered story of how they each walked into a launch disaster and found their way out. Same crisis archetype. Completely different timelines, decisions, and outcomes.
What follows are the lessons that stuck.
Most product orgs have a launch playbook. Almost none have a failure playbook.
There's a reason for that. Nobody wants to plan for failure. It feels defeatist. So teams invest enormous energy in launch preparation — the roadmap, the go-to-market plan, the internal alignment — and almost nothing in what happens if week one looks nothing like what they projected.
And then it does.
When a launch fails publicly and fast, three things happen at once: customers need answers, leadership wants accountability, and your team is watching to see how you respond. The product leader is expected to manage all three simultaneously, often without a clear script for any of them.
Christine and Matt both found themselves in that exact position. How they navigated it reveals a lot about what actually separates leaders who recover well from those who don't.
Christine joined Userflow as VP of Product two months before the company's biggest launch ever. The stakes were high. The preparation felt solid. And then, within hours of shipping:
"Inbound into support was insane. There were just complaints coming in from obviously our customers and then your CS team and your support team were like, 'what do we do?'"
Two hours in, Christine made a call that defined how the recovery played out. Her PM — brilliant, energetic, and buried in Slack — was absorbing the full weight of the fallout. Christine stepped in, told her PM to step back from the noise, and took ownership herself.
"I'm gonna take this. Here's where I need you to just back off from Slack. So you just shut this world out."
She called it going into "mama bear mode." Her goal wasn't to fix the product first — it was to protect the mental health of her team before anything else. The PM. The engineers. The people who'd worked nights and weekends convinced they were doing the right thing. Christine had been in that seat before. She knew exactly what it felt like to think everything was fine and then have the floor drop out — and she wasn't going to let her team absorb that alone.
"My goal was to protect the mental health of sets of people. One was the product team and then the engineers. I really felt deeply because I was in her seat and I was in that space where like I thought everything was okay."
When a leader on the team asked if they could run a retrospective immediately, she shut it down: "Absolutely not. Let's go make sure our customers are okay. Then we worry about the retro."
Her post-mortem was unflinching. She later described what the launch revealed: "A complete crap show across the organization in terms of alignment, transparency, communication, and readiness." But she said it after the fire was out — not during it.
Matt's launch disaster at Bitly unfolded very differently — not in hours, but over months.
In 2012, Bitly was at the center of the social media startup boom in New York. Matt's team made a bet: pivot the consumer product toward social bookmarking. They renamed core features. They rebranded the experience. And they built it, essentially, for a version of their user they wished they had.
"I started to get into this space of like, I'm like a cool internetty person, and we're building for cool internetty people. Like, who's used us in the past? Social media marketers? Social media marketers aren't cool."
The launch landed to immediate backlash. Roger Ebert wrote publicly about how terrible it was. Patton Oswalt tweeted that they should just revert the changes. Someone in the comments of their blog threatened to burn down the office.
And yet — Matt couldn't name a single moment when he realized it had failed.
"I think it was just this ongoing lingering sense that something wasn't playing out as it was supposed to. Even when you literally have people threatening to burn down your office, it's still very easy to manufacture an environment where you can say, 'well, I don't know, there's still a lot to be done.'"
The problem, he reflected, wasn't stubbornness. It was structural. His team was cohesive, supportive, and deeply aligned — but they had never defined what success actually looked like. Their goal for the launch? TechCrunch coverage. Not adoption. Not retention. Not any metric that would have forced an honest conversation.
"In the absence of having those clear success and survival criteria, there was no way to acknowledge this had failed without implicitly attacking each other."
It took months before Matt proposed the right move: give most of his team to the enterprise side and rebuild with one developer, one designer. A pivot that was both correct and painful.
"I was on the one hand making this very mature and I think correct choice. And on the other hand, like fighting it and being resentful and being like, 'it's not fair.'"
These two recoveries aren't in conflict. They're optimized for different kinds of failure.
Christine's approach — move fast, protect the team, own it publicly — works when:
Matt's approach — slow diagnosis, honest pivot — is what you're left with when:
The trap most product leaders fall into is treating a launch failure like a support ticket — acknowledge it, patch it, close it. Neither Christine nor Matt did that. They both recognized that a launch failure is a signal, not just a symptom. It reveals something true about your organization that didn't show up on the roadmap.
Christine's launch revealed an alignment and readiness gap across the org. Matt's revealed something harder: that the team had optimized for internal cohesion over external feedback. Both were real problems. Both required different recovery paths.
What they shared was a refusal to point fingers while the fire was still burning. Christine was explicit:
"Can we not point fingers at this moment?" Matt, looking back, wished he'd been more honest with himself sooner — but once he got there, his ownership was complete: "I should have gotten in more trouble than I did, to be honest."
There's a structural reason Matt's team couldn't acknowledge failure without it feeling like an attack: they had never defined what failure looked like.
"TechCrunch coverage" is not a success metric. Neither is "strong exec alignment" or "positive team energy." Without specific, pre-defined criteria — activation rates, week-two retention, support volume thresholds — there's no neutral ground to stand on when something goes wrong. Every conversation about failure becomes a conversation about blame.
The most practical takeaway from both stories is also the least glamorous one: set your success and survival criteria before you launch. Not after you see the numbers. Before. Define the signal that would trigger a pivot, a rollback, or a full stop. Make it explicit and make it shared.
Without that, you're navigating a failed launch without a compass — and the most capable, cohesive teams are often the most vulnerable, because their trust in each other makes it harder to say the hard thing out loud.
Both Christine and Matt are still in the industry. The Bitly consumer product, despite the chaos, was still generating revenue eight years after the relaunch. Userflow shipped a recovery plan and moved forward.
Christine's parting thought from the episode is worth sitting with: "Everything is temporary. Take a beat and breathe. It's not brain surgery we're doing."
That's not a dismissal of the stakes — it's a reminder that the goal isn't to never fail. It's to build the kind of leadership reflexes that let you respond well when you do. Your users' first experience with your product is shaped not just by what you ship, but by how quickly and honestly you recover when something breaks.
That capacity — to fix fast, protect your team, and examine with clarity — is what turns a catastrophic launch into a leadership case study worth sharing.
Want to hear the full conversation? Listen to Episode 2 of the Product Leaders Lab wherever you get your podcasts:
