You have a list. Five to ten things you've been assuming. Now you go and find out.
This is where most startups quietly skip ahead. They've got the spec, they've got the plan, they've got the burning desire to ship something. Validating assumptions feels like procrastination.
It isn't. It's the cheapest insurance policy you'll ever buy.
What testing actually means
An empirical test of a startup assumption isn't a survey. It isn't a focus group. It isn't "we showed them the deck and they liked it."
An empirical test asks the customer to do something. Costly. Specific. Now.
The cost they bear is the signal. If they'll spend nothing — no money, no time, no political capital — they don't really want it. If they'll spend a little, they're polite. If they'll spend something material, you might have something.
Everything that doesn't cost them something is conversation. Conversation is cheap. Conversation lies.
The escalation ladder
Aulet ranks tests from softest signal to hardest. Use the highest rung you can get them to.
Prepay for the solution
The strongest signal there is. Money on the table for something that doesn't exist yet. If you can get prepayment, you've found a customer who actually needs it, not one who thinks it would be nice to have.
Put down a deposit
Half measure on prepayment. Still cash, still real, but the commitment is lower. Useful for higher-priced products where full prepayment would be unreasonable.
Letter of intent
Non-binding, no money, but signed. "If you build X, we commit to evaluating it / piloting it / purchasing it." Worth less than money, more than nothing. Worth a lot more than people realise, because the customer had to get sign-off internally to give it to you.
Agree to a pilot
A timed commitment to use the product. Free or low-cost. Useful for B2B where the buyer wants to derisk. Comes with a real opportunity cost for them — time their team will spend integrating, time their stakeholders will spend evaluating.
Express strong interest with specific conditions
"I would buy this if it had X, Y, Z." Cheapest of all signals, but still useful if the conditions are specific. "I'd buy it if it were free" is not a condition. "I'd buy it if it integrated with our SAP instance" is.
The same five-rung ladder applies whether you're a one-person startup or a $100B venture testing a new line. The strength of evidence is set by the strength of what they're willing to do, not by what they're willing to say.
The lighthouse test
One specific assumption deserves a specific test: are the customers you've identified actually lighthouse or linchpin customers?
A lighthouse's power isn't their own purchase. It's the purchases that follow theirs because they bought.
So test it. Go to a second customer in the segment and ask: "If we got [Lighthouse Company] on board, would that change your evaluation of us?" Watch their face. If they say "well, possibly, depending on what they got" — that's a lukewarm lighthouse. If they say "yes, that would matter a lot, I trust their judgment in this space" — you have a real lighthouse.
If nobody perks up at the name of the customer you've called a lighthouse, they're a customer. Not a lighthouse.
The speed of the experiment
The whole point of this stage is to fail cheap. The longer an experiment takes, the more expensive it is. The more expensive it is, the fewer assumptions you can afford to test.
Run small. Run fast. Run in parallel where you can.
Two weeks of phone calls and follow-up emails will tell you more than two months of building. If two weeks of phone calls produces zero prepayments, zero LOIs, zero pilot agreements, you've learned something that would have cost you two months of engineering to discover.
Don't fall in love with your experiment. Make it cheap, make it short, make the result legible enough that you'll trust it.
What you do with the results
Three buckets. Be honest about which bucket each test falls into.
Confirmed
The assumption held up. Customers behaved as expected. Move on, but note the strength of the confirmation. One LOI confirms less than ten LOIs.
Refuted
The customer behaved differently than your assumption predicted. This is the most valuable bucket. You found a thing you didn't know. Now you go back and fix it. The fix might be small — re-position the value prop — or large — pick a different segment entirely. Either way, do it before you build.
Inconclusive
The test didn't produce a clean signal. You need to run a better experiment. The biggest risk here is treating inconclusive results as confirmation. Most founders do, because they want the assumption to be true. Resist.
The honesty part
The point of step twenty-one isn't to validate your startup. It's to find out whether your startup is what you think it is.
If the tests come back overwhelmingly positive, congratulations, you're in a smaller minority than you think. Most founders find at least one assumption that breaks. That break is information. Use it.
If the tests come back overwhelmingly negative, you have a much bigger problem than a failed experiment. You have a fundamental issue with the proposition. Better to find it now than in production.
Either way, you walk into step twenty-two with cleaner information than ninety-five percent of founders ever have.
The MVP comes next. You're about to build something. Make sure you're building the right thing.