The founder books time with me because they can't get traction or more specifically they don't know how to. They want to talk about pricing, or sales process, or what's wrong with the cold-email cadence, or whether they should be hiring a VP of marketing. Those are the surface symptoms. They've come to me thinking the diagnosis is somewhere in the surface symptoms.
I almost never start there.
One question
I ask one question. What problem are you solving and who are you solving it for? And then I let them talk for as long as they want.
The first thirty seconds of that answer is the diagnostic. Most founders, when you ask that question, don't describe a problem. They describe their solution and then back-derive a problem from it. We're solving the lack of [the thing our product does] for [the audience our product targets].
A person doing a thing they don't want to do
Real problems don't sound like that. Real problems sound like a person, doing a thing they don't want to do, in a moment they remember vividly. The data analyst who exports the same dashboard to a CSV every Monday, cleans it up by hand in a spreadsheet, and re-uploads it somewhere else, because the two systems don't talk and the integration the vendor promised has been a roadmap item for a year. The backend engineer SSH-ing into a production server at eleven at night to restart a service by hand, because the deploy reported success and wasn't, and nothing pages anyone when that happens. The support lead who keeps a private doc of which bugs are actually on fire and the one-line workarounds for each, because the ticketing system sorts by date instead of by pain, so every new hire rebuilds that triage knowledge from scratch. Those are problems.
The dig-deeper exercise
Most founders coming to me for help with traction don't have a problem like that articulated. They have a category of users, a hypothesis about what those users want, and a product they've already built. The problem-shaped hole at the center of all that work is the thing they need to find before any tactical fix matters.
So I run an exercise, and it isn't a clever one — it's the Five Whys, the thing off the Toyota assembly line, except I point it at the founder's problem statement instead of a defect on the line. Take the sentence you just gave me — we're solving the lack of [our thing] for [our audience] — and ask why that's a problem. Then ask why about the answer. Then again. Five times, give or take; you're not counting, you're drilling.
One of two things happens. Either each why drops you somewhere more specific and more human than the last:
Why doesn't the data come out clean? Because the export was built for the accounting team, not the analysts. Why does that matter? Because the analyst can't trust the numbers without re-checking them by hand. Why does that cost anything? Because she spends Monday morning doing that instead of the analysis someone actually asked her for.
And there it is — a person, a morning, a thing she doesn't want to be doing. That's a problem you can build against.
Or — the more common outcome — the whys run out of road in two steps. Why is that a problem? Because people would use the product. Why? Because it does the thing. That's not a chain, it's a circle. If your problem statement can't survive three honest whys, you don't have a problem yet — you have a product looking for one.
There's a second cut to make while you're down there, and it's the one founders skip — which is exactly why I make them answer who are you solving it for? up front. Whose pain did you just drill into, and is that the same person who will pay for it? Users aren't always customers; customers aren't always users. The analyst feeling it on Monday morning doesn't sign the contract — her VP of Data does, and the VP's pain isn't my morning is annoying, it's I can't tell the board whether our numbers are right. Same root, two completely different sentences — and if you build and message for the user when the customer holds the budget, or the reverse, you get warm nods in every demo and a signature in none of them. The exercise isn't finished when you've found a pain. It's finished when you know whose pain it is, what it costs that person, and whether that person is the one who can say yes.
I don't say that to be brutal. I say it because solving the wrong problem for the wrong customer is the most expensive friend a startup can have. They give you enough hope to keep building. They give you anecdotal validation. They give you a logo. They never give you the kind of revenue or referral velocity that would tell a board, we have a thing. You spend eighteen months in a slow conversation that won't end and won't grow.
The shift, when it lands, isn't dramatic. It's a founder going home and rewriting their messaging — not because the old messaging was bad, but because they suddenly know what they're actually selling. It's reorienting an outbound list. It's hearing a customer call differently. It's a quieter, more specific way of describing what they do.
Customer discovery: the rules
Customer discovery is the bridge to all of that. Not a survey. A real conversation. The rules I tell founders are simple:
- Ask about the last time the problem happened, not whether it happens.
- Ask what they did instead of using anything.
- Ask who else was involved and what it cost them.
- Don't say what your product does.
- Don't say what you wish were true.
- Listen for the moment they passionately describe a frustration they had.
The founders I see make it past month eighteen are not the ones with the slickest decks or the most disciplined sales process. They're the ones who, before they hired a VP of marketing or rewrote pricing or cold-emailed harder, sat with the question what problem am I solving? until the answer was a person doing a thing.
The traction problem under the traction problem is almost always that the problem under the problem hasn't been found yet.