Eight conversations in, you've heard the words "that's totally a problem" from eight different people, and you're already imagining what to name the company. The nods feel like data. They're not the data that matters.
Most validation conversations measure the wrong thing. They capture whether a problem exists, which is almost never the useful question. The useful question is whether the problem is painful enough that someone will actually pay to have it gone, and that answer shows up not in the conversation but before it, in what people have already done.
The workaround is the signal.
What Customer Interviews Actually Measure
Customer interviews are excellent at one thing: confirming that a problem is recognizable. If you describe a struggle and eight people nod, you've learned that eight people can recognize that struggle. You haven't learned that they want to fix it, that they'd pay to fix it, or that the problem is severe enough to have interrupted their current behavior at any point in the past.
"That's totally a problem" is a very low bar. Almost everything qualifies as a problem in some loose sense. The question is whether the problem is acute enough that someone has already done something about it.
The three kinds of problems founders encounter
| Problem type | What it sounds like | What they've already done |
|---|---|---|
| Acute | Specific frustration, described with details | A workaround: spreadsheet, Zapier flow, hired VA, internal tool |
| Latent | "Yeah, it's annoying" | "Been meaning to sort this out" — nothing built |
| Phantom | Enthusiastic agreement in the abstract | Nothing. Ever. |
Acute problems are worth building for. Latent ones might eventually be. Phantom ones, which generate the most interview agreement, are the tarpits that absorb six months of runway.
⚠️ The tarpit signature: An idea that consistently generates excited nods but produces no paying customers is almost certainly a phantom problem. The nods measure recognition, not urgency. Tarpits are populated entirely by problems nobody bothered to solve their own workaround for.
The Workaround Test
The single most useful question in any customer discovery conversation: "What do you do about this today?"
Not "would you use something that solves this?" (which invites the person to imagine a hypothetical and agree with it). Not "how much would you pay?" (which skips the question of whether they'd pay at all). What they do today is observable behavior, and it's the most honest answer available because it's not a prediction.
What each answer signals
The workaround they're proud of. They built something: a Notion template, an Airtable database, a script that runs on Friday afternoon, a spreadsheet with formulas they've spent real time on. This person experienced the problem acutely enough to construct a solution, kept using their half-measure because nothing better existed, and will immediately understand what you're building. That's your early adopter.
The workaround they're embarrassed about. They describe how they handle it and wince slightly: "it's a bit of a mess, honestly." An embarrassed workaround means they know the problem is real, they know their fix is inadequate, and they've accepted the friction because they had no better option. They'll buy something that's meaningfully better than their mess.
The shrug. "I just deal with it." Not a system, just ongoing tolerance. Tolerance is not urgency, and a founder who hears this across most conversations is standing at the entrance of a very populated tarpit.
"I've been meaning to do something about this." This sentence is the kindest possible way someone can tell you the problem hasn't earned ten minutes of their own time. They've been meaning to solve it for months or years, and the absence of any action is the data.
💡 The workaround test in one sentence: If someone has built something to work around the problem (even something terrible), the problem is real enough to build for. If they haven't, the burden of proof is on you to explain why they'd pay to solve something they've never been motivated to fix themselves.
Reading the Conversation Differently
Most founders come away from validation conversations with a count: eight out of ten said it was a real problem. The count is nearly useless. What matters is the texture of those eight responses.
The reframe is simple: don't count agreement. Map existing behavior.
| What you heard | What it actually signals | What to do next |
|---|---|---|
| "That's exactly the problem I have" | Problem is recognizable | Ask: "What do you do about it today?" |
| "We built an internal tool for this" | Acute pain, validated willingness to invest | Ask: why internal vs. buying something? |
| "We use [enterprise tool] for this" | Real problem, existing market | Ask: what does the tool not do? |
| "We hired someone to handle it" | Acute pain, budget already allocated elsewhere | Ask: what would change if they didn't have to? |
| "I've been meaning to sort this out" | Low severity | Probe for a more specific friction, or move on |
| "Yeah, it's annoying sometimes" | Phantom problem | Move on |
The follow-up question that changes everything
After someone describes their workaround, ask: "And if that workaround disappeared tomorrow, what would you do?"
A person with an acute problem will feel some version of alarm: "Oh, that would be painful. We'd probably have to hire someone, or spend days doing it manually." A person sitting on a latent problem will shrug. "Honestly, I'd probably just figure something out."
The second answer tells you the problem isn't severe enough to anchor a business, at least not for this person, not yet. Five versions of the second answer in a row is a clear signal to move on or find a sharper problem within the same space.
📋 Quick audit before you build: List what each of your last ten interview subjects does about the problem today. If the majority have no workaround, you haven't validated a problem; you've found a topic people are willing to discuss. There's a real difference between those two things, and it's worth knowing before month three.
The Founders Who Validate Fast
There's a pattern among founders who build things that sell quickly: they didn't discover a problem through research. They ran into it themselves, built a workaround for their own use, then found out other people had the same workaround, just worse, or more expensive, or more time-consuming.
This is the core of what Paul Graham describes as "live in the future and notice what's missing." The problem you personally felt urgent enough to hack around is the problem urgent enough to build for. The corollary is harder to hear: problems you noticed but never hacked around didn't make it past your own threshold, let alone anyone else's.
Why this pattern produces better validation than interviews
When you've built a workaround yourself, you already know what the ideal solution looks like, how often the problem surfaces, and what someone would give up to have it solved. You're not trying to imagine these things from interview notes; you lived them. Your first five customers are people whose messy workaround looks like yours.
When founders start with research instead, the risk is building a precise solution to a problem nobody was urgently trying to solve. The research produces a real problem, just not a severe one, and the product that follows is elegant and empty.
The conversations worth having are with people who've already tried to solve the problem independently. Those conversations shift from validation to design; you're not asking if the problem is real, you're asking what their workaround couldn't do that yours should.
FAQ
How many workaround conversations do I need before building?
There's no universal number, but five to ten people describing independent workarounds for the same underlying friction is meaningful. The workarounds don't need to be identical; they need to address the same core problem in ways that reveal urgency, not just recognition. Five people with different messy spreadsheets pointing at the same gap is a stronger signal than fifty people who agreed the gap exists.
What if nobody has a workaround but the problem seems real?
That's important data. Either the problem isn't frequent enough to merit a workaround, it isn't painful enough, or people have accepted it as a fixed cost of doing something else. None of these is necessarily a dead end, but they change what you need to validate next. A problem without workarounds can still have a market, but you need a much clearer theory of why people would change behavior to pay you, when they've never been motivated to change behavior for free.
What's the difference between a workaround and just tolerating the problem?
Intention. A workaround is active: someone built or organized something specifically to reduce the friction. Tolerance is passive: they're aware of the friction and coexist with it. Both can be real problems, but workarounds signal a much higher severity threshold. The person who spent three hours building a spreadsheet to handle something has already revealed more about their willingness to invest than the person who shrugs and says it's annoying.
Are tarpit ideas avoidable before building?
Often yes, with one research step: before customer interviews, search for prior companies that tried the same idea. A graveyard of Y Combinator alumni, shuttered IndieHackers projects, and "we're shutting down" blog posts around a particular problem is strong evidence of a tarpit. It doesn't mean the problem is unsolvable; it means the obvious approach failed repeatedly, and you need a non-obvious angle or a market timing argument to justify trying again.
Can the workaround test replace actually charging people?
No, it complements charging. The workaround test validates that the problem is real and severe. Charging from day one validates that your solution is better than the workaround. You want both signals. The workaround test tells you whether to build at all; charging tells you whether what you built closes the gap. Skipping the workaround test and going straight to pre-selling means you might get ten customers without ever understanding whether the problem was widespread or why it is or isn't.
The conversations that feel like validation — enthusiastic, specific, "you're solving exactly the right thing" — are often the least useful. The signal was already there before you showed up: in the spreadsheet someone built for themselves two years ago, the assistant they hired for one specific task, the Zapier workflow that breaks once a month and gets fixed again. Find the workarounds. Build the thing that makes them unnecessary.