You Don't Validate Ideas. You Test Assumptions.

"I need to validate my idea" is probably the most common sentence in startup land. It's also one of the least useful, because it frames the entire exercise wrong.

Validation implies a binary outcome. You go out, you talk to people, and you come back with a verdict: valid or not valid. Thumbs up or thumbs down. Like some Roman emperor deciding the fate of your SaaS product.

The problem is that your idea isn't one thing. It's a stack of assumptions, each of which could independently be wrong. And treating it as a single thing to validate is how you end up six months in, confident in your conviction and wrong about everything that matters.

The assumption stack

Consider a founder building a tool that helps Series A CTOs speed up code reviews. Behind that single sentence are at least five separate bets:

1. Problem: CTOs at Series A companies feel acute pain around slow code reviews
2. ICP: Series A is the right segment (not seed, not Series B)
3. Solution: An automated tool is what they'd want (not a process change, not more engineers)
4. Willingness: They'd pay for it (not just say "cool, interesting")
5. Distribution: You can actually reach these people at a reasonable cost

Each of these can be true or false independently. You could have a real problem but the wrong customer segment. A willing buyer but no way to reach them. A valid everything except that nobody will pay more than $20/month for it.

"Validating your idea" treats this stack as a single block. It's not. It's a Jenga tower, and you need to figure out which blocks are load-bearing before you start pulling.

Let's look at each one more carefully, because the devil is in what founders mistake for evidence.

Problem. Good evidence looks like people describing the pain unprompted, in their own words, without you leading them there. You ask "what's frustrating about your engineering workflow?" and they bring up code reviews on their own. Bad evidence: you describe the problem and they agree it sounds annoying. Of course it sounds annoying — you framed it that way. The gap between "yes, that's a problem" and "I actively lose sleep over this" is the gap between a feature request and a business.

ICP. Good evidence looks like a noticeable intensity difference between segments. You interview seed-stage CTOs and Series A CTOs and the Series A people are visibly more frustrated — longer answers, more specific complaints, unprompted mentions of money or time wasted. Bad evidence: you talked to three Series A CTOs and they all had the problem. Three people is not a pattern. It's a coincidence that feels like a pattern because you want it to be one.

Solution. Good evidence looks like people describing a desired outcome that maps to what you'd build, without you showing them your mockup first. "I wish I could just get a summary of what changed and what the reviewer should focus on" — that's a pull toward a solution shape. Bad evidence: you show someone a prototype and they say "yeah, this looks useful." You've just asked someone to evaluate a thing you're clearly proud of. Most people aren't going to tell you it's pointless to your face.

Willingness. Good evidence looks like commitment. Pre-orders. Deposits. A signed LOI. Someone saying "if you build this, send me the invoice." Bad evidence: "I'd definitely pay for that." This sentence has been uttered millions of times in the history of startups and converted to actual revenue approximately never. People are excellent at imagining a future version of themselves who spends money on things. They're considerably less good at actually doing it. The only reliable signal for willingness is a behavior that costs something — money, time, reputation.

Distribution. Good evidence looks like a tested channel with real numbers. You ran $300 in LinkedIn ads targeting Series A CTOs and got a 3% click-through rate and 12 email signups. You can do math on that. Bad evidence: "we'll use content marketing and LinkedIn outreach." That's a plan, not evidence. Lots of plans sound reasonable. Most of them don't survive contact with a real audience.

The evidence quality spectrum

Not all evidence is created equal, and this is where founders consistently fool themselves. There's a spectrum from weak to strong, and most "validation" lives at the weak end.

Anecdotal (weakest): "My friend who's a CTO said this would be useful." One person's opinion, likely influenced by their relationship with you. Worth approximately nothing as market evidence, no matter how smart your friend is.

Self-reported interest: "I surveyed 50 people and 70% said they'd use it." People are unreliable narrators of their own future behavior. Surveys measure what people think they'd do, which correlates loosely with what they'd actually do. The correlation gets worse the more hypothetical the question.

Observed behavior (unprompted): "In 8 out of 12 interviews, the participant brought up code review speed as a top-3 pain point before I mentioned it." Now we're getting somewhere. You didn't lead them. They volunteered it. They used emotional language. This is a real signal that the problem exists and has salience.

Commitment behavior: "I put up a landing page with a $49/month price point and 4% of visitors clicked 'Start Trial.'" Someone took an action that costs them something — even if it's just the micro-commitment of clicking a payment button. This is behavioral data. It's not perfect (some people click and bounce) but it's orders of magnitude more reliable than asking "would you pay for this?"

Revenue (strongest): "Three companies are paying us $200/month for a manual version of the service." Money changed hands. Repeatedly. For the thing you're offering. This is as close to proof as you get in the early days.

Most founders stop at the second tier — self-reported interest — and call it validation. "We talked to a bunch of people and they all said they'd use it." That's not validation. That's a survey of human politeness. Real evidence requires you to create situations where people reveal their preferences through actions, not words.

The order matters more than you think

Most founders test assumptions in the order that feels most natural, which usually means building something. You sketch a UI, write some code, put together an MVP. This feels productive because it is productive — you're making tangible progress.

But you've just spent three months testing assumption #3 (does the solution work?) when you haven't established whether assumption #1 is true (does anyone actually have this problem?).

If nobody has the problem, it doesn't matter how elegant your solution is.

The right order is roughly: start with whatever would be most catastrophic to get wrong. If your problem assumption is shaky, test that first. If you're confident about the problem but have no idea whether your target customer actually cares, test that. If everything checks out except distribution — well, that's actually the one that kills most startups, so maybe test that earlier than you think.

What goes wrong when you validate out of order

Testing assumptions in the wrong order doesn't just waste time. It creates specific, pernicious failure modes that are hard to diagnose because everything feels like it's working.

Building before validating the problem means you optimize for a pain that might not exist. You ship, you get polite feedback ("neat idea!"), and you interpret the lack of traction as a product problem. So you iterate on features. You add integrations, improve the UI, build onboarding flows. Each iteration feels like progress, but you're polishing a solution to a phantom problem. You can do this for a surprisingly long time because there's always one more feature to add, one more thing to fix. The product gets better, but it never gets used, and you never confront why.

Validating the problem but skipping the ICP means you build for a blurry audience. You know the pain is real — you've confirmed that. But you build for "engineering managers" generally rather than discovering that the pain is sharpest at companies with 20-50 engineers who've just started doing formal code reviews for the first time. Without that specificity, your messaging is generic, your product tries to serve too many use cases, and your early users are a random assortment of people with vaguely related but actually different needs. You can't iterate because the feedback contradicts itself — one user wants more depth, another wants more speed, a third wants something you never imagined.

Validating problem and ICP but skipping willingness is the gentlest trap. You have enthusiastic users. They love the product. They use it regularly. And when you introduce pricing, they vanish. Or they stay but only at a price point that can't sustain a business. You've built a popular free tool, which is a fine thing to have but isn't a company. This one stings because you were so close — everything worked except the part where money changes hands.

Validating everything except distribution is the quiet killer. Your problem is real, your ICP is sharp, your solution is strong, people will pay. But you can't get in front of enough of the right people at a cost that works. Your CAC is three times your LTV. The communities where your ICP hangs out are saturated with competitors. The LinkedIn outreach that worked for your first 10 customers doesn't scale to your next 100. This assumption is the one founders test last and it should probably be tested second or third, because a business with great product-market fit and no distribution is just a secret.

"But I talked to people"

Talking to people is good. Talking to people and concluding "they seemed interested" is not validation of anything.

Interest is the politeness tax. Most people, when you describe something you're working on, will say encouraging things. They'll nod. They'll say "oh, that's cool." They might even say "I'd use that." None of this is evidence of anything except that humans are generally nice when someone is excited about something.

Evidence looks different. It's specific. "Three out of eight CTOs I interviewed mentioned slow code reviews unprompted when I asked about their biggest engineering bottlenecks." That's a signal. "Everyone I talked to thought it was a great idea" is not.

The difference is whether you're collecting reactions or collecting data. Reactions are what you get when you pitch. Data is what you get when you observe and ask open-ended questions. "Tell me about your last code review" will teach you more than "would you use a tool that speeds up code reviews?" The first question invites a story. The second invites a yes.

What changes when you think in assumptions

Once you stop trying to validate your idea and start trying to test specific assumptions, a few things shift:

You can be wrong about something without being wrong about everything. Your problem might be real but your ICP might be off. That's not a failure — it's progress. You've narrowed the search space. This is what real iteration looks like — not adding features to a product nobody wants, but updating your model of the world based on evidence. You still have four assumptions standing. That's four more than the founder who ran a single "validation" sprint and gave up when it didn't produce a clear yes.

You know what to do next. Instead of the vague anxiety of "is this a good idea?", you have a specific question with a testable answer. "Do seed-stage CTOs feel this pain more acutely than Series A?" is something you can actually go find out. The answer might take a week of interviews. It won't take three months of building. And when you have the answer, you'll know whether to keep going, shift your focus, or move on entirely — not based on a gut feeling, but based on something you learned.

You stop building prematurely. When the goal is testing assumptions, and the riskiest assumption is about the problem or the customer, building an MVP is the wrong tool. Conversations, surveys, landing pages — these are faster and cheaper ways to test the things that matter most. We've somehow internalized the idea that "real" startup work means writing code. It doesn't. Real startup work means reducing uncertainty. Sometimes code is the tool for that. Often it's not.

You accumulate evidence instead of opinions. Each test produces a result. Over time, these results compound into something you can actually reason about, instead of a pile of anecdotes and gut feelings. You build a map of what you know, what you've tested, and what you're still guessing about. That map becomes the foundation for every decision — what to build, who to build for, where to spend your time. Without it, you're navigating by vibes.

The uncomfortable part

This approach requires you to be honest about what you don't know, which is harder than it sounds. Most founders (myself included) are naturally optimistic — you kind of have to be to start a company. Listing out all the ways you might be wrong feels like inviting failure.

But the assumptions are there whether you list them or not. The question is whether you find out which ones are wrong now (when it's cheap to adjust) or later (when you've burned six months of runway on a solution to a problem that three people have).

There's a version of this that's genuinely uncomfortable to hear: your conviction about the idea is not evidence for the idea. Feeling certain is a psychological state, not a market signal. The most confident founders we've talked to are roughly as likely to be right as the least confident ones. The difference is that the uncertain ones tend to test more, because they know they don't know. Certainty is the enemy of learning.

Optimism is a feature. Willful ignorance about your own risk isn't. And the fastest way to turn optimism into something useful is to give it a structure — a list of assumptions, a ranking of risk, and a plan to learn what you need to learn before you build what you want to build.

---

Launcherly helps founders identify the assumptions their business depends on, prioritize them by risk, and test them in the right order. Start your free trial.