Building got 10x cheaper. Building the right thing didn't.

Ever since the AI boom started I have been opening product workshops with the same claim: discovery is now more important than it has ever been.

It lands badly about a third of the time, and I understand why. When building is nearly free, spending three weeks deciding what to build feels like a tax. Just ship it and find out. The feedback loop is the research.

The problem is that only one of the two costs actually fell.

The cost that collapsed, and the one that did not

Producing a feature got dramatically cheaper. Fine. Now price being wrong.

Being wrong still costs you the quarter you spent, the customers who tried the thing and quietly left, the support surface you now own forever, the maintenance burden on every future change, and the roadmap slot you gave away. None of those got cheaper. Several got more expensive, because you are now producing more of them per quarter.

Keep the benchmark in view: roughly 80% of features are rarely or never used. That ratio was never a function of how fast anyone could type. It is a function of how well the team understood the problem before they picked a solution.

The failure data has not moved either

For years I have opened workshops with the CB Insights work on why startups die, because it is the least flattering data in product and it stays stubbornly consistent.

The current edition, published in March 2026, looks at 431 VC-backed companies that shut down since 2023. Running out of capital tops the list at 70%, which CB Insights itself flags as the final cause of death rather than the root problem. The root problem sits right underneath it: poor product-market fit, cited in 43% of the shutdowns. Two-thirds of those were early-stage companies that never found a market at all.

Read that again with the AI argument in mind. In a period when building has never been faster or cheaper, the thing killing companies is still that nobody wanted what they made.

Cheap building makes this worse, not better

Here is the part that gets missed. When building was expensive, cost acted as a filter. A weak idea had to survive an estimate, a prioritisation argument, and a quarter of somebody's salary. It was a bad filter, arbitrary and often political, but it stopped some things.

Remove the cost and you remove the filter. Now everything ships.

And people will tell you these decisions are reversible, so it does not matter. Mostly they are not. Every shipped thing leaves a permanent residue: a surface you support, users who now depend on it, a data model you have to live with, a decision that constrains the next one. That is the argument in not all features add value, but every feature adds cost, and cheap generation makes it more true rather than less.

The fundamentals did not change

They are unglamorous and they still work:

• Talk to users before you build.
• Treat every idea as a hypothesis, and test it.
• Drive outcomes, not outputs.

The numbers behind that are worth keeping on hand when someone calls discovery a luxury. Teams doing real discovery cut their risk of failure by around 75%, save roughly 2x in development costs by removing avoidable rework, and land at an 83% product success rate against something close to a coin flip without it. Those figures come from Pendo, the Nielsen Norman Group, and MIT, and they were all measured before generation got cheap.

If none of that is running in your team yet, the starting point has not changed either: discover what to build before you code it.

Three questions before anyone opens an editor

This does not have to be a three-week phase. In practice I ask a team three things, and the conversation takes an hour.

Who specifically has this problem, and where would I find twenty of them this week? If the answer is a description of a persona rather than a place, you do not have a segment yet. You have an idea about one.

What is the workaround they use today? Real problems leave scar tissue: a spreadsheet, a WhatsApp group, a manual step somebody does every Friday, an intern. If nobody has bothered to work around it, the pain is theoretical, and theoretical pain does not convert.

What number should move, and by how much, for this to have been worth it? Say it before you build, not after. Written down in advance, this is the only thing standing between "we shipped it" and "it worked." Stated afterwards, it is just a story that fits whatever happened.

An hour on those three questions kills more bad features than any prioritisation framework I have used, and it costs less than the meeting where you would have argued about story points.

The good news nobody uses

Cheap building did change something real. It made discovery cheaper too, and almost nobody is spending the windfall there.

A prototype that used to take a designer a week takes an afternoon. A landing page that used to need a sprint takes an hour. Which means the tests that teams always claimed they had no time for are now genuinely trivial to run. A fake door test costs you a morning and tells you whether anyone wants the thing before you own it forever.

The correct use of a 10x drop in build cost is 10x more tests, not 10x more shipped features. Almost every team I meet picked the second one.

So: the bar for building dropped to the floor. The bar for building the right thing stayed exactly where it always was. Discovery is not the phase you skip because you move fast. It is the reason moving fast pays off at all, and it is the whole point of a product discovery workshop.