In 2003, if you had asked frequent travelers whether they had a problem finding short-term accommodation when visiting a city, most would have said no. Hotels exist. Problem solved. Reid Hoffman wasn’t even thinking about that space. Travis Kalanick wasn’t yet annoyed enough about taxis to do anything about it. And two guys in San Francisco hadn’t yet inflated an air mattress to pay their rent.
But the friction was already there. People were couch-surfing on Couchsurfing.com, posting on Craigslist for sublets, and wrangling with bed-and-breakfasts that required phone calls during business hours. Nobody filed a complaint. Nobody wrote a report. The discomfort was diffuse, normalized, and therefore invisible to anyone running a proper market research operation.
This is the pattern that keeps repeating. The most consequential companies tend to emerge from problems that weren’t officially on anyone’s list.
Why Market Research Finds Yesterday’s Problems
The standard playbook says: find a pain point, validate it with customers, build a solution. This logic is sound for incremental improvements. It is nearly useless for identifying genuinely new categories.
Customers are good at describing what frustrates them inside a system they already understand. They are not good at articulating needs that require a system that doesn’t yet exist. In the early 2000s, nobody told researchers they needed a way to carry their entire music library in their pocket, because they had no framework for imagining that was even possible. They complained about CD cases being bulky and skipping on the treadmill. The iPod wasn’t a response to a stated need. It was a response to a structural friction that users had accepted as permanent.
The surveys come back clean. The focus groups produce nothing alarming. And so the problem goes unaddressed, which is exactly the condition that makes it valuable to the founder who spots it anyway.
The Difference Between Latent Demand and No Demand
There is a meaningful distinction between a problem that doesn’t exist and a problem that hasn’t been articulated. Founders who build lasting companies are almost always solving the second kind, even when everyone around them insists it’s the first.
When Stripe launched in 2010, accepting payments online was already possible. PayPal existed. Google Checkout existed. The developer community was not, on paper, clamoring for another payments company. But Patrick and John Collison had noticed something in the texture of how developers talked about building on top of existing payment infrastructure. The frustration wasn’t about the concept of online payments. It was about the seven-step integration process, the obtuse documentation, the waiting weeks for merchant accounts. Nobody had labeled this as a crisis. It was just considered the cost of doing business online.
Stripe built for that unnamed friction. The result was a company now valued in the tens of billions, built on a problem that most industry observers would have told you was already solved.
This is where outsider founders tend to have a genuine edge. They don’t know enough to accept the existing friction as normal. They see the workaround and ask why the workaround is necessary.
How Founders Actually Find These Problems
It is not through formal research, usually. The founders who find pre-articulated problems tend to have a few things in common.
First, they are often direct participants in the friction. Airbnb’s founders didn’t study the accommodation market. They needed money for rent and found a workaround that happened to work. That lived experience gave them a model of the problem that no survey could have produced.
Second, they pay close attention to workarounds. When people are MacGyvering solutions out of tools not designed for the job, that is almost always a signal that the designed-for-the-job tool doesn’t exist yet. Spreadsheets being used as CRM systems. Email threads being used as project management. Slack channels being used as customer support queues. Each of these workarounds is a map of unmet need.
Third, they are willing to be early enough to look wrong. A problem that doesn’t officially exist yet will attract skepticism, because there is no established category for investors and journalists to file it under. The rejection letter is data, and founders who build for latent needs collect a lot of it before the market catches up to what they already knew.
The Risk Is Real, But It’s Specific
Building for a problem no one has named is not the same as being reckless. The failure mode is specific: the friction turns out to be less widespread than it felt from inside the founder’s experience, or the timing is wrong and the enabling conditions (technology, behavior change, regulation) aren’t yet in place.
Google Wave is the clean cautionary case. It solved a coordination problem that genuinely existed, but it required users to reconceptualize how they thought about communication, and that behavioral shift never arrived at scale. The problem was real. The solution required too much of the user to bridge the gap.
The distinction between a latent problem and a premature solution is one of the harder calls in early-stage building. The question isn’t just whether the friction exists. It’s whether the conditions are ripe for people to start feeling it acutely enough to change behavior.
Naming the Problem Is Part of the Product
One underrated aspect of building in this territory: the founders often have to name the problem themselves. Coinage matters. “Sharing economy.” “Creator economy.” “Serverless.” These weren’t categories that existed and then got companies built around them. The companies built the categories, and the labels followed.
This naming function is not just marketing. It’s the mechanism by which latent demand becomes legible, to customers, to investors, and to potential employees. The company that successfully names the problem it’s solving earns a durable positioning advantage over every company that enters the space later, because later entrants are always explaining themselves in relation to the category the pioneer defined.
The founders who do this well are usually the ones who were close enough to the friction to understand it from the inside, not the ones who found it in a market research deck. The problem has to be personal enough to generate conviction through the period when no one else believes it’s worth solving. That conviction is what gets you through the years when the market hasn’t caught up yet.
And when it does catch up, you’re already there.
