How do you validate a startup idea before building it?

Validation means proving that a specific, reachable group of people has a problem bad enough that they'll change their behavior to solve it—before you invest months building a solution. The founders who skip this step tend to build products nobody asked for and blame the market. The ones who do it well treat the pre-build phase as a research sprint, not a formality.

Write down your hypothesis in one page before talking to anyone

Most founders carry their idea as a vague mental image—a half-formed sense that 'people need this.' That ambiguity is dangerous because it lets you unconsciously reshape the idea to fit whatever you last heard. Force yourself to write a single-page document that states: who the customer is, what specific problem they have today, why the current solutions are inadequate, and what your solution does differently. This is not a business plan. It is a falsifiable hypothesis you are about to try to break.

Paul Graham's observation about writing—that it forces you to commit to a single, optimal sequence of words and surfaces things you didn't consciously realize—applies directly here. Writing out your idea exposes gaps in your own reasoning that a casual conversation never would. You'll often discover mid-sentence that you don't actually know why someone would switch from whatever they use today. That confusion is signal, not noise. Fix it before you talk to customers.

A good one-page hypothesis has three testable claims: (1) this type of person has this problem frequently enough to matter, (2) they currently solve it in a way that is painful or expensive, and (3) they would prefer your approach if it existed. Each claim should be written as a prediction you can go confirm or deny in the next two weeks.

Find five to ten real people who match your target customer and talk to them

Not your friends, not your family, not fellow founders at a co-working space. You need people who are actually living the problem you think you're solving. If you're building software for restaurant supply chain managers, you need to find restaurant supply chain managers—not restaurateurs in general, and not logistics people from a different sector. Specificity at this stage is a feature, not a limitation.

Paul Graham's point about Facebook starting deliberately at Harvard before expanding is instructive here. The tightness of the initial audience wasn't a constraint—it was the mechanism that made early users feel the product was genuinely made for them. When you're validating, a narrow target group makes your conversations far more diagnostic. If you talk to 'small business owners broadly,' you'll get mush. If you talk to 'independent tax preparers who file more than 200 returns a year,' you get actionable signal.

In these conversations, your goal is not to pitch. It is to understand the current workflow in painful detail: what do they do today, how long does it take, what breaks, what have they already tried. The best validation conversations feel like investigative journalism, not sales calls. If someone spends twenty minutes venting about a problem unprompted, that's more valuable than ten people saying 'yeah, I guess that would be useful.'

Look for evidence of behavior, not expressions of interest

The single most common validation mistake is conflating 'people said they'd use it' with 'people have a real problem.' Humans are polite. When you describe your idea, most people will not want to disappoint you. They'll say it sounds interesting. That tells you almost nothing about whether they'll pay for it, integrate it into their workflow, or recommend it to a colleague.

Behavior tells the truth. Ask potential customers what they're doing right now to solve the problem. If they've cobbled together three spreadsheets, hired a part-time contractor, or paid for an expensive workaround, those are behavioral signals that the problem is real. If they say they mostly just live with it, that's a warning sign—either the pain isn't acute enough or you've misidentified the problem. Ask how much time or money they currently spend on the problem. If the answer is 'not much,' your target market may not care enough to switch.

An even stronger signal: has anyone tried to pay you already? Paul Graham has emphasized the importance of recruiting users manually and doing things that don't scale precisely because that direct, hand-to-hand contact is where real signal lives. If you can get even one person to pre-pay, sign a letter of intent, or agree to be a design partner before you build, that's more valuable validation than a hundred survey responses.

Run a cheap experiment that simulates the core value exchange

After customer conversations, you should have a clearer view of which specific part of your hypothesis is most uncertain. Design the cheapest possible experiment that tests exactly that uncertainty. This is not about building a full MVP—it's about isolating your riskiest assumption and testing it in isolation.

For example: if your hypothesis is that busy HR managers will pay to automate a specific compliance report, don't build the automation first. Create the report manually using publicly available tools and offer to deliver it to three HR managers for free. If they use it, share it with colleagues, or come back asking for more, you have strong directional evidence that the output is valuable. If they glance at it and file it away, you've learned something important before writing a line of code. The goal is to simulate the value exchange—them getting something, you providing it—as cheaply and quickly as possible.

This approach also gives you the first version of what Paul Graham calls 'making users super happy.' The founders who manually do the thing their software will eventually automate often learn more about the product's real requirements in two weeks than they'd learn in six months of building. You see exactly where the friction is, what the user actually cares about, and which features you assumed mattered turn out to be irrelevant.

Know your competitors honestly before you convince yourself you have none

One of the clearest signals that a founder hasn't done real validation is when they claim to have no competitors. Every problem that's real enough to build a business on has already attracted some form of solution—whether that's a direct competitor, a legacy tool, or just 'the way people do it manually today.' Claiming no competition usually means you haven't looked carefully, and it signals to anyone evaluating your idea that your market research is shallow.

Paul Graham's perspective on YC partner interviews is relevant here: they hold it against founders who appear either unaware of competitors or dismissive of the threat they pose—not because competitors are likely to kill you, but because your awareness of the competitive landscape is a proxy for the quality of your thinking. The same logic applies to self-validation. If you've mapped the competitive landscape honestly, you understand why your approach is different and what specific switching cost or user preference you're betting on.

In practice, spend a few hours documenting every alternative a potential customer could use—including doing nothing. For each alternative, write down why it's insufficient for your target customer. That document will sharpen your positioning, focus your early product decisions, and help you articulate your angle clearly when you talk to customers, investors, or early hires.

“The feedback you get from engaging directly with your earliest users will be the best you ever get.”

— Paul Graham, source

The one thing to do

Before writing any code, write down your three core assumptions, find ten real potential customers, and run the cheapest possible experiment that proves or disproves the most uncertain one.

Frequently asked questions

How many customer conversations do I need before I can start building?

There's no magic number, but five to ten in-depth conversations with people who genuinely match your target customer will surface most of the patterns worth knowing. What matters more than quantity is whether you're hearing unprompted frustration, seeing behavioral evidence of the problem, and finding at least two or three people who want the solution badly enough to act—by pre-paying, joining a waitlist with commitment, or agreeing to pilot it.

What if my idea requires building something before anyone can evaluate it?

Almost no idea actually requires a fully working product to validate the core value hypothesis. If you're building a complex data platform, you can manually pull and present the insight first. If you're building a marketplace, you can broker the first transactions by hand. The question to ask is: what is the simplest thing I can do that lets a real customer experience the core value? Start there.

Is a landing page with an email signup form sufficient validation?

It's a weak signal on its own. Email signups cost the visitor almost nothing, so a high conversion rate tells you your copywriting is compelling, not that you have a real business. Pair it with conversations, and treat signups as leads to follow up with personally—not as proof of demand.

How do I validate an idea in a market where I have no existing connections?

Start with communities where your target customer already spends time: forums, LinkedIn groups, industry Slack channels, subreddits, conference attendee lists. Offer genuine value first—answer questions, share a useful resource—before asking for a conversation. Cold outreach works when it's specific and shows you understand the person's actual situation.

Sources

More playbook answers · Growth Prophet home