Validate Before You Build

When building is cheap, the most expensive mistake is building the wrong thing. Validation tells you whether your thesis holds before you spend months on it. You are gathering evidence, not encouragement, and the best evidence is what people do rather than what they say.

Ask About the Past, Not the Future

Most customer conversations fail because the founder asks the wrong questions. "Would you use a product that does this?" and "How much would you pay?" feel useful, but they invite people to imagine a future and be polite about it. People predict their own behaviour badly, and they are good at being kind to someone who is clearly excited. Psychologists call this the intention–behaviour gap. In a 2016 review, Paschal Sheeran and Thomas Webb report that experiments producing a medium-to-large change in people's intentions led to only a small-to-medium change in what they actually did, and that the gap comes mainly from people who intend to act and then do not.

Rob Fitzpatrick's book The Mom Test is the standard reference. Its three rules are to talk about their life instead of your idea, to ask about specifics in the past instead of opinions about the future, and to talk less and listen more. The name comes from asking your mother whether your business idea is good. She will say yes because she loves you, so you need questions that even she could not mislead you with.

In practice, that means questions like these:

• "When was the last time this happened? Walk me through it."
• "What did you do about it?"
• "What have you tried to fix it? Why did that not work?"
• "How much time or money does this cost you in a typical month?"
• "Who else is involved when this comes up?"

Specific stories show how much a problem matters. If someone cannot remember the last time it happened, or has never tried to solve it, it is probably not a priority for them, however enthusiastically they agree that it is a problem.

Don't pitch during these conversations. Once you describe your solution, the talk turns to your idea and people start being supportive. Save the pitch for later, or for a different conversation.

Find 20 to 30 People

You need enough conversations to see patterns rather than anecdotes. Around 20 to 30 people in your target segment is usually enough to tell whether a problem is real and widespread, and to notice when answers start repeating. Professional researchers work at a similar scale: in voice-of-the-customer research as described by MIT's John Hauser and colleagues, a typical study interviews between 10 and 30 customers one on one, for about an hour each. If you are still hearing new things at 30, your segment may be too broad.

Finding them is easier than it sounds.

• Start with your own network: former colleagues, clients and people you met at industry events. Ask each one for two more names.
• Go where they already gather, such as industry forums, professional groups, trade events, online communities and local meetups.
• Send short, honest messages. Say you are researching a specific problem and not selling anything, and ask for twenty minutes. Many people enjoy talking about their work.
• Be narrow. "Operations leads at independent logistics companies" will produce better conversations than "small business owners."

Take notes in the same format for every conversation: who they are, the problem in their words, what they do today, what it costs and anything that surprised you. Consistent notes make patterns easier to spot.

Signals That Count

Every conversation produces some encouragement, and most of it means nothing. What you want to know is whether the person gave up something real.

Weak signals	Strong signals
"That's a great idea."	They pay, place a deposit or sign a pre-order
"I would definitely use that."	They sign a letter of intent with specific terms
"Let me know when it launches."	They book a follow-up and bring a colleague
Likes, follows and waitlist sign-ups	They introduce you to their boss or the budget holder
General agreement that the problem exists	They give you their real data or let you watch them work

Fitzpatrick calls compliments "the fool's gold of customer learning: shiny, distracting, and entirely worthless". What he looks for instead is commitment, meaning the person gives up something they value, such as time, reputation or money. Money is the clearest signal, but time and introductions also count, because they cost the person something.

Try pre-sales earlier than feels comfortable. A discounted early version, a paid pilot or a founding-customer agreement tests whether the pain is real enough to open a budget. A refusal tells you something, and the reason behind it tells you more.

Letters of intent are weaker than payment but still useful, especially with larger companies whose purchasing takes time. Make them specific: what they would buy, at roughly what price, on what timeline and under what conditions. A vague letter of support is not much better than a compliment.

Test Demand Without a Product

You can learn a lot before writing any real code.

Smoke tests check whether people will take a step towards a product that does not yet exist. A simple landing page that describes the offer and asks for something concrete, such as booking a call, joining a paid waitlist or requesting pricing, shows whether your message lands with the people you are targeting. Measure actions rather than page views, and be honest with visitors about what stage the product is at. Buffer's founder Joel Gascoigne tested his idea this way. He put up a two-page site that explained the product, then inserted a pricing page before the email sign-up to see which plan people would pick and whether they would take the extra step. Enough did that he built it, and he had a first paying customer within four days of launch.

Concierge MVPs deliver the result by hand. Instead of building software, you do the work yourself for a few customers, using spreadsheets, existing tools and your own time. You learn exactly what the job involves and which parts customers care about. It is slow and does not scale, and that is deliberate.

Wizard-of-Oz MVPs look automated to the customer but are run manually behind the scenes. They test whether customers value the experience before you invest in automating it. Zappos began this way: Nick Swinmurn photographed the stock at a shoe shop in Sunnyvale, put the photos online, and told the owner, "if people buy them, I'll buy them from you at full price."

Eric Ries, who popularised the term, defined a minimum viable product as the version of a product that lets you collect "the maximum amount of validated learning about customers with the least effort." By that definition, a spreadsheet and your own time often qualify.

Paul Graham's essay "Do Things That Don't Scale" makes the case for early manual work: recruiting users by hand, giving early users "an insanely great experience" even with an incomplete product, and doing by hand what you plan to automate later. The manual phase is where you learn what the product should be.

AI tools make it tempting to skip these steps, because a working prototype is only days away. Build the prototype if it helps you have better conversations, but do not mistake it for validation. A working demo proves you can build. It says nothing about whether anyone will pay. In CB Insights' study of 431 venture-backed shutdowns since 2023, 43% cited poor product-market fit (2026).

Decide What to Build First

After your conversations and tests, you should be able to answer a few questions clearly. Who has the problem most acutely? What single job do they most want done? What have your strongest-signal customers specifically asked for?

Build the smallest product that does that one job for those people well enough that they would be upset to lose it. Leave out anything that came up only once, anything requested by people who gave you weak signals, and anything you added because it seemed impressive.

A simple filter helps:

1. Must have: the job does not get done without it.
2. Should have: customers asked for it repeatedly, but they could start without it.
3. Later: everything else.

Ship the first list only. At AW3 we scope first versions this way so they can go out in days or weeks, then grow from real usage rather than guesses. Whatever you build, put it in front of your strongest-signal customers first and keep talking to them. Validation does not stop at launch; it becomes the way you run the product.