How to Validate a Startup Idea

What actually counts as validation, versus a polite yes?

Validation is a signal that costs the other person something real: money changing hands, time spent on a call they did not have to take, or a reputational risk if they share the idea with their own network and it turns out to be nothing. A friend telling you an idea "sounds cool" costs them nothing to say and tells you almost nothing about whether they, or anyone else, would actually use it.

This distinction is the entire game. Y Combinator's own guidance on getting and testing ideas is built around exactly this: start with a real problem, not a solution you already like, and test it in a way that forces a real decision out of the other person, not a hypothetical opinion. How to run customer interviews covers the mechanics of that conversation in more depth than this guide has room for.

Do you need a product before you can test anything?

No. A landing page that describes the problem in the visitor's own words, states the promised fix plainly, and asks for a real commitment, an email, a deposit, a scheduled call, can validate demand before a single feature exists. This is not a shortcut around building the real thing later. It is the fastest, cheapest way to find out whether you are about to build something anyone was actually waiting for.

The trap here is building the landing page around what you want to be true instead of what you have actually heard from people. A page that leads with your product's technology instead of the visitor's problem will convert on curiosity, not need, and curiosity clicks do not turn into paying customers later.

How many conversations do you actually need?

Fewer than most people assume, if each one is structured around a real story instead of an opinion. Ask "tell me about the last time this happened to you," not "would you use a tool that solved this." The first question produces a specific, checkable account. The second produces a polite guess about a hypothetical future, and people are famously unreliable narrators of their own future behavior.

A handful of real conversations that surface the same underlying pattern, the same workaround, the same moment of frustration, is worth more than a hundred survey responses to a leading question. The pattern is the signal. One person's story is an anecdote; five people independently describing the same moment is a real, testable problem. A structured discovery interview script helps here, mostly by keeping you from accidentally leading the witness toward the answer you want to hear.

Signal type	What it tells you	How reliable it is
"Sounds cool" from a friend	Almost nothing; costs the speaker nothing to say	Very low
Survey response to "would you use this?"	A hypothetical, not a behavior	Low
A specific story about the last time the problem occurred	Evidence the problem is real, recent, and remembered	High
Real email on a waitlist after seeing the actual pitch	Mild but real commitment	Medium
Pre-payment or a scheduled follow-up call	Money or time committed before the product exists	High

Should you aim for a broad market or a narrow one first?

Narrow, deliberately. A specific audience with a sharply describable pain point is easier to find, easier to interview, and easier to build a first version for than a broad market defined by wishful thinking. "Small business owners" is not an audience you can validate against. "Solo bookkeepers who invoice five or more clients a month and still use spreadsheets" is, because you can go find exactly those people and ask them a specific question.

Widening comes later, once the narrow version has actually proven itself. Most successful products started narrower than their eventual market, not broader, because a narrow first audience is where the earliest, clearest signal actually lives. If you are still deciding whether that first audience should be businesses or consumers, see B2B or B2C for solo founders.

What is the biggest mistake people make here?

Treating a hypothetical answer as a fact. "Would you pay for this" produces a yes from almost anyone who likes you and does not want to be discouraging. It is not a lie exactly; it is a guess dressed up as a commitment. The fix is not to ask a better version of the same hypothetical question. It is to stop asking hypotheticals and start asking for something real: a pre-payment, a scheduled follow-up, a waitlist signup after seeing the actual offer, not a description of it.

Is validating the idea the same as validating the business?

No, and treating them as one step is how a real problem turns into a startup that still cannot sustain itself. Validating the idea confirms a real problem exists for a specific audience. Validating the business confirms that enough of those people will pay enough, often enough, to make solving it worthwhile as an ongoing effort, not a one-time favor. An idea can pass the first test cleanly and fail the second one just as cleanly, if the willingness to pay never shows up at a price that covers what it costs to deliver.

That is why a real validation plan includes a pricing or commitment test alongside the interest test, not after it. Asking for a pre-payment, even a small deposit, before the product exists tells you something a waitlist signup alone cannot: whether the problem is painful enough that someone will act, not just agree, when money is actually on the table.

Who this guide is for, and who it is not for

This is for a founder, solo builder, or product manager exploring a new idea who wants to know whether a real problem exists before committing weeks to building anything. It matches the audience Builders Camp names directly for this kind of work: aspiring founders, solo builders, and non-technical operators who want to ship a side project or MVP without a technical co-founder, and product managers exploring a new feature who need a validated ICP before scoping it.

It is not a guide to fundraising, and it will not tell you how to pitch investors. Validating that a problem is real is a separate, earlier step from convincing someone to fund solving it, and conflating the two leads people to build a pitch deck before they have a single real conversation to put in it.

What comes after validation actually holds up?

Once you have a real signal, not a polite one, the next real decision is scope: what is the smallest version of the fix you can actually ship, and to whom. That question is covered in more depth in how to build an MVP as a solo founder, and if the idea is a SaaS product specifically, how to build a SaaS with AI as a solo founder picks up from exactly this point. If you have no technical co-founder and want to move straight from a validated idea to something people can actually click on, how to build an app without coding covers that path.

Builders Camp's Discovery Expert Track is built for exactly this discipline: problem discovery, interviewing, synthesis, and validation, for founders and operators validating a new product or entering a new market, and for product managers trying to move from a feature factory into evidence-driven decisions. The track's From Idea to Launch with AI bootcamp specifically covers turning a validated problem into a scoped MVP and a real launch plan in a single week.