The most expensive mistake in product development is not bad code. It's building the right code for the wrong product.

Every year, founders spend months and tens of thousands of dollars building apps that don't find users — not because the apps were technically broken, but because the core assumption underneath them was never tested. The problem wasn't as real as it seemed. The target user wasn't who they thought. The solution people said they wanted wasn't the one they'd actually pay for.

Validation is the work you do to find out whether your assumptions are correct before you stake money and months on them. Done well, it doesn't just tell you whether to build — it tells you exactly what to build, for whom, and why.

This guide covers how to do it properly.

---

What Validation Actually Is (And What It Isn't)

Validation is not getting people to say your idea is good. Friends will tell you it's good. Potential users, when asked politely, will often say it sounds interesting. Advisors will nod encouragingly. None of that is validation.

Validation is evidence that a real problem exists, that real people experience it urgently enough to seek a solution, and that your proposed solution is something they will actually use and pay for — demonstrated through their behaviour, not their words.

The distinction matters because people are optimistic in conversations and conservative in reality. Someone who tells you "I would definitely pay for that" in an interview may not open their wallet when the product actually exists. Someone who joins a waitlist with their email may not convert to a paying customer. The closer your validation signal is to the actual purchase decision, the more reliable it is.

A useful rule of thumb from Rob Fitzpatrick's The Mom Test: never ask anyone if your idea is good. Ask about their life, their problems, and their behaviour. The facts of how they currently live and work are more reliable than any opinion they offer about a product that doesn't exist yet.

---

The Two Things You Need to Validate

Most founders think of validation as a single step. It's actually two distinct questions that need to be answered in sequence.

1. Is the problem real?

Does the problem you've identified actually exist? Do real people experience it with enough urgency that they're actively trying to solve it — not just vaguely wishing it were easier? Are they spending time, money, or significant mental energy on it right now?

This is problem validation, and it comes first. No amount of solution validation matters if the problem isn't real or isn't urgent.

2. Is your solution the right response to it?

Given that the problem is real, does your proposed solution address it in a way that people will actually adopt? Is it meaningfully better than whatever they're currently doing? Is the improvement compelling enough that they'll change their behaviour — which is always harder than it sounds?

This is solution validation, and it only makes sense once you're confident on the first question.

Founders who skip problem validation and go straight to testing their solution often discover too late that they were solving the wrong version of the problem, or a problem that wasn't urgent enough to drive behaviour change.

---

The Validation Spectrum

Not all validation signals are equal. They exist on a spectrum from low fidelity (easy to get, easy to misread) to high fidelity (harder to get, much more reliable).

Low fidelity — Conversations and surveys

Talking to potential users about their problems. Surveys that ask about pain points and current behaviour. Useful for generating hypotheses and understanding the landscape, but not sufficient on their own. People describe their problems accurately but their solutions optimistically.

Medium fidelity — Demonstrated interest

A landing page that clearly describes the product and captures emails. A waitlist with sign-ups. Social posts that generate real engagement and direct messages from people who want it. These signals show that the concept resonates and people are paying enough attention to take a small action — but a small action is not the same as a purchase decision.

High fidelity — Commitment signals

Pre-orders. Letters of intent. People who give you money — or credibly commit to giving you money — before the product exists. Paying for a manual version of the service before you've automated it. These are the signals that actually tell you something, because they require the person to go beyond enthusiasm and make a real decision.

The goal of validation is to get to high-fidelity signals as quickly as possible, using lower-fidelity methods to guide your way there.

---

Validation Methods That Actually Work

Deep Customer Interviews

The starting point for almost all good validation. Before you test any solution, spend serious time understanding the problem from the inside.

The goal of these conversations is not to pitch your idea or gauge enthusiasm. It's to understand, in concrete detail, how real people currently experience the problem you're trying to solve. What they've already tried. What's worked and what hasn't. How much time or money the problem costs them. How often they encounter it. How they'd describe it in their own words.

Aim for at least fifteen conversations with people who closely match your target user. Look for patterns: what problems come up repeatedly, in similar words, unprompted. The overlap between what different people tell you independently is your signal. One person's frustrated rant is an anecdote. Ten people saying the same thing is a finding.

Practical tips:

• Talk to people who have the problem, not people who might have it
• Ask about past behaviour, not hypothetical future behaviour ("how do you currently handle this?" not "would you use something that...")
• Follow the energy — when someone's language becomes more animated, go deeper there
• Listen for workarounds. If people have built clunky DIY solutions to a problem, the problem is real and urgent

The Landing Page Test

Before writing a line of code, build a page that describes the product clearly and asks people to take an action — join a waitlist, enter their email, express interest. Drive traffic to it through your network, relevant communities, or paid ads.

What you're measuring is not just whether people sign up. It's who signs up, where they came from, and what language they use when they reach out. Read every message from early sign-ups carefully. The words people use to describe what they want are the words you should use in your product and marketing.

A conversion rate of 10–20% on a landing page with clear, targeted traffic is a meaningful signal. Below 5% usually indicates either a positioning problem or a weaker-than-expected pull from the problem.

Keep the page honest. Describe what you're building accurately. Vague or overhyped landing pages generate inflated sign-up numbers that don't convert into real users.

The Concierge MVP

Do manually what your product would eventually automate. If you're building a tool that helps founders track investor relationships, create a spreadsheet system and offer to manage it manually for five founders, for free or for a small fee. If you're building a service that connects people to something, make the connection by hand.

This is one of the most underused validation methods and one of the most powerful. It forces you to deliver the actual value of your product — not just the concept of it — to real users. You'll immediately discover which parts of the problem are harder than you thought, which parts of your solution don't work as intended, and which aspects users actually care about versus which ones you assumed they'd care about.

The concierge also generates the most valuable artefact in early-stage product development: real users who have experienced your value, whose feedback is grounded in actual use, and who — if it worked — are candidates for your first paying customers.

Pre-Orders and Letters of Intent

Ask people to pay — or to formally commit to paying — before the product exists.

This is the highest-fidelity signal available because it requires real decision-making. When someone hands you money for something that doesn't exist yet, they are telling you, with their behaviour, that the problem is real and your proposed solution is credible enough to bet on.

Pre-orders work best for consumer products. Letters of intent — written commitments to purchase once the product is ready — work better for B2B, where purchase decisions involve procurement processes and legal review. Even an informal written commitment ("when this exists, I'm in at $X/month") is significantly more reliable than verbal enthusiasm.

Don't be afraid to ask. The discomfort of asking someone to pay early is real, but it's much less painful than spending eight months building something and then finding out the demand wasn't there.

The Smoke Test (Fake Door Test)

Offer the product as if it exists. Put a sign-up button, a "buy now" link, or a booking form on your landing page — then, when someone clicks it, explain that you're still building and ask them to join the waitlist. Measure how many people take the action that would lead to a purchase.

This tells you something no survey can: not whether someone thinks your product sounds interesting, but whether they'd actually try to get access to it. The gap between "this sounds like a good idea" and "I clicked the button to get it" is meaningful.

Use this method carefully and honestly. Don't collect payment without intending to fulfil. Be transparent with people who hit the wall that the product is coming and their interest is valuable.

---

What Counts as "Validated Enough" to Build

There's no universal threshold, but here are meaningful markers:

• You've had at least fifteen to twenty conversations with people who closely match your target user, and a consistent pattern of pain has emerged
• At least five of them have expressed genuine intent to pay — ideally backed by a pre-order, letter of intent, or some form of committed interest beyond verbal enthusiasm
• You can describe the problem clearly in the words your users use, not the words you assumed they'd use
• You know what your users are currently doing to solve this problem, and you understand why your approach is meaningfully better
• You've identified the one or two features that are truly essential and can articulate exactly why everything else can wait

If you can say yes to all of these honestly, you have enough to start building. If you can't, you'll be making costly guesses in the build that validation would have answered for free.

---

The Validation Mistakes That Cost Founders Most

Asking the wrong questions. "Would you use this?" and "Do you think this is a good idea?" are not validation questions. They produce socially optimistic answers that don't predict behaviour. Ask about current behaviour, past decisions, and what people have already tried.

Talking to the wrong people. Validating with friends, family, or people who are generally supportive is not validation. You need to talk to people who have the problem right now — ideally people you don't know and who have no reason to be kind to you.

Validating the wrong thing. Spending weeks validating that the problem exists and then assuming the solution is obvious. The problem and the solution both need to be tested. A real problem does not guarantee that your proposed solution is the right response to it.

Moving too fast from interest to build. A hundred waitlist sign-ups feels exciting. It is not a mandate to build. Sign-ups tell you the concept resonates. They don't tell you whether users will stay, pay, and refer others once the product exists. Keep the bar high.

Counting polite responses as validation. If someone says "yeah that could be useful" in a conversation, that's not validation. If someone spends forty minutes telling you about this exact problem, has tried three different workarounds, and asks you when they can get access, that's validation.

---

Validation and the Main Product Guide

If you've been through the full founder's guide to building a SaaS product, you'll recognise the customer interview and solution hypothesis sections as part of this same process. Validation isn't a separate phase — it runs through every stage of good product development, from problem definition through to post-launch iteration.

The difference is focus. The main guide gives you the full picture from idea to shipped product. This article goes deeper on the specific work of testing before you build — the phase that determines whether everything that follows is well-directed or expensive guesswork.

Done right, validation is not a delay. It's the work that makes the build faster, the product more focused, and the outcome more likely to be something real users actually want.

---

If you've validated your idea and are ready to figure out what to build and how to build it, let's talk. That's exactly where I come in.

💬 Not sure if you've validated enough to start building? Bring me what you have — your interviews, your landing page data, your early conversations — and I'll give you an honest read on where you stand. Get in touch.