Discovery isn't dead: why AI makes it harder, not easier
I keep hearing the same claim from product leaders who should know better: "AI will automate discovery." They say it with this confident certainty, like they've already solved the hardest part of product work by plugging in a chatbot.
They haven't. And I think this belief is going to cost a lot of teams a lot of time.
The misconception
The argument goes something like this: AI can synthesize customer interviews faster, parse support tickets at scale, and generate user personas in minutes. So why do we need a whole discovery process? Just feed the data into the model and let it tell you what to build.
If you've done real discovery work, you already see the problem. Discovery isn't a data processing exercise. It's a thinking exercise. The hard part was never reading the transcripts. The hard part is knowing which questions to ask in the first place, recognizing when a customer is telling you what they think you want to hear, and sitting with ambiguity long enough to find the real problem underneath the stated one.
AI can't do any of that. Not yet, anyway, and probably not for a while.
There's a deeper issue too. Discovery requires what Teresa Torres calls "continuous" contact with the problem space. It's not something you do once and hand off. It's a posture, a habit of staying curious about your customers even when you think you already understand them. AI can give you a snapshot of what's in the data. It can't give you the ongoing relationship with the problem space that produces real insight.
What actually happens when teams skip discovery
I've watched this pattern repeat at three different companies over the past year. A team gets excited about AI tooling, uses it to generate a bunch of "insights" from customer data, builds a feature based on those insights, and then watches it underperform.
The failure mode is always the same. The AI found patterns in what customers said, not in what they actually need. There's a gap between those two things, and closing that gap requires the kind of judgment that comes from direct contact with users. Teresa Torres calls this continuous discovery for a reason. It's not a one-time extraction exercise. It's an ongoing relationship with the problem space.
One team I advised had used AI to analyze 2,000 support tickets and concluded that "navigation" was the top customer pain point. They redesigned their entire nav structure. Usage dropped. When they went back and actually talked to customers, they found that "navigation" was just the word people used when they couldn't find a specific feature that was buried three levels deep. The fix was a search bar, not a redesign.
Another team ran AI sentiment analysis across their NPS responses and concluded that pricing was the main source of dissatisfaction. They spent a quarter building a new pricing page with better plan comparison tools. The actual problem, which they would have caught in five customer conversations, was that customers didn't understand what they were paying for because the value wasn't visible in the product itself. No amount of pricing page polish was going to fix that.
The lesson in both cases is the same: AI is excellent at telling you what words people use. It's terrible at telling you what those words actually mean in context.
Where AI actually helps with discovery
I'm not saying throw away your AI tools. I'm saying stop treating them like they replace the thinking part of discovery. Here are the spots where AI genuinely makes discovery better.
Synthesis after conversations, not instead of them. Record your customer interviews, run them through a transcription and summary tool, and use AI to pull out themes across multiple conversations. That's useful. That saves real time. But you still need to have the conversations. I've found that the best use of AI here is generating a quick debrief document after each interview that captures key quotes, emotional moments, and surprises. It gives you something to reference when you're doing opportunity mapping later without having to re-watch an hour of video.
Pattern matching across large datasets. If you have thousands of support tickets or NPS responses, AI can surface clusters you'd miss manually. Use that as input to your discovery process, not as the output. The distinction matters: AI-surfaced clusters are hypotheses about what's going on. They're not validated insights. Treat them as starting points for further investigation, not as conclusions.
Generating hypotheses to test. AI is good at producing plausible ideas quickly. Treat those as starting points for experimentation, not as validated insights. I've had teams use AI to generate a list of twenty possible causes for a drop in activation, then use that list to structure their next round of customer interviews. That's a great use of the technology.
Summarizing competitive research. Scraping competitor changelogs, review sites, and forums is tedious. AI handles this well, and it frees you up for the harder work of deciding what the competitive data means for your product.
Preparing for customer conversations. Before an interview, have AI pull together what you know about that customer from support tickets, usage data, and past interactions. Walk in with context, not assumptions. The PM who shows up knowing that this customer submitted three tickets about export functionality in the last month is going to ask better questions than the PM who walks in cold.
Here's how I think about the discovery process and where AI fits in at each stage:
The Melissa Perri problem
Melissa Perri wrote about the "build trap" years ago, and her diagnosis still applies. Organizations that treat product management as a delivery function will keep building the wrong things, no matter how sophisticated their tools get. AI doesn't fix organizational dysfunction. It amplifies it.
If your company doesn't value discovery, AI just makes it easier to skip. You'll generate "insights" faster, ship features faster, and fail faster. Faster failure is only useful if you're actually learning from it, and most teams aren't set up for that.
The product operating model that Perri and Marty Cagan advocate for requires something AI can't provide: a genuine understanding of why discovery matters and the organizational patience to do it properly. That's a leadership problem, not a tooling problem.
I've seen this play out in a specific way that's worth naming. Companies that adopt AI tooling often simultaneously cut their user research budgets because leadership assumes the AI is "handling" that function. This is exactly backwards. AI tooling should increase your research investment because now you can process what you learn faster, which means each research session generates more value than it used to.
Warning signs your team is over-relying on AI for discovery
I've started watching for specific patterns that tell me a team has crossed the line from "using AI to augment discovery" to "using AI to replace discovery." Here are the red flags.
Your team talks about customers in the aggregate but can't name five. If every insight starts with "our data shows" and nobody can tell a specific customer story, you've lost the human connection that makes discovery work. AI-generated summaries feel authoritative, but they flatten individual experiences into averages.
Your opportunity backlog hasn't changed in months. If AI keeps surfacing the same themes and nobody is going deeper, you're stuck in a synthesis loop. Real discovery should constantly surprise you. If it doesn't, you're not asking hard enough questions.
You stopped doing follow-up interviews after surprising data. When AI surfaces something unexpected, the right response is "let's go talk to people about this." If the team's response is "the AI already analyzed it," you're in trouble.
Your personas read like marketing copy. AI-generated personas are polished, detailed, and completely generic. If your personas don't include contradictions, edge cases, and messy human behavior, they're not based on real people.
You can't explain why a feature failed. If a feature underperformed and the team's explanation is "the data said it would work," that's a sign the team isn't doing the kind of deep understanding work that would help them predict failure modes.
Nobody on the team has changed their mind about anything recently. Discovery should challenge your assumptions. If AI is confirming everything you already believe, it's probably because you're asking leading questions or filtering for confirming data. The best discovery makes you uncomfortable. If your team hasn't had a "wait, we were wrong about this" moment in the last quarter, you're not doing discovery -- you're doing validation theater with better tools.
Your interview questions come from AI-generated lists. There's a difference between using AI to help prepare for an interview and letting AI write your interview guide. AI-generated questions tend to be generic and surface-level because they're based on what people typically ask, not on what you specifically need to learn. The best interview questions come from the gaps in your understanding, and only you know what those gaps are.
What I'd actually recommend
If you're a PM trying to figure out where AI fits in your discovery practice, here's where I'd start.
Keep your weekly customer touchpoints. Don't reduce them because AI is "handling" customer insights. If anything, increase the frequency. The AI-generated summaries should make you more curious, not less.
Use AI to prepare for conversations, not to replace them. Before an interview, have AI pull together what you know about that customer from support tickets, usage data, and past interactions. Walk in with context, not assumptions.
Be skeptical of AI-generated personas and journey maps. They look polished. They read well. And they're built from statistical averages, which means they describe nobody in particular. Real personas come from real pattern recognition across real conversations.
Build a "discovery stack" where AI handles volume and humans handle judgment. Let machines process the data. Let people decide what the data means. The teams I've seen do this well have a clear separation: AI tools live in the "process" layer (transcription, clustering, summarization), and humans own the "interpretation" layer (framing problems, prioritizing opportunities, making bets). When those layers bleed together, you get AI making interpretive calls that nobody questions because the output looks authoritative.
Create a team habit of asking "what would change our mind?" before accepting any AI-generated insight. If you can't name a specific customer conversation or data point that would challenge the conclusion, you haven't done enough discovery.
Set a rule: no AI-generated insight gets acted on until it's been validated by at least two customer conversations. This sounds slow, but it's faster than building the wrong thing. And those conversations will either strengthen your confidence or reveal nuance the AI missed. Either way, you win.
The uncomfortable truth
The PMs who will thrive in an AI-heavy product world aren't the ones who learn to use AI tools fastest. They're the ones who get better at the things AI can't do: building relationships with customers, developing product intuition through repeated exposure to real problems, and making decisions with incomplete information.
Discovery isn't dead. It's more important than it's been in years. The teams that understand this will build products that actually matter. The teams that automate it away will build faster, ship more, and wonder why nobody cares.
This article is part of a series on product management in an AI-transformed landscape. The ideas draw on frameworks from Teresa Torres' continuous discovery habits, Melissa Perri's product operating model, and Marty Cagan's work on empowered product teams.