How to validate a startup idea: why most founders get it wrong

When I was initially trying to validate my idea for Seapoint, I discovered that the best way to do it was counterintuitive. As founders, our first instinct is usually to build a case for an idea. That often starts with talking to the people most likely to agree with us. Tuning out those who push back. Emphasising the signals that support us. Explaining away the ones that don’t.

But this is one of the reasons some companies never get off the ground. Startups reward conviction. The ecosystem encourages you to back yourself, ignore the naysayers, keep going when it gets hard. That’s all true, but there’s a version of that advice that tips into delusion, where you’re so convinced your idea is genius that you stop being honest about whether it actually is.

I ran my third startup for nearly five years. Looking back honestly, I knew 18 months in that it wasn’t working, but I didn’t shut it down. I told myself I owed it to the investors and to the employees. There was shame in calling it. So I kept going for another two and a half years. In tech, the opportunity cost of that mistake is enormous.

So, if you’re a seasoned operator thinking about taking the leap or an early-stage founder still trying to figure out if your idea is worth building, my advice is: instead of trying to validate your startup idea, try to disprove it.

Flip it: try to disprove your idea

When your goal is disproof, you go looking for the reasons something won’t work. You talk to sceptical prospects and early customers, not just enthusiastic ones. You ask harder questions. You sit with the signals you’d normally brush off.

And here’s the thing, if you try hard to kill the idea and you can’t, that’s actually meaningful. The ideas that survive a genuine attempt to disprove them are the ones worth backing.

Solve the hardest piece of the puzzle first

When I was at Google X working on drone delivery, this was our entire methodology. Every experiment started with, what’s the thing most likely to kill this? Go find out if that’s true first.

We weren’t in a lab building something beautiful. We were in the Nevada desert with drones duct-taped together, trying to keep them in the air for more than 60 seconds. Because if we couldn’t do that, nothing else mattered.

Most founders do the opposite. They build what’s comfortable. They get the product looking nice. They nail the pitch deck. They do everything except confront the problem that could end the whole thing.

The question you’re most afraid to ask is the one you should ask yourself first.

Get the timing right

One thing this type of experiment won’t always tell you on its own is whether the timing is right.

My first mobile gaming company was the right idea. We were building installable games for Nokia handsets in 2001. The problem was there were about 50,000 phones in Europe that could run them. We were eight years too early, and having the right idea too early is the same thing as being wrong.

When you’re testing an idea, ask not just whether it works, but whether the market is ready for it now. Is the infrastructure there? Are the customers reachable?

Most people treat timing as luck. Something that either works in your favour or doesn’t. I don’t think that’s right. Timing is testable. Is there something available now - a technology, a behaviour shift, a regulatory change - that makes your idea possible in a way it wasn’t before? If the answer is no, that’s a signal worth taking seriously.

Speed matters even more than you think

At Google X, we never debated whether to run an experiment. We always ran it. The drone that crashed in 60 seconds told us more than a week of whiteboarding would have. Every failure was data. Every data point made the next experiment better.

Jeff Bezos said Amazon’s innovation came down to one thing: the speed and volume of experimentation. Running more experiments, faster, than anyone else. I believe it. The advantage isn’t any single experiment. It’s the number of them you can run. And the goal isn’t to avoid failing. It’s to fail fast, learn something useful, and run the next experiment.

Remember: failure is part of the process

The hardest thing for an early stage founder isn’t starting. It’s being honest about whether you’ve actually achieved what you set out to do. Decide what failure looks like before you’re emotionally attached to the outcome. Write it down. Then stick to it.

If a founder hasn’t experienced 10 or 20 failures, they probably haven’t been pushing hard enough. Failure is part of the process. The founders who build something real have usually failed more than anyone around them - they just failed faster. The worst thing you can do in life is fail slowly.

I once built a neural network to automate sports gambling. Made money the first month, lost it the second, and by month three it was clear there was no edge. It failed. And honestly? I learned more about how AI actually works than I would have any other way. That knowledge is still in use today at Seapoint. The experiment that fails but teaches you something, that’s the process working.

Seapoint handles your startup’s financial ops so that’s not the thing slowing you down. No forms. Sign up here