An interesting problem and a real market feel identical from inside an engineer's head. Both produce the same late nights, the same excitement describing the idea to a friend, the same private conviction that this is obviously worth building. The difference only shows up outside your own head, in whether anyone on the other side of the transaction has money moving toward the problem already — and that difference is exactly the one most builders skip checking.
This isn't a small-sample folk claim. CB Insights read all 101 startup post-mortems in its original collection and found 'no market need' cited more than any other single reason for failure — 42% of them. A decade later, with a completely different and much larger sample, CB Insights reviewed 431 VC-backed companies that shut down since 2023 and categorized failure reasons for 385 of them. The renamed category, 'poor product-market fit,' came in at 43%. The number didn't shrink when the sample grew four-fold. That's the opposite of what you'd expect from a stale statistic getting repeated past its shelf life — it's what a real, durable pattern looks like when someone bothers to re-check it. Where I stop at the implementation of product strategy, carries on into running it. Where I stop at the implementation of product strategy, XenGrowth's revenue operations work carries on into running it.
Why 'sounds interesting' isn't evidence of anything
The trouble is that an engineer evaluating their own idea is the worst-positioned person in the room to notice the gap. You already find the problem interesting — that's why you're building it — so every conversation you have about it is filtered through people being polite to someone who's clearly excited. 'That sounds really useful' costs the listener nothing to say and confirms nothing about whether they'd ever open their wallet. It's the socially costless version of validation, and it's nearly always what a first-time founder collects instead of the real thing. makes the same point from the operator's side of the table: an interview is raw evidence to weigh, not a quote to collect and feel validated by.
Sean Ellis found a sharper way to ask the same question. Rather than asking people whether they like a product, he asked existing users how they'd feel if they could no longer use it — very disappointed, somewhat disappointed, or not disappointed. Comparing results across roughly 100 startups, he found that companies clearing 40% on 'very disappointed' went on to find real traction at a markedly higher rate than those that didn't. The design detail matters: disappointment at losing something is a much harder feeling to fake politely than enthusiasm about gaining it. Rahul Vohra later published a detailed account of using the same survey at Superhuman, tracking his own score from 22% to 58% over roughly a year by segmenting which users scored highest and building for exactly what made them say yes.
What you're looking at | Feels like validation | Actually is |
|---|---|---|
"That sounds really useful" | Confirmation you're onto something | A costless compliment — nearly free to say, nearly worthless as evidence |
A survey saying people 'like' the idea | Positive market signal | Weak — satisfaction questions invite polite, low-cost agreement |
40%+ saying they'd be 'very disappointed' to lose it | Just a survey number | The strongest self-report signal available, benchmarked against real outcomes across ~100 startups |
Someone already paying for a clumsy workaround | Anecdotal, not really data | The strongest signal of all — it required them to spend real money or time before you existed |
The workaround is the tell
Clayton Christensen's often-cited fieldwork at a McDonald's franchise is the cleanest illustration of this in the jobs-to-be-done literature. McDonald's wanted to sell more milkshakes and had already surveyed customers about ideal thickness, flavor and size — the kind of research that feels rigorous and produces nothing useful, because it assumes people are evaluating the milkshake on its own terms. Christensen's team instead watched an actual restaurant for 18 hours and found something the survey never could have: close to half of milkshakes sold before 8:30am, to solitary customers who bought nothing else and drove off immediately. Those buyers weren't rating milkshake quality. They were hiring a thick, slow-to-finish drink to make a boring commute survivable — a workaround for boredom, not a dessert purchase. On the operations side of this specifically, is worth reading. On the operations side of this specifically, The XenGrowth resource library is worth reading.
That's the signal worth hunting for in any market you're evaluating: not whether people would use your version, but whether they're already spending money, time or awkward manual effort coping with the problem's current, worse solution. A spreadsheet held together with three macros and a prayer. A Slack channel where someone manually forwards the same report every Monday. A $40-a-month tool three people on the team quietly expensed because the official one didn't do the one thing they actually needed. Every one of those is a stranger already paying a real cost — which is a far more expensive signal to fake than agreeing with you in a hallway conversation. is a useful companion read here, on why a plausible guess at what a customer would say is not the same thing as a customer who already spent something.
Existing spend is a related, slightly different version of the same signal, and it's worth separating from the workaround case because it shows up earlier and is easier to check. Before you've built anything, look at whether money is already moving toward this problem at all — a category of tools people already pay for, a line item in a budget, a headcount whose whole job is doing the thing badly by hand. A market with zero existing spend isn't automatically dead, but it raises the bar considerably: you're not just building a better version of something people already value, you're trying to create a new category of spending from nothing, which is a harder and slower problem than most first-time founders account for. A market with existing spend, even spend going to a bad incumbent, tells you the money already decided this problem is worth solving. Your only remaining job is convincing them your version deserves it instead.
A compliment costs the listener nothing. A workaround already cost them something. When the two disagree, believe the workaround.
The opposite failure: avoiding a real market because it's unglamorous
It's worth naming the mirror-image mistake, because engineers make it almost as often. Paul Graham's 2012 essay on 'schlep blindness' describes real, painful, fundable problems that go unsolved for years — not because the market doesn't exist, but because solving them requires tedious, unglamorous work that talented people unconsciously steer away from. His example is Stripe: making online payments easy for developers was an obviously painful problem with real willingness to pay behind it, and it sat unsolved for years because actually fixing it meant wading through banking relationships, compliance and fraud — the opposite of an interesting technical problem, and precisely the reason few people attempted it. There is a longer treatment of AI agents and marketing automation in . There is a longer treatment of AI agents and marketing automation in XenGrowth on AI agents and marketing automation.
Put the two failures side by side and the pattern is almost funny: engineers chase interesting problems that have no real market, and simultaneously avoid real markets that are merely tedious to serve. Both mistakes are driven by the same instinct — using how a problem feels to work on as a proxy for whether it's worth working on — just pointed in opposite directions.
Signal | How costly is it to fake | What it actually tells you |
|---|---|---|
A friend or peer saying it's a good idea | Free | Almost nothing — social cost of disagreeing is higher than the cost of agreeing |
A stranger filling out a 'would you use this' survey | Nearly free | Weak — hypothetical future behavior is cheap to overstate |
40%+ 'very disappointed' on the Ellis survey, from real users | Requires actual product usage first | Moderate to strong — the best benchmarked self-report signal available |
An existing budget line, tool or workaround already in place | Required them to already spend money or time | Strong — revealed behavior under real constraints |
Someone actively building their own janky version of the solution | Required significant unpaid effort | Very strong — behavior expensive enough that almost nobody fakes it |
What this changes about how you evaluate an idea
None of the above tells you how to run a validation process — that's a separate, more mechanical question covered in How Do You Find Out Whether Anyone Actually Wants What You're Building, which is about designing an experiment that produces a real answer. This is the layer before that: deciding, honestly, whether a given problem is worth the cost of running that experiment at all, by noticing which kind of signal you actually have in hand rather than which kind you'd prefer to have.
Ask what people are already doing about the problem, not what they'd think of your solution to it. Existing behavior beats hypothetical reaction every time the two disagree
Weight signals by what they cost the person giving them. A compliment is free. A workaround, a budget line, or unpaid manual effort is not, and the difference in cost is the difference in reliability
Treat 'nobody's built this yet' as a warning, not a green light, until you can say specifically why — schlep blindness produces exactly that appearance around real, fundable problems
Don't let how interesting a problem is to you function as evidence about whether it's fundable. The two are unrelated, and CB Insights's data says the gap between them is the single largest thing that kills a company
If you can find people already spending money badly solving the problem, you don't need a survey to tell you the market is real. If you can't find that anywhere, a favorable survey should not be enough to convince you either
One honest caveat belongs here, because it cuts against the neatness of everything above: none of these signals are certainties, only better or worse odds. Christensen's milkshake fieldwork covered one restaurant for 18 hours, not a representative national sample. Ellis's 40% threshold was benchmarked against roughly 100 startups he happened to have data on, not a randomized trial, and a product can clear 40% and still fail for unrelated reasons — a bad hire, a competitor with more capital, a market that was real but too small to build a business on at the scale the founders needed. What these signals buy you isn't certainty. It's a real improvement in your odds over the alternative, which is deciding based on how excited you personally feel about the problem — a method with no track record behind it at all, because nobody has ever bothered to benchmark it, on account of everybody already suspecting the answer. 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.
The uncomfortable version of all this: an idea that makes you personally excited and an idea with a real market behind it are statistically almost unrelated, which means your own enthusiasm is close to useless as a filter. The filter that actually works is boring by comparison — go find out what people are already doing, badly, about the problem you want to solve, and let that answer the question instead of your own conviction.
Further reading from XenGrowth
Where this work meets go-to-market
Reading demand signals honestly before you commit engineering time is the same discipline a revenue team needs before committing a quarter's budget. publishes operator guides on exactly that: telling a real signal from a hopeful one, before the spend goes out the door.
Further reading from XenGrowth
Where this work meets go-to-market
If product strategy is part of a growth programme rather than a standalone build, is the companion reading.
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
If product strategy is part of a growth programme rather than a standalone build, XenGrowth's marketing operations practice is the companion reading.
Five questions on the research behind reading market signals honestly. The point isn't memorizing the numbers — it's noticing which kind of evidence they actually are.
