Here is a scenario that plays out constantly in startup circles. A founder gets on stage at a demo day, leans into the mic, and says, ‘I built this because I had this exact problem myself.’ The crowd nods. The investors scribble notes. The myth gets reinforced one more time. Except when you actually look at the companies that reshaped industries, the founder-as-user story starts falling apart in uncomfortable ways.
Early-stage founders win by pretending they don’t know the rules, and one of the rules they’re quietly ignoring is the sacred gospel of ‘scratch your own itch.’
The Origin Story We Sell Ourselves
The ‘scratch your own itch’ framework has real appeal. It’s clean, it’s emotionally resonant, and it makes for a great pitch narrative. If you built a tool because you personally suffered without it, investors assume you understand the customer deeply. You speak their language. You won’t need to do as much discovery because you already are the discovery.
But this logic has a serious flaw baked into it. Founders who build for themselves tend to build for people exactly like themselves. And people exactly like a technical founder in their thirties with disposable income and high tolerance for early-stage software are a very specific, often very small, market.
Stewart Butterfield did not build Slack because he personally struggled with workplace communication. He was building a video game called Glitch, the internal messaging tool his team was using became more interesting than the game itself, and he pivoted. The problem he solved belonged to his team, not to him personally. Sara Blakely did not have a background in hosiery manufacturing when she founded Spanx. She had a problem, sure, but the insight that turned it into a billion-dollar business came from obsessive customer research and an outsider’s willingness to question every assumption the industry had calcified around.
The Empathy Gap Is Actually an Advantage
Here’s the counterintuitive part. Founders who do not personally have the problem they’re solving often build better solutions than founders who do. The reason is something researchers call the curse of knowledge. When you’ve lived inside a problem for years, you stop seeing it clearly. You’ve developed workarounds, mental shortcuts, and tolerances that blind you to how broken the underlying experience actually is.
Outsiders see the problem fresh. They don’t accept the workarounds as inevitable. They ask ‘why does it have to work this way at all?’ and that question, repeated relentlessly, is where the real product breakthroughs come from.
Brian Chesky was not a person who regularly needed to rent out a room in his apartment before he co-founded Airbnb. He and Joe Gebbia did it once out of financial desperation, noticed something interesting in the experience, and then spent enormous energy understanding the people who would need this regularly. The product insight came from proximity to the problem, not from being the primary sufferer of it.
This connects to something worth understanding about how the best products get built. Successful startups deliberately choose crowded markets and the reason will change how you think about competition. The founders entering those markets successfully are rarely the ones who suffered through the old solutions for years. They’re the ones who looked at the existing solutions without loyalty to them.
Why Founder-Market Fit Beats Founder-Problem Fit
The framing that actually matters is not whether the founder had the problem. It’s whether the founder can develop deep, almost obsessive understanding of the people who do. This is what people mean when they talk about founder-market fit, though the concept gets watered down in most discussions of it.
Founder-market fit is not about your resume lining up neatly with your target customer. It’s about your capacity to go learn a world that isn’t yours yet. Some founders have an unusual ability to sit across from someone struggling with a problem and come away understanding not just what the person said but what they meant, what they were embarrassed to say, and what they didn’t even realize they were telling you.
This skill compounds. Founders who are genuinely curious about people they’re not like tend to build for larger and more diverse audiences. They don’t accidentally filter out customers who don’t match their own profile.
The Research Discipline That Separates These Founders
So if you’re not building from personal experience, what replaces it? The answer is not glamorous. It’s structured, repeated, sometimes tedious customer research conducted before you’ve written a single line of code.
The founders who build successfully for problems they don’t personally have tend to share a few habits. They do customer interviews compulsively, often hundreds of them, before committing to a solution. They look for patterns across very different kinds of people experiencing the same friction. They pay attention to the emotional weight of the problem, not just the functional description of it. And critically, they stay close to users after launch rather than retreating into the product.
This discipline is harder to maintain than it sounds, especially once you have a product to obsess over. The context switch tax that affects individual productivity affects founders too. Getting back into deep customer empathy mode after weeks of sprint planning and investor updates requires real intentionality.
What This Means for How You Pick Your Problem
None of this means personal experience with a problem is a liability. It’s a starting point, and sometimes a good one. The founders who get into trouble are the ones who treat their personal experience as a substitute for customer research rather than a prompt for it.
If you’ve had the problem yourself, great. Now go find 200 other people who have it and assume that half of what you think you know about their experience is wrong. You will be right about that assumption more often than you’re comfortable with.
If you haven’t had the problem yourself, don’t let the demo day mythology convince you that you’re starting from a disadvantage. You’re starting from a different place, one with less built-in bias and fewer assumptions to unlearn. Use that.
The companies that matter got built by people who were relentless students of problems they often didn’t personally own. The founder-as-suffering-user is a compelling story. But it’s mostly a story. The actual work looks a lot more like research, more like listening, and a lot less like autobiography.
