Most engineers who set out to build a product do the thing they're already good at first: they build. A working prototype exists inside a few weeks, a landing page goes up, maybe a demo video gets recorded, and none of it is backed by evidence that a stranger — someone who doesn't know the founder and has no reason to be kind — actually wants it. This isn't a discipline problem. It's a sequencing problem. Validation is supposed to happen before the expensive part, and for most first-time founders it happens after, if it happens at all.
Validation, done properly, isn't a survey and it isn't a gut check from people who already like you. It's a specific set of techniques for finding out, before the months get spent, whether a real buyer will change their behavior — pay money, switch tools, give up a workaround they've already built — for what you're proposing. The distribution and pricing decisions that come after that answer is settled are exactly the kind of go-to-market mechanics writes about for teams already past the founding stage, but none of it matters if the founding answer was never actually tested. approaches product management from the operator's side, which complements the engineering view here. XenGrowth's growth engineering practice approaches product management from the operator's side, which complements the engineering view here.
Why “would you use this?” tells you nothing
Ask a friend, a former colleague, or someone friendly at a conference whether they'd use your product, and you'll get a yes almost every time — not because they will, but because saying no to someone's earnest new idea, to their face, feels rude. This has a name: social-desirability bias, the well-documented tendency for survey and interview respondents to shade their answers toward whatever they believe will be received favorably, understating unpopular positions and overstating agreeable ones.
It's one of the most reliable distortions in survey methodology, and it's strongest in exactly the setting where most first-time founders do their 'research': a friendly conversation, a plausible-sounding pitch, and a direct question that's really asking for reassurance rather than information. The person you're asking knows what answer would make you happy, and giving you that answer costs them nothing. That asymmetry — free to say yes, awkward to say no — is the whole mechanism, and no amount of asking more people fixes it, because the bias doesn't average out. It's systematic, not random.
The three kinds of feedback that lie to you
Rob Fitzpatrick's book The Mom Test is built around a blunt premise: even your mother will lie to you to protect your feelings, so any question that lets people be nice instead of honest is a bad question. Fitzpatrick names three recurring shapes this takes, and once you've seen them named you notice all three inside almost every founder pitch deck's 'validation' slide. There is a longer treatment of the operations side of this in . There is a longer treatment of the operations side of this in The XenGrowth resource library.
Bad data type | What it sounds like | Why it's worthless |
|---|---|---|
Compliments | “That's such a great idea.” / “I love this.” | Praise costs the speaker nothing and satisfies the social obligation of the conversation without any commitment attached |
Hypotheticals | “I'd definitely use something like that.” | A promise about imagined future behavior, made by someone with nothing at stake and no memory of having said it next week |
Wishlists | “It'd be great if it also did X, Y and Z.” | An eager list of features from someone who has demonstrated zero intention of paying for any of them, which tends to expand your scope instead of confirming your demand |
The fix Fitzpatrick proposes is to stop asking about the future and start asking about the past: what have you actually done about this problem already, what did you try, what did it cost you, when did you last deal with it. Past behavior is a fact you can verify. A hypothetical is a courtesy.
Steve Blank's actual method, and where founders skip ahead
Steve Blank's customer development model, laid out in The Four Steps to the Epiphany, splits the early life of a startup into four sequential stages: customer discovery, customer validation, customer creation, and company building. The distinction that matters most for an engineer building their first product is the gap between the first two.
Customer discovery — testing whether the problem you think exists actually matters to the people you think have it, mostly through direct conversation with the caveat that conversation alone is discovery, not proof
Customer validation — proving, with a repeatable and at least somewhat scalable sales process and real paying customers, that a market exists for your specific solution, not just that the problem is real
Customer creation — driving demand at scale once the sales process from validation is known to work
Company building — shifting the organization from a learning-and-discovery structure to one built for execution
Blank's own framing is explicit that this takes several passes — 'it will take several iterations of each of the four steps until you get it right,' as the model assumes from the start. Most engineer-founders run something like a compressed, informal version of discovery: a handful of conversations that confirm the problem is annoying. Then they skip straight to building, without ever running validation — without ever forcing themselves to find a repeatable way to get a stranger to pay. Discovery answers 'is this problem real.' Validation answers 'will people pay me, specifically, to solve it,' and those are different questions with different evidence bars. has more on how established go-to-market teams structure this kind of staged testing once a company is past the founding question.
Build-measure-learn is not “build something small and see”
Eric Ries's Lean Startup popularized the build-measure-learn loop, and the most common misreading of it is treating 'build' as an instruction to build a smaller version of the eventual product. That's not what an MVP is for in Ries's own framing. 'Validated learning' — his term for the actual unit of progress — comes from designing the smallest, fastest, cheapest experiment that tests one specific assumption you're uncertain about, and very often that experiment isn't a product at all. works through AI agents and marketing automation in more operational detail. XenGrowth on AI agents and marketing automation works through AI agents and marketing automation in more operational detail.
A landing page describing the product, with a real payment button on it, tests more about demand than a working prototype does, because a prototype still asks people to imagine paying while a payment button asks them to actually pay. The loop is build (the experiment) → measure (what people actually did) → learn (whether the assumption held), repeated as many times as it takes, and the entire point is to make each lap of that loop as cheap as possible so you can afford to be wrong several times before you've spent real money.
What actual validation looks like
The pattern across Blank's validation stage, Ries's build-measure-learn loop, and Fitzpatrick's Mom Test is the same underlying test: does this cost the other person something real, before you've built anything, in one of the currencies that actually matter — their time, their reputation, or their money. A conversation costs almost nothing. A deposit costs money. A signed letter of intent costs reputation, because the signer is putting their name behind a commitment inside their own organization.
What people usually do | Why it fails as a signal | A stronger version |
|---|---|---|
Ask friends “would you use this?” | Social-desirability bias makes yes the default polite answer regardless of real intent | Ask what they've already tried, spent, or built to solve the problem themselves |
Collect email signups on a ‘notify me’ page | An email address costs almost nothing to hand over | Put a real payment or deposit button on the same page and count actual attempts to pay |
Run a survey asking how interested people are | ‘Interesting’ is a compliment wearing a numeric disguise | Ask a buyer to sign a non-binding letter of intent with a specific price attached |
Show a working demo and ask for feedback | Feedback on a demo is still hypothetical until money or a real workflow change is on the line | Ask the person to actually replace their current workaround with your demo for one real task and watch what breaks |
None of this requires the finished product. It requires a specific ask that a real prospect can say no to, and a founder willing to hear that no early, when it's still cheap information instead of a symptom discovered six months into a product nobody's buying.
Fitzpatrick's own rule of thumb is close to this: if a conversation with a prospective customer never makes you a little nervous, you're probably asking questions that are safe for both of you rather than questions that produce a real answer.
The trap that's specific to engineers
Engineers default to building because building is the skill they trust, and a working system feels like progress in a way that a spreadsheet of interview notes doesn't. That instinct is a real asset later — it's exactly why senior engineers are valuable once a market is proven — but at the validation stage it's a liability, because it lets you substitute 'I built something' for 'someone wants something,' and only one of those is evidence. Paid demand tests are one of the fastest ways to check that substitution before it compounds, which is part of why spends so much time on small, cheap tests before a team commits real budget to a channel. works through AI search, GEO and discovery in more operational detail. XenGrowth on AI search, GEO and discovery works through AI search, GEO and discovery in more operational detail.
Sunk cost makes this worse the longer it goes unchecked. A founder who spent eight weeks writing code is far less willing to hear that nobody wants it than a founder who spent two days building a landing page and a payment link. Cheap validation isn't just faster — it's the version of the mistake you can actually afford to make and recover from.
A cheap way to test price, not just interest
A landing page with a real, working checkout — even for a product that doesn't fully exist yet, sometimes called a pre-sale or a 'fake door' test — answers a question that interviews never can: what price, specifically, makes a real stranger take out their card. Interest is cheap at every price point; a completed purchase is not, and the price at which purchases stop is itself useful information about what you're actually building. Once real transactions start happening, the operational side of tracking and attributing them is its own discipline, one covers for teams scaling past this first signal.
What to actually do this week
Write down the specific, falsifiable claim you're testing — not “people want a better X” but “people currently spend money or hours on Y and would pay $Z to stop”
Find ten people who've actually experienced the problem recently, not people who like you, and ask what they've done about it so far
Build the cheapest artifact that lets a stranger commit something real — a landing page with a payment button, a deposit form, a one-page letter of intent — and put a real number on it
Count actions, not opinions: completed payments, signed letters, calendar bookings for a paid pilot, not likes or ‘very interested’ replies
If the honest answer after this is no, treat that as the fast, cheap version of the outcome you were going to hit eventually anyway, and change the plan before the expensive version arrives
None of this guarantees success. Plenty of ideas that pass every test above still fail for reasons validation can't catch — timing, execution, a competitor moving faster. What this process does is cheaper and more honest than the alternative, which is spending months building on the strength of a friend's compliment and finding out the hard way that a compliment was never evidence.
Where this work meets go-to-market
Once demand is real and confirmed, the questions change to distribution, pricing and repeatable acquisition — the exact territory operates in for teams that have already cleared the bar this post is about.
Further reading from XenGrowth
Further reading from XenGrowth
Where this work meets go-to-market
writes for the teams who have to run product management day to day.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
XenGrowth's growth engineering practice writes for the teams who have to run product management day to day.
Five questions on what counts as real evidence that someone wants what you're building, versus what only feels like it.
