42% of startups build something nobody wants. AI is making it worse.

For years I've opened every product workshop with the same slide. It's not a framework or a flashy case study. It's a list — the CB Insights report on why startups fail, ranked.

And every single year, the number one answer is the same.

Not "ran out of money." Not "got outcompeted." Not "wrong team." Those are further down the list. The thing that kills the most startups is the most avoidable one: they spent months — sometimes years — building a product the market shrugged at.

Here's the part that should worry you. That number isn't going down. If anything, the tools we got excited about in the last few years are quietly pushing it up.

AI didn't fix this. It made it more tempting.

Building is 10x faster now. You can go from idea to a working app in a weekend with a handful of prompts. That's genuinely amazing. It's also a trap.

Because shipping more apps hasn't led to more traction. The Financial Times put hard data behind what a lot of us were already seeing on the ground: while releases exploded, app downloads stayed flat. And retention? Don't get me started on retention.

Think about what that means. We collectively got much, much better at making things. We got no better at making things people actually keep using. The bottleneck was never the building. It was knowing what to build.

When building is cheap, skipping discovery and just shipping feels logical. Why spend three weeks interviewing users when you could just build the thing and find out? So that's what more and more teams do. They build first and ask questions later.

The bar for building dropped to the floor. The bar for building the right thing stayed exactly where it always was. AI moved one of those bars and not the other — and most founders are celebrating the wrong one.

The fundamentals that didn't change

Here's the uncomfortable truth for the "just ship it" crowd: the things that separate the 58% from the 42% are the same things they were a decade ago. AI didn't repeal them. It just made them easier to ignore.

• Talk to users before you build. Five to eight conversations with the right people will tell you more about whether your idea has legs than a month of building in the dark.
• Every idea is a hypothesis — test it. Your conviction isn't evidence. The fact that you'd use it isn't evidence. A real signal from real users is.
• Drive outcomes, not outputs. Twelve features shipped is an output. Users who'd be genuinely upset to lose your product is an outcome. Only one of those keeps you alive.

None of that is new. That's the point. The founders who win in the AI era aren't the ones who ship the most. They're the ones who still do the unglamorous work of figuring out what's worth shipping — and now have cheaper tools to act on it once they know.

The traction mirage

Speed creates a dangerous illusion: motion that looks like progress. You're shipping every week. The changelog is full. The team feels productive. It feels like you're winning.

So what? Ask the question. So what if you shipped twelve features this quarter? So what if downloads ticked up after launch?

If those users don't come back — if the retention curve slopes straight to zero — none of it counted. Downloads are a vanity metric. A flat retention curve under a busy release schedule isn't traction. It's a startup burning runway efficiently. You're just failing faster and with better tooling.

The only thing that tells you whether any of the building mattered is demand: do people actually want this enough to stick around and miss it when it's gone? That's not something you feel. It's something you measure.

How to find out if you're in the 42% — before the runway's gone

The cruelest version of "no market need" is the slow one. You don't find out in week two. You find out a year in, after you've hired, after you've raised a little, after you've told everyone this is the one. By then the lesson costs you the company.

It doesn't have to go that way. You can get an early, quantified read on demand long before the runway runs out. The cleanest tool for it is the one Sean Ellis built: ask your engaged users how they'd feel if they could no longer use your product. The percentage who say "very disappointed" is your product-market fit score — a direct measurement of real market need.

Run it on the users who've actually experienced your product, and you get an honest answer in weeks: are people forming a real attachment, or are you politely shipping into the void? A 19% score today is painful — but it's a painful truth you can act on, not an expensive surprise you discover at month twelve.

What to do this week

You don't have to choose between moving fast and building the right thing. Use the cheap building to act on real signal instead of guesses:

1. Write down your riskiest assumption. Usually it's "people want this enough to change their behavior." Say it out loud.
2. Talk to 5–8 of the exact people you're building for. Not to pitch — to understand the problem they actually have.
3. Treat the idea as a hypothesis. Decide, before you build, what evidence would prove you wrong.
4. Measure demand directly. Once people are using it, run the Sean Ellis survey and get a PMF score. That's your early-warning system for "no market need."
5. Watch the trend, not the snapshot. A score climbing month over month means you're building the right thing. A flat one means it's time to listen harder.

The teams that survive the AI era won't be the ones who shipped the most. They'll be the ones who used cheap, fast building to chase a number that actually matters — and had the discipline to measure it. Discovery isn't a phase you skip because you move fast. It's the reason moving fast actually pays off.