Most validation is theater. Someone has an idea, describes it to twenty people who like them, hears twenty encouraging responses, and concludes the market wants it. Then they build for nine months and find out that liking an idea and paying for it are unrelated activities.
The failure is structural rather than lazy. A test that cannot come back negative is not a test. If you design the conversation so the pleasant answer is the easy one, you will get the pleasant answer every time, and you will have learned nothing while feeling like you learned a lot.
Write the kill criteria first
The single most useful habit here is deciding what a no looks like before you go looking.
Before we talk to anyone, we write down the specific result that would make us stop. Not a vague standard like "if there is not enough interest." Something checkable: if fewer than a third of the people we talk to have tried to solve this already, we stop. If nobody has spent money or meaningful time on a workaround, we stop.
Doing this in advance matters because you cannot do it afterward. Once you have spent three weeks on something, every result becomes evidence for continuing. You will find the reframe. Everyone does. The written criterion is a message from the version of you who had no sunk cost, and it is the only one you should trust on this question.
The related discipline is being willing to act on it. Studios drown in ventures that should have been stopped at month four and instead limped to month twenty, consuming the attention that the next venture needed. Killing things well is a bigger determinant of studio outcomes than picking things well, and it gets far less attention.
Look for existing behavior, not stated interest
The most reliable signal that a problem is real is that people are already doing something awkward about it.
We are looking for the spreadsheet someone maintains by hand. The recurring calendar reminder. The junior employee whose actual job turns out to be copying data between two systems. The tool being used for something it was obviously not designed for. These are all evidence of a problem someone is paying for already, in time if not in money.
Stated interest is much weaker evidence, because it costs nothing. "I would definitely use that" is a polite noise. "Here is the file I keep" is data.
The questions that surface this are all backward looking. What did you do the last time this came up. Walk me through the most recent time. What did you try before this. When did you last look for something to fix it. Questions about the past have answers. Questions about the future have guesses, and people are generous with their guesses.
Ask about the workaround, not the product
Once we find the awkward behavior, we do not describe our solution. We ask about theirs.
How long has this been the process. Who else is involved. What breaks when it goes wrong. What happens if it just does not get done this week. That last one is the important one, because the answer separates a real problem from an irritation. If the honest answer is "nothing much," we have found something annoying, and annoying does not sustain a subscription.
Describing your solution too early contaminates everything afterward. People are agreeable, they want the conversation to go well, and once they know what you are hoping to hear they will help you hear it. Every answer after that point is worth less.
Then make the test cost something
Talk is the cheap layer. At some point the test has to involve the person giving up something they care about.
The forms this can take, in rough order of strength: putting in time to give real feedback on something concrete, committing to try it with a real deadline, agreeing to be a first customer at a stated price, and actually paying.
Payment is the strongest signal in the set, and it is strong specifically because it is uncomfortable to ask for. That discomfort is the reason people skip it, and skipping it is why they end up building for nine months on a foundation of politeness.
Price is also part of the test, not a decision to make afterward. A number people accept without hesitation is a number that was too low. Some friction is the signal working.
What we do with a maybe
Most results are ambiguous, and this is where the discipline actually gets tested.
A maybe usually means the problem is real but we have the wrong shape, the wrong customer, or the wrong moment. The right response is a narrower test rather than a bigger commitment. Change one variable, run it again, and keep the kill criteria in place.
What a maybe never justifies is building the full thing to find out. That is the reasoning that turns a four week question into a nine month answer, and it always arrives dressed as decisiveness.
Why this matters more now
Building got dramatically cheaper. A first version that used to take a team two quarters is now, for a large class of software, a matter of weeks.
The instinct that follows is to skip validation, because building is now cheap enough to just try. That instinct is wrong, and it is wrong for a reason that is easy to miss. The expensive part of a wrong build was never the engineering. It was the year of distribution, support, and attention spent afterward on something the market did not want. Those costs did not fall at all.
Cheap building raises the value of good validation rather than lowering it, because the bottleneck moved. When the constraint was engineering capacity, judgment about what to build was one input among several. Now judgment is close to the only one, and the studios that treat cheap building as permission to stop thinking will find that out expensively.
The venture studio playbook covers where validation sits in the wider operating system, and how we decide between building and buying covers the branch this feeds into.
Get new essays by email.
Occasional notes on venture studios, operators, and building software that lasts. No schedule, no filler.