The honest guide to knowing if your idea is worth building

Most founders spend months building before they talk to a single real customer. Here is a more useful order of operations, drawn from the people who have seen more startup launches than anyone.

Paul Graham has a line that founders tend to memorise without fully acting on: "The way to get startup ideas is to notice things that seem to be missing." It sounds simple. The trap is that most people interpret "missing" as something they personally wish existed, rather than something a large number of people are actively struggling with right now.

There is a difference between a product you would enjoy using and a problem that makes people's lives genuinely worse in its absence. The first category produces lifestyle projects. The second produces companies.

Start with the problem, not your solution

Y Combinator's application asks founders to describe the problem they are solving before asking about the product. That ordering is deliberate. The product is your current best guess at a solution. The problem is what actually matters, and it stays stable even as your product changes completely.

Michael Seibel, who has interviewed thousands of founders at YC, says the clearest signal a startup is in trouble is when the founder can describe their product in one sentence but struggles to describe the problem in two. If you have spent more time thinking about features than about why people are suffering without those features, that is worth pausing on.

A useful exercise: write down the problem your idea solves, then ask whether someone who has never heard of your product would describe that same problem using similar language. If the answer is yes, you are likely working on something real. If the description only makes sense once you explain your solution, you may be retrofitting a problem to a product.

The conversation most founders skip

Rob Fitzpatrick, in his book The Mom Test, makes a point that YC reinforces constantly: most customer conversations give founders false confidence because founders ask the wrong questions. "Would you use this?" produces a yes almost every time, because people are polite and they want to be encouraging.

The questions that actually tell you something are about the past, not the hypothetical future. How do you currently handle this? How much time does that take? What have you tried? What happened the last time this was a problem? These questions are harder to answer with politeness. They require real recall. And the answers reveal whether the problem is active and painful, or theoretical and tolerable.

YC partners describe this as finding "hair on fire" problems. A person whose hair is on fire is looking for any bucket of water. They are already trying things. They have already paid for partial solutions. They will tell you, without prompting, that the problem is urgent. That kind of customer is infinitely more valuable to talk to than someone who agrees your idea sounds interesting.

What "validated" actually means

Founders often treat validation as a checkbox. You talk to a few people, they say the idea sounds good, and you move forward. But that is not validation in any meaningful sense. Validation means you have evidence that a specific group of people have a specific problem badly enough that they will change their behaviour to fix it.

Graham's essay on organic startup ideas distinguishes between ideas that come from noticing gaps in your own life versus ideas that come from sitting down and trying to think of startup ideas. The second approach almost always produces ideas that sound plausible but lack the lived urgency that makes for a strong market. The best ideas tend to come from founders who are so personally frustrated by a problem that they build the solution out of necessity first.

That founder-problem fit matters beyond just motivation. It means you are likely already a potential customer, which means you have a built-in sense for whether your solution actually works. You know what good looks like because you need it yourself.

On the question of market size

A common mistake is to research total addressable market before confirming that any individual within that market has the problem badly enough to pay for a solution. Market size is useful for thinking about ceilings. It tells you almost nothing about whether you have product-market fit.

YC's advice here is consistent: find ten people who love your product before you worry about finding a million who might tolerate it. A small number of genuinely delighted early users is a far stronger signal than a large number of people who say they might try it someday.

Kevin Hale, who ran Wufoo and later joined YC as a partner, talks about the importance of making users happy rather than making them satisfied. Satisfied users stay. Happy users tell other people. The question worth asking in validation is not "will they pay for this" but "will this change how they describe their week to someone else."

Do things that produce information

"Do things that don't scale" is probably the most quoted piece of YC advice, and it is usually applied to growth. It applies equally to validation. The things that produce real information about whether your idea has legs are the same things that feel inefficient: manual demonstrations, one-on-one conversations, hand-holding early users through a process that your eventual product will automate.

Airbnb's founders photographed apartments themselves. Stripe's founders set up payment processing manually for early users. These were useful because they kept the founders in direct contact with the actual experience of their customers. You learn things in those conversations that no survey or analytics dashboard will show you.

Before you build infrastructure, build understanding. The infrastructure scales. The understanding has to be earned in person, one conversation at a time.

A useful order of operations

Based on what YC has repeatedly seen work, here is a sequence worth following before you write meaningful amounts of code:

1. 01Write down the problem in one sentence, from the customer's perspective, using language they would use.
2. 02Identify five to ten people who currently have that problem. Find them through communities, forums, or your own network.
3. 03Have conversations focused entirely on their current behaviour and past experience. Ask nothing about your product.
4. 04Look for specifics: time lost, money spent, workarounds attempted. Vague frustration is a weak signal. Concrete examples are a strong one.
5. 05After those conversations, assess whether the problem is active, recurring, and something people are spending resources to address.
6. 06Only after that, sketch the simplest possible version of your solution and show it to the same people. Watch what they do, not just what they say.

What to do with what you find

If your conversations produce consistent, specific evidence of a painful and active problem, keep going. If the responses are vague, inconsistent, or heavily qualified, that is useful information too. It means either the problem is real but you are talking to the wrong people, or the problem is less severe than you thought.

Both outcomes are good. The first points you toward a better-defined customer segment. The second saves you from building something for a problem that people can live with.

Graham's framing is useful here: the goal of early-stage validation is to get to a clear answer as fast as possible. Fast answers, even ones that redirect you, are worth more than slow answers that tell you what you want to hear. The founders who iterate quickly tend to outlast the ones who spend a year perfecting something before showing it to anyone.