How To Pick A Startup Idea

You're sat on three startup ideas, can't pick, so you tinker with all of them and call it research. John from YC has a word for that. Wheel-spinning.

This one's a partner at YC laying out a rubric for how to stop overthinking, pick an idea, commit, and find out fast whether it's actually working. The whole thing hinges on one blunt idea: you cannot progress on a startup without committing to a single thing. Dabbling feels safe. It's the opposite.

First, stop hunting for the perfect idea. John says it's understandable (startups are hard, surely you'd want the best one before you commit), but it's impossible to find the perfect idea in the abstract. You only figure out what to work on by making contact with reality and talking to customers. Everything else is daydreaming with a spreadsheet open.

Second overthink: "am I the right founder for this?" Founder-market fit is real, sure. A non-technical founder probably won't dream up a killer DevTools idea. But John reckons founders, especially second-timers, weaponize this against themselves. They convince themselves they need a decade of domain experience before they're allowed to start. They don't. Pick something you're curious about, go extremely deep, talk to customers, and you can build extraordinary knowledge fast. His example: Blake Scholl, CEO of Boom Supersonic. Spent his early career on adtech at Amazon and Groupon, then decided to commercialize supersonic flight. People thought he was mad. Boom's now a billion-dollar company. So stop asking permission.

Now the meat: commit to one idea. Founders who juggle several think they're hedging. They're producing bad data. If you don't go deep on one, you get no real signal, and no signal means you either talk yourself out of a good idea or keep flogging a dead one. The fix is to go deep first.

What does deep actually mean? Burn the other boats. Explicitly kill your other options, stop working on them, tell any customers you've pivoted, and work with single-minded focus on the one you chose. John says it should feel like wearing new skin, you become an almost unrecognizable version of yourself. New company name, new emails, new website, even a new internal story about why you're building at all. His example is GovDash, who help customers win government contracts. They pivoted at least five times before landing on it, and each time they changed the company name and the mission. John says he literally lost track of how to contact them because the emails kept changing. By actually becoming experts in government procurement, idea number five worked so well they could barely keep up with demand. Just raised a Series B.

How do you know you're going deep enough? Here's the watermark John uses: could you actually run your customer's business? Say you're building voice customer service agents for cleaning companies. It's not "have I talked to 20 owners." It's: drop you into a cleaning business tomorrow, could you run it? Do you know their daily crises? Is answering the phone even a top-five problem? How much business do they lose on an unanswered call, and what would they pay to never lose another one? Another framing: could you teach a class on the problem? Are you one of the most informed people in the world on it? Getting there means loads of customer conversations and sometimes doing the job yourself. But don't obsess over talking to hundreds before you write code. Run a tight loop: understand the customer, ship product, understand deeper, ship better. Real users produce concrete data that complements the abstract stuff.

Then the qualities of a good idea in the AI era. One: it sits at the edge of what models can do today. It might barely work on frontier models now but clearly improve as they get better. Know your bottlenecks intimately, because if one doesn't clear, solving it might become the company. That's Paul Graham's "live in the future and build what's missing." Two: it should verticalize, meaning sell an outcome, not software. Software cost is going to zero, so the value lives in customer trust, licenses, regulatory permission, outcome ownership. Don't build software for insurers, be the insurer. Don't build back-office software for banks, be the bank. Example: Corgi Insurance, YC summer 24, an AI-powered commercial insurer. They refused to be a broker or even a managing general agent because that's owning a slice. They went for the whole stack, underwriting to customer service, and acquired an insurance carrier mid-batch to do it. Result: underwrite any line in any vertical with a fraction of the headcount, better pricing, faster turnaround, all the economics.

Three: be the most ambitious version of itself. Counterintuitive, but a wild idea and a modest one cost roughly the same. Both are brutally hard, both eat your life. So aim at the version that rewrites a sector, because that's also the version that fends off competitors, pulls the best talent, and has a real moat. Think heavily regulated industries, taking on a $10bn legacy SaaS incumbent, or hard tech like robotics for space assembly.

And if it fails? You're miles ahead of where you started. You've got unambiguous customer data, you know whether the hair-on-fire problem is real or imagined, and you've got conviction to pivot on. More to the point, going deep usually hands you a better idea underneath. Most founders start on surface pain points. The real money's in the deeper structural problems, the bottlenecks and gaps and missing dev tools you only spot from the frontier.

The closer: in the early fog you can see ten feet ahead, so the temptation is a few cautious steps in every direction. That gives you almost nothing. Commit to one direction and walk fast. You generate far more information per unit of time, and you might arrive somewhere better than you could've seen from the start.

The worst failure isn't being wrong. It's never deciding.