You can ship faster than ever. That doesn't mean you're building the right thing. Two product leaders, two crises, and one expert voice who names exactly why most teams get it wrong.
Your team is shipping faster than ever. The roadmap is full. Leadership is happy.
And users are leaving.
This is the speed trap. AI gives product teams the ability to build in days what used to take weeks. But moving faster doesn't help if you don't know what to build. In Episode 10 of the Product Leaders Lab, I brought together two product leaders who lived through exactly this and came out the other side with hard-won lessons. Plus an expert voice who's seen the pattern play out across hundreds of teams.
Stephanie Leue is an Executive Coach for Product Leaders. She joined a company two days before a massive product launch. The launch broke, went down for 48 hours, and when it came back up, users discovered that a feature they loved had been quietly deprecated. Nobody told them.
Adam Thomas is Head of Product at Flax and Teal. He walked into a bootstrapped company that had just cut its staff in half. No outside money. No clear ICP. And a product strategy that had quietly stopped working without anyone saying so out loud.
Mateja Milosavljevic is the CEO and co-founder of Lyssna, a user research platform. He's seen this pattern across hundreds of product teams and joins us as the expert voice for this Season 1 finale to help make sense of what both stories are really telling us.
Every product team that ends up in a crisis like this had the same belief: we know our users well enough.
They had data. They had some research. They were moving fast. The problem is what Mateja identifies as the trap inside that confidence:
"I think what happens is that usually teams get themselves into trouble either because they haven't done any research at all, which is an obvious problem. But I think the less obvious problem is doing just enough research to feel confident. But then not enough research to be correct."
Doing just enough research to feel confident. But not enough to be correct.
And underneath that is a structural problem most teams never name out loud.
"Research is generally considered, I think most people would agree that it's important, right? But it's often not considered urgent. So, you know, important and urgent things are the things that get done, but the ones that are important and not urgent are scheduled for later. And for a lot of teams, later never comes."
When a crisis hits, there's no time for scheduled-for-later. You find out what you don't know all at once.
Stephanie's situation didn't give her much choice.
It was day three of her new job. The product went live, then immediately went down for 48 hours. Hundreds of millions of users couldn't access it. And when the product came back up, the second wave hit:
"Once the product was back, the users figured out that the company deprecated features that they loved and no one told them. So the users found out why they were using the product. So the next chit storm was just around the corner. And that was just my first week."
The team was wrecked. The people who had spent 12 to 18 months building this release, excited for launch day, were now watching their work become the source of user rage. Stephanie describes it as the toughest moment of her entire leadership career:
"The people who cared so deeply about all the things in the past 12, 18 months, who were just moving towards building and releasing that product and who were like so excited. Seeing them in this situation has been for me personally the toughest situation in my entire leadership career."
Her first move was counterintuitive. She didn't try to fix anything. She listened.
"I just had the ability to lean back and listen. Like literally listen to everyone, like trying to understand what happened, what's your perspective, how do we get out of here? So I used my onboarding period to really listen to all the people trying to understand like, what was the product before? Why did things happen? What would you have done differently? What does that mean for the future?"
That wasn't just a product instinct. Stephanie has a coaching certificate, and she used it. Her onboarding became an ongoing retrospective. For the team, and for the product.
Then came the discovery. The customer support volume had spiked 10x. Thousands of users reaching out, angry, specific, and for once, fully available for conversation.
"Discovery was suddenly super easy because all these people really wanted to talk to us and complain. So I think me and my team, we had months of therapy sessions with customers who told us about how much they hate the product now and what they are missing and why and how they were using it and why it's missing and how we disrupted their workflows."
What those conversations revealed changed the entire strategic question. The deprecated feature wasn't just a popular feature. It was the entry point into the product experience.
"We deprecated a product, unfortunately, accidentally, right? The team just felt like this product is not contributing to our growth. So let's just skip it. Unfortunately, that was the one product that most of the users really used as entry point into our experience. You also have to understand what are they missing? Is it the feature or is it a part of their workflow or is it a problem that this feature solved?"
That reframe led to a decision nobody liked in the short term. Stephanie chose not to rebuild what was lost. She chose to rethink the entire product suite.
"Finally, we came up with the decision that we're not going to rebuild the product, but we're going to rethink the entire product suite itself. And instead of building the feature that we deprecated, we've built a new product line that not only solved the pain of the users and the thing they were missing, but we doubled down on delivering more value."
Both options (rebuild or rethink) would take six months. Same timeline, completely different destinations. She held that line even when it was uncomfortable:
"I'd say that's one of the key elements of good leadership to have a conviction and follow through. And you always have to help a company to move towards a better future. And you don't know whether that future is a big bet and if it's successful or not. Like you don't know, right? So you have to somewhat try to de-risk your decisions. But at the same time, you also have to strongly believe that once you've made a decision, you have to follow through."
The product shipped 12 months later. Users loved it. And it was still running after Stephanie left.
Her regret: she was too gentle with the team during the transition. She walked on eggshells when the situation called for clarity. Teams in grief need honesty, not softness.
Adam's situation had less noise and more uncertainty. He walked into a bootstrapped company four weeks before being promoted to Director of Product. The company had just cut staff in half. The team was scared:
"It was bad. And some of the ways that it showed up was people were scared to say what they thought. And, you know, they were nervous like they were going to be next. So whenever the founders would walk into a room, everybody would just zip up."
The founders weren't hearing honest feedback. The team wasn't giving it. And nobody had named the core problem yet.
"One of the things that became blatantly clear is the business itself wasn't really focused on the ICP, the ideal customer profile. The business was trying to do too much for everyone. And as you and I'm sure the listeners well know, like if you try to do everything for everyone, you end up doing nothing for no one."
Adam's approach was to do what most PMs never do: go talk to the people who had already left.
"There was no extra money, right, to go find. You had to keep what you killed. And so we were on the clock. Could we fix the business after these layoffs and get a product strategy that worked?"
He cold-emailed churned customers himself. No process, no team, no tool. Just him using his outsider status as cover to ask honest questions. What he found was a pricing signal the team had never surfaced.
The product was priced to appeal to beginners. But the customers they actually wanted (professional sellers, established businesses) saw a $20/month product and walked away.
"The story that they told was an enterprise button that said, you're going to talk to a salesperson and we're going to take you in from there. Ours was free trial, you know, $20 a month. And so certain people, especially if you're a couple of million dollar business and you have employees, there's one that shows a level of professionalism that you would, I think you trust more versus something that says here's 20 bucks, you can try us."
Mateja points out why this insight was so hard to find without going to churned customers specifically:
"A challenge within research is that some groups of users are actually just naturally harder to hear from than others. Active users are mostly helping you improve the current experience, but the people outside the product on the peripheries are the ones that are able to tell you how the market actually perceives what you're doing, what you're offering is. And I think Adam's pricing insight is a really good example of that."
Adam used that data to build a cost story first. He partnered with engineering to measure more effectively and pair off non-ICP users who were consuming resources. The company cut costs by 35%. That built the trust he needed to make a bigger move.
"We were able to raise the price. I was able to double the price and lower net churn as a result. I heard from a customer, a different customer, but same kind of profile, and they were like, well, I'm staying with you now because I used to think you were too cheap. And I thought you guys were a scam. But at this price point, I got in, the onboarding flow feels like it's for me."
Doubled the price. Lowered churn. Because he talked to the people nobody else was talking to.
His regret: he did most of it alone. The research was real. The insight was right. But one person doing churn interviews is a sprint, not a muscle.
"There were a lot of times where I took a lot on my shoulders and I spent a lot of late nights trying to do all this on my own. And it took me a while to learn. I burnt myself out. Trying to do this all by myself. Trying to train the product managers that were there and the designers. Instead of really bringing them in and getting them on board. It would have taken a little bit longer, but I think we would have had a much stronger team as a result."
Stephanie heard the truth through chaos. Adam went looking for it. Different triggers, same destination: both of them discovered that their teams had been building without really knowing who they were building for, or why.
That's not a process failure. It's an exposure failure. The team wasn't spending enough time with the people outside the product.
Mateja's synthesis is worth sitting with:
"I think really good product decisions come from combining a few different perspectives. So you want to know who the users are, what they're saying, what they're doing. You want to look at what's coming up in support, what's coming up during sales conversations. Why are they leaving? Having a full picture."
Not one signal. Not your loudest users. Not your most active users. All of it together.
The trap Stephanie fell into was that crisis-driven discovery gives you a skewed sample. The users who scream loudest are not always the ones who matter most. The trap Adam fell into was that solo discovery doesn't scale. He had the right instinct. He needed a team behind it.
Most teams treat research like a project. Something to schedule, complete, and move on from.
The teams that don't end up in these situations treat it differently.
"Strong product teams make customer exposure just the normal recurring part of the process. So every project needs to have some amount of discovery and some amount of validation. Just baked in. If you're on a tight budget or a tight deadline, it's not a negotiable. You have to do some amount of research. And so the question is not are we going to do it, but how?"
Not are we going to do it. But how.
That shift is the whole thing. When research is baked in, you don't need a crisis to tell you what users actually think. You already know. You've been listening.
And in an era when AI lets you ship 10x faster, that question becomes more urgent, not less. Mateja puts it plainly:
"There is an emergent trend of rapid experimentation. And on one hand, I think that's a good thing. I think being able to rapidly iterate on different ideas with the assistance of AI, I think that's great. But I don't think that should replace actually doing upfront discovery and the care and attention in understanding the context that the user is operating in. Because I think there's a risk of basically turning users into guinea pigs where you're like, what about this and what about that? And I think people will eventually fatigue from that."
The bottleneck isn't engineering anymore. It's knowing what to build.
What Stephanie and Adam both found, through completely different paths, is that the hardest product leadership moments usually have the same root: the team stopped being close enough to the people they were building for.
Speed can hide that gap for a long time. Until it can't.
The product leaders who don't fall into the speed trap aren't the ones with better research processes. They're the ones who've made user exposure so normal that it doesn't feel like a process at all. It just feels like how they work.
That's what building for the right people actually looks like.
Want to hear the full conversation? Listen to Episode 10 of the Product Leaders Lab wherever you get your podcasts:
