AI has changed the economics of building. Not in the way most commentary suggests, not as a replacement for thinking, but as a collapse in the cost of making things real. And that shift lands squarely on how product discovery works, what it's for, and how much of it is still justified.
This matters to anyone leading product design or product management in organisations that build digital products. Whether you're in a startup moving fast or an enterprise that's only just getting comfortable with the idea of discovery at all.
The original bargain
For as long as most of us have been doing this, discovery has existed to protect delivery. That was the deal. Delivery was slow, expensive, and politically fraught. Getting it wrong meant months of wasted effort, strained relationships, and difficult conversations about sunk costs. Discovery's job was to reduce the odds of that happening.
So we built a practice around stand-ins. Wireframes alongside working products. Prototypes to test assumptions before committing to full builds. Workshops to align teams before burning through delivery capacity. These weren't shortcuts; they were practical responses to the reality that building was hard, slow, and costly. But they were only ever part of the picture. The other half was just as important: landing products in the market, scaling them, and measuring product-market fit with real usage at real volume. Discovery didn't replace that work. It existed to make sure you arrived there with better odds.
That logic made sense. For decades, it was good practice.
But the protective half, the stand-ins, the proxies, the speculative validation was always a concession, not a virtue.
What AI actually changes
Designing and shipping a functional product is no longer a six-month commitment. In some cases, it's days. In others, hours. The distance between an idea and something real has collapsed in ways that would have seemed absurd five years ago.
That doesn't make discovery irrelevant. But it weakens one of its central justifications.
If you can build working software and put it in front of users quickly, the value of speculative validation, of debating whether something might work based on an abstraction of the thing, drops significantly. Not to zero. But enough that it should no longer be the unquestioned default.
Observing real behaviour beats debating stated intent. A small-scale release with actual users beats an hour of abstract critique in a meeting room. We've always known this. What's changed is that the first option is now genuinely available earlier and more often.
Something else disappeared with the cost of building.
Here's something I don't think gets talked about enough. When building was expensive, the act of building itself imposed a kind of discipline on teams and organisations.
You couldn't build everything, so you had to choose. You couldn't target every segment, so you had to prioritise. You couldn't ship a feature for every possible use case, so you had to make hard decisions about what mattered most. The constraint was frustrating, but it was also useful. It forced focus.
That forcing function is weakening.
When build cost drops dramatically, it becomes tempting to keep every option open. To target multiple segments simultaneously. To ship features for problems you haven't properly validated, because why not? It's cheap to try. The result is products and teams that look more mature than they actually are. The surface runs ahead of the substance underneath — the customer understanding, the commercial model, the domain expertise, the actual evidence that any of this solves a real problem.
A polished product used to be a reasonable signal that real work had happened. It implied months of iteration, customer feedback baked in, hard choices made. That signal is becoming less reliable. You can now produce something that looks like the output of a well-resourced, mature team without having done any of the learning that mature teams do.
This isn't a criticism of using AI to build faster. These tools are genuinely powerful, and you'd be foolish not to use them. But it means that for product leaders, the question shifts. It's less about what a team has built and more about what they've actually learned. Who have they spoken to? What did they discover that surprised them? What happens when their assumptions are wrong?
The discipline that expensive development used to impose for free now has to come from somewhere else. It has to come from leadership.
The distinction that matters
Here's where I think the conversation needs to be precise.
Problem discovery hasn't changed. AI doesn't create demand. It doesn't generate strategic context. It doesn't make a weak problem worth solving. The work of understanding what matters to users, what's changing in a market, and where a product should focus, remains deeply human and deeply necessary. If anything, the ease of building makes problem discovery more important, because teams can now ship solutions to problems that don't matter at remarkable speed.
What has changed is solution validation.
When the cost of building falls, the penalty for being wrong shifts with it. Learning from real artefacts becomes viable earlier. Iteration speeds up. And here's the part that catches people off guard: throwing work away becomes normal rather than painful.
There's a second-order effect here that's worth naming. When AI produces much of the implementation, teams tend to have less emotional attachment to the output. The sunk cost problem, the one that makes people defend past decisions well beyond the point of reason, weakens. Fewer people feel the need to protect something they didn't spend three months handcrafting.
That's healthy. It's a better way to learn.
Where many teams are today
I should be honest about the landscape. Many enterprise organisations haven't fully embraced discovery in the first place, let alone discovery running in parallel with delivery. The idea that you'd invest continuously in understanding problems while simultaneously building solutions still feels radical in some boardrooms.
For those organisations, this shift creates an odd situation. They're being told that the practice they never quite adopted is already evolving. That can feel disorienting. But it also creates an opening, because the version of discovery that's emerging is, in some ways, more legible to delivery-focused leaders. Learning from real things rather than abstractions is easier to explain and easier to fund.
For teams that have mature discovery practices, the challenge is different. It's about recognising which parts of the current approach exist because they genuinely serve learning, and which parts exist because building used to be expensive.
The line that cannot be crossed
None of this is permission to ship carelessly.
Brand trust is still expensive to earn and easy to damage. Users don't care how quickly you built something. They care whether it works, how it feels, and whether it respects their time and provides genuine value. Those standards haven't moved.
Shipping broken experiences and calling them "alpha" is not experimentation. It's erosion. But there's an equally damaging version of this that's harder to spot: shipping polished experiences that were never validated at all. Products that look complete and professional but were built on assumptions rather than evidence. The surface is impressive. The understanding underneath is hollow.
Both failure modes come from the same root cause. Build cost collapsed, but the discipline that used to come bundled with slow, expensive building didn't transfer automatically to the new world. Speed arrived. Judgment didn't always come with it.
This is where I expect many teams to struggle in the next few years. The risk isn't shipping early; early can be fine if it's done thoughtfully. The risk is confusing speed with permission to lower standards, or confusing output with learning.
There are practical constraints here, too. Some users simply won't engage with rough products; they'll form a judgment and leave, and you'll never get the data you were hoping for. Some teams will struggle to kill things that technically function but are directionally wrong. Some leaders will mistake shipping activity for progress.
These aren't theoretical risks. They're the ones I've seen play out repeatedly, long before AI entered the picture. Speed just amplifies them.
The opposite risk
But there is an equal and opposite risk that deserves equal attention.
Many teams are still optimising for a world where building is slow and politically dangerous. They're over-investing in speculative validation. They're perfecting wireframes and prototypes and research decks that exist only to represent something that could already be real.
In some situations today, and this is genuinely new, the stand-in takes longer to produce than the real thing.
When a detailed prototype takes a few days but a working version takes less time to build and deploy, the prototype no longer reduces risk. It's adding cost and delay for the comfort of a process that made sense under different economics.
That world is fading. Not gone, there are still plenty of situations where building remains expensive, where the consequences of getting it wrong are severe, and where careful upfront validation is the right call. But the blanket assumption that discovery-before-delivery is always the responsible approach? That assumption needs revisiting.
What this asks of leaders
The question isn't whether discovery still matters. It does.
The question is how discovery evolves when building is no longer the bottleneck, and how senior product and design leaders protect brand trust while learning faster from real use.
The bottleneck is shifting from building to judgment. And that changes what good leadership looks like in product organisations.
You need to know when speculative validation still earns its keep and when it's become organisational theatre. You need to understand which users will tolerate rough edges and which won't. You need teams who can ship quickly and maintain quality standards, because those two things feel contradictory until you've built the muscle for both.
And you need to be asking better questions, of your teams and of yourself. Not "what have we built?" but "what have we learned?" Not "how fast did we ship?" but "what do we now understand that we didn't before?" Not "does it work?" but "does it matter?"
I don't have a neat framework for this yet. I'm not sure anyone does, and I'd be suspicious of anyone claiming otherwise this early in the shift.
But the direction feels clear. Learning from real things earlier is becoming not just possible but sensible. Doing so without damaging trust is the new bar for good product leadership. And the teams that figure out where that line sits, not in theory, but in practice, for their users and their context, will be the ones that move meaningfully faster without paying for it later.
That's the work ahead.