Customer validation

What is customer validation?

Customer validation is the step where you stop trusting your own conviction and go looking for evidence that strangers will part with money or time for what you plan to build. It sits between having an idea and committing months of engineering to it.

The core discipline is separating what people say from what they do. Almost everyone is polite about a founder's idea, especially in a friendly conversation, so enthusiasm on a call is close to worthless as evidence. Validation means designing small tests where the customer has to give up something real: a deposit, a calendar slot, access to their data, a signature.

It is also not a single milestone you clear once. You validate the problem, then the willingness to pay, then the specific solution, then the price. Each answer narrows the next question, and skipping a stage usually means discovering the gap much later at much greater cost.

What counts as a real signal

Signal	Strength	Why
"That sounds useful"	Weak	Costs the person nothing to say
Email signup on a landing page	Moderate	Shows interest, not willingness to pay
Giving you an hour or their data	Moderate	Real cost in time and trust
Prepayment, deposit, or paid pilot	Strong	Money is the least ambiguous signal available
Repeat use with no prompting	Strong	Proves the value survives first-week novelty

Why customer validation matters for startups

The most expensive thing a small team can do is build the wrong thing well. Six months of clean architecture for a product nobody wants costs the same as six months spent on something people are waiting for, and you only find out at the end.

Validation changes what you commit to next week. Instead of a build plan, you run a test that could plausibly fail. That framing matters: if no realistic outcome of your test would stop you from building, you are not validating, you are collecting reassurance. Done properly, validation is also how you avoid a painful pivot later, or at least reach it while it is still cheap.

Customer validation in practice

Say you want to build invoicing software for independent contractors. Rather than starting with code, you find 40 contractors in trade forums and ask for 20 minutes each about how they bill clients today. Twelve agree, and a pattern emerges: chasing late payments hurts far more than creating invoices.

You put up a one-page site describing an automated payment chaser and offer lifetime early access for $99. Two people pay within a week, and three more ask when it launches. That is not a business yet, but it is enough to justify building a narrow first version, and it told you to build the chasing feature rather than the invoice editor you originally imagined.

How to validate on a small budget

Start with conversations, not surveys. Ask about the last time the problem occurred, what the person did about it, and what it cost them. Past behavior is factual; future intentions are speculation. Avoid describing your solution until the end, since people will politely agree with whatever you pitch.

Then design one test with a real cost attached: a preorder, a paid pilot, a concierge version where you do the work manually for three customers. Write down in advance what result would make you stop. If you cannot state a failure condition, redesign the test before you run it.

Common mistakes

• Asking leading questions. "Would you use a tool that does X?" invites a yes. Ask what they do now and what it costs them.
• Validating with friends. People who like you cannot evaluate your idea. Talk to strangers who have the problem.
• Counting signups as demand. An email address is cheap to give. Charge something, even a small amount, before believing the interest.
• Building the full product to test it. The test should be cheaper than the thing you are testing, otherwise you have skipped validation entirely.
• Stopping after the first yes. One enthusiastic buyer is an anecdote. Look for a repeating pattern across several independent conversations.

Validation is the discipline underneath the lean startup approach and the reason a minimum viable product exists at all: both are ways of buying evidence cheaply. Keep going after launch through a running customer feedback loop, because early validation gets you a first version, while product-market fit is the longer proof that the demand is real and repeatable.