Most startups don't fail because of execution. They fail because they picked the wrong problem.

There's a specific feeling most founders know well. You're in the shower, or on a walk, or half-listening in a meeting, and something clicks. An idea. Suddenly your brain is already three years ahead: the product, the name, the pitch, the exit.

It feels like clarity. It isn't.

What you're feeling is pattern recognition mixed with optimism. Your brain connected two things that haven't been connected before, and it rewarded you with dopamine. That feeling is real. The idea being good? That's still completely unknown.

The problem is that the feeling of insight is identical whether the idea is brilliant or terrible. There's no internal alarm that goes off to warn you. And the more ambitious the idea, the stronger the feeling, which makes the most dangerous ideas the most seductive.

Paul Graham wrote about this in 2012, noting that the most common mistake founders make is working on problems they find interesting rather than problems people actually have. That distinction seems obvious when you read it. It disappears the moment you're inside the idea.

The typical startup arc looks like this: idea → build → launch → (silence) → pivot → more building → run out of money.

The validation step — the one that should happen before any building — either doesn't happen at all, or happens in a way that confirms what the founder already believes.

Confirmation bias in early-stage startups is severe. When you've spent three months building something, you don't interview users to find out if the product matters. You interview them to find evidence that it does. You ask questions that lead toward yes. You discount the hesitation. You interpret polite interest as enthusiasm.

Steve Blank, who spent decades teaching entrepreneurship at Stanford and Berkeley, built his entire framework around one idea: get out of the building. His Customer Development methodology starts from the premise that on day one, you have zero facts about your market — only hypotheses. Every assumption needs to be tested before it gets built.

Most founders know this. Almost none do it properly.

The reason isn't laziness. It's that real validation is uncomfortable. Real validation means talking to people who might tell you the problem isn't that bad. That they already have a workaround. That they wouldn't pay for your solution. Real validation means risking the idea — and most founders are too attached to the idea to risk it.

I've noticed that real, painful problems don't announce themselves as opportunities. They show up as complaints, silence, inefficiency, and money leaving through cracks nobody bothered to seal.

Real problems look like:

These aren't elegant problem statements. They don't make for clean pitch decks. They're messy, specific, and operational. But they have something most startup ideas don't: someone is already paying a cost to live with them.

That cost might be money. It might be time. It might be stress, or manual labour, or emotional energy spent managing chaos. But it's real and it's measurable. And when you find it, people will tell you about it unprompted, because they've been living with it for years and nobody ever asked.

Clayton Christensen spent decades studying this through the lens of "jobs to be done": the idea that customers don't buy products, they hire them to do a job. The failures he documented weren't failures of execution. They were failures of problem understanding. Companies that built excellent solutions to problems their customers didn't actually have.

We celebrate execution in startup culture. We talk about speed, iteration, shipping, hustle. These things matter. But they matter a lot less than people think, and they matter almost nothing if applied to the wrong problem.

Think of it this way: execution is a multiplier. If the problem is real and the solution is directionally correct, good execution makes the outcome much better. If the problem is wrong, good execution just means you arrive at failure faster and with more confidence.

I've watched smart, capable people build technically impressive products that nobody used. The code was clean. The design was good. The founders worked hard. None of that helped.

The hard truth is that most failed startups don't fail because they ran out of money, or because competition arrived, or because the market wasn't ready. They fail because nobody wanted the thing badly enough to change their behaviour for it.

Eric Ries, in The Lean Startup, introduced the concept of validated learning — the idea that the fundamental unit of startup progress is not code shipped or features built, but evidence about what customers actually need. The entire lean methodology is, at its core, a response to the problem of building things nobody wants.

Before thinking about technology, design, or business model, there are three questions that deserve honest answers:

Who is suffering? Not "who might benefit from this" — but who is currently paying a cost, wasting time, or carrying stress because this problem isn't solved? If you can't name three specific people, you don't have a problem yet.

What are they doing today instead? Every unsolved problem has a workaround. What is it? A spreadsheet, a WhatsApp group, a manual process, an expensive consultant? The workaround tells you two things: how real the pain is, and who your actual competition is.

Would they pay to make this go away? Not "would they try a free version" — but would they pay, now, for a solution that actually worked? If the answer is uncertain, the pain isn't sharp enough to build a business around.

These questions aren't original. They appear, in different forms, in virtually every serious piece of writing about early-stage companies. And yet most founders skip them, or answer them with assumptions rather than evidence.

If you get the problem right, execution becomes leverage — every decision you make builds on something real, and the market confirms your direction instead of resisting it.

If you get it wrong, execution just helps you fail faster — with better code, a cleaner pitch deck, and more confidence that your assumptions were correct right up until the moment they weren't.

The most valuable thing a founder can build isn't a product. It's a clear, honest understanding of the problem worth solving.

Everything else follows from that.