How to validate a startup idea on evidence, not eloquence

Here is the uncomfortable pattern: the founders who describe their idea most beautifully are not the founders whose ideas survive contact with customers. Articulation and validation are different skills, and almost every tool, pitch template, and well-meaning mentor accidentally rewards the first while claiming to test the second. If you want to validate a startup idea before building it, the discipline is learning to tell the two apart in your own work.

Primary evidence beats secondary retrieval

Evidence about your idea comes in two kinds. Secondary evidence is what already exists in public: market reports, competitor sites, search volume, what an AI model can retrieve and summarize about your space in thirty seconds. It is cheap, fast, and worth collecting — and it is evidence about the MARKET, not about your idea. Nobody ever validated a startup from secondary sources, because the thing being tested — will these specific people change their behavior and pay — isn't written down anywhere yet.

Primary evidence is what you generate yourself: interviews where a buyer describes the problem in their own words, a pilot where retention holds at week eight, a pricing conversation where someone says yes to a number. It is slow and sometimes embarrassing to collect. It is also the only kind investors weigh, because it is the only kind that could have come out differently.

Completeness is not proof

Most validation checklists measure completeness: did you fill in a persona, a TAM, a value proposition? Completeness is a useful progression mechanic — you genuinely cannot test pricing before you know who the buyer is — but a complete answer is not a strong one. "Store managers" typed into a persona box passes the checklist; twenty-four recorded interviews with operations managers who rank the problem in their top three weekly costs is proof. Track the two separately: gates for "can I move on," quality for "would this survive a skeptic." The moment one number tries to be both, it lies in whichever direction flatters you.

The seven stages of proof

Validation has an order, because each stage's evidence is the input to the next one's experiment:

1. Diagnose — name the problem, who has it, and why now. Evidence: a specific group, a measured cost, a reason the timing changed.
2. Discover — talk to that group. Evidence: 15+ interviews, verbatim quotes, the pains THEY rank — not the ones you pitched.
3. Define — cut to the smallest thing that delivers the value. Evidence: a must-have list of three, and an explicit not-building list.
4. Validate — does anyone pay and come back? Evidence: PMF survey signal, retention that holds, unit economics that survive arithmetic.
5. Ignite — one beachhead, one channel. Evidence: a named list of first customers and a measured acquisition cost.
6. Deploy — make it repeatable. Evidence: a sales playbook with measured conversion, margins that fund the next stage.
7. Dominate — defensibility. Evidence: a moat you can name, revenue that compounds inside a market that actually fits it.

Run the absurdity checks

Numbers that pass a checklist can still fail arithmetic. Before you show anyone a deck, divide your claims by each other: claimed annual revenue against your obtainable market (if revenue exceeds the whole SOM, one of them is fiction); one customer's annual price against that same SOM (if a single customer out-earns it, the sizing is a placeholder); SOM against SAM (a slice that is 0.06% of its market is not a plan, it's a rounding error); a 50:1 LTV:CAC next to single-digit retention (nobody keeps customers they can't retain). One absurd pass kills the credibility of every honest number around it — investors check these first precisely because they are checkable.

Let something push back

The most useful thing in any validation process is the entity that disagrees with you — a co-founder who asks "says who?", a customer who shrugs, an advisor who reads your own answers back to you and points at the gap between them. If your current process contains nothing that pushes back, you are not validating; you are rehearsing. Build the skeptic in: write down, before each experiment, what result would kill the idea — then run the experiment honestly enough that it could.

A checklist you can start today

• Write the problem in one sentence with a number in it.
• Book five conversations with people who have the problem this week. Record exact words.
• Separate your progression (what's filled in) from your proof (what would survive a skeptic).
• Run the absurdity checks on every number you claim.
• Define the kill criterion before each experiment, not after.

This method is what ValidLab operationalizes: seven stages with explicit gates, a quality verdict that is scored separately from completeness, magnitude checks that error on absurd claims, and an Advisor that cites your own answers back at you. But the method works on paper too. The tool just makes it hard to lie to yourself.