"Validation" has become a ritual, a few interviews, some encouraging nods, then straight into building. But nods aren't evidence. Before committing months of engineering, three specific claims are worth testing.
1. The problem is expensive enough to pay to remove
People will agree a problem is annoying. Far fewer will pay to make it go away. The test isn't "would you use this?", everyone says yes to be polite. It's "what do you do about this today, and what does that cost you?" If the honest answer is "nothing, it's fine," there's no product yet.
2. You can reach the buyer repeatably
A product with no path to its customer is a hobby. Before building, find one channel you can use again and again. If the only way you can imagine getting customers is "go viral" or "we'll figure out sales later," that's the risk to test first, not the feature set.
3. The first version is small enough to actually ship
Founders routinely validate a vision and then build the vision. The thing to validate is the smallest version that delivers real value to one type of user. If you can't describe that version in a sentence, you're not ready to build it.
What this looks like in practice
- Replace "would you use this?" with "show me how you do this now."
- Try to sell the thing before it exists, a pre-order, a paid pilot, a deposit. Money is the only honest signal.
- Write down the one metric that would tell you the MVP worked, before you build the MVP.
The counterargument
"Some things can't be validated without building them." Occasionally true, deep technical bets, genuinely new categories. But even then you can usually validate the problem and the reachability cheaply, and reserve the expensive, unvalidatable part for last. The goal isn't to eliminate risk. It's to spend your build budget on the risk that's actually worth taking.