Picture a room full of twenty-something engineers building a product for sixty-five-year-old retirees managing their Medicare supplements. Nobody in that room has ever navigated a Medicare form. Nobody has spent twenty minutes on hold with an insurance company while their hands shake from arthritis. Nobody in that room would ever use this product voluntarily. And that company? It raised a Series B and is now processing over two million claims a year.
This is not an accident. Some of the most durable startups in tech were built by founders who were constitutionally unsuited to be their own customers. The conventional wisdom, the one plastered across every startup bootcamp and Y Combinator blog post, says to build what you know, scratch your own itch, solve your own problem. That advice is not wrong exactly, but it is dangerously incomplete. Most successful startups abandon their original business model within 18 months, and a big reason is that founders eventually discover the user they imagined and the user who actually pays them are two completely different people.
The “Scratch Your Own Itch” Myth Has a Body Count
The founders-as-users model works brilliantly in a narrow set of circumstances. Developer tools are the classic example. When Stripe launched, Patrick and John Collison were developers who hated how painful payment processing was. They built for themselves and their peers, and the product was sharp because the founders felt every paper cut personally.
But most market opportunities do not live in that narrow band. They live in industries where the people with the deepest problems are not writing Medium posts about them. Elderly patients, blue-collar workers, small business owners running landscaping companies, rural hospital administrators, none of these people are the founders of the startups eventually solving their problems. And that distance, that fundamental foreignness, can be an advantage if you treat it honestly.
The founders who fail are the ones who paper over the distance with assumptions. The founders who succeed are the ones who treat their own ignorance as a research assignment that never ends.
Discomfort Is Diagnostic
Here is something counterintuitive that took me a long time to understand. When a founder uses their own product and finds it genuinely uncomfortable or confusing, that feeling is not a signal that the product is broken. It is often a signal that the product is calibrated correctly for someone else.
A founder building accounting software for independent truckers should probably find the interface a little slow and deliberate. Truckers are not optimizing for speed. They are optimizing for not making an expensive mistake at the end of a twelve-hour shift. If the founder, who can navigate spreadsheets in their sleep, finds the software annoyingly hand-holdy, that is a feature, not a bug.
This connects to something deeper about how the best technical teams operate. Successful startups hire their biggest critics as first employees precisely because internal comfort is a terrible proxy for product quality. You want people in the room who will tell you the thing you built does not actually work for the person you built it for.
The Empathy Debt Problem
There is a version of this that goes badly wrong, and it is worth naming directly. Building for users you do not understand requires a sustained, almost aggressive empathy practice. Without it, you end up with something worse than a product founders hate using. You end up with a product nobody understands, built by people who stopped asking questions after the first user interview.
The companies that navigate this well treat user research like infrastructure, not like a project. They embed people from the target community as advisors, consultants, or actual employees. They do not just watch users struggle with prototypes in a lab and call it a day. They go to where the users are, repeatedly, and they bring back findings that make the product team uncomfortable.
This discomfort inside the building is actually protective. Tech companies build features they never release on purpose, and part of the reason is that internal testing surfaces assumptions that would otherwise survive all the way to launch. When founders hate using their own product, they are more likely to ask whether the product actually works, rather than assuming it does.
Pattern Recognition Cuts Both Ways
Venture capitalists fund a lot of founder-as-user stories because they are legible. The pitch is intuitive, the passion is visible, and the market hypothesis is easy to evaluate. Venture capitalists decide your startup’s fate in under 10 minutes using pattern recognition, not gut feeling, and the pattern of a passionate founder solving their own problem is one of the most recognizable templates in the room.
But pattern recognition is backward-looking by nature. The markets that look familiar are often already crowded. The markets that look strange, the ones where the founder has to explain who the user is and why they matter, those are sometimes the ones with the most room.
The pitch for a startup serving a customer the founder has never been is harder to make, which is partly why so few people try. That asymmetry is where the opportunity hides.
How to Build for Someone You Are Not
If you are building for users you do not instinctively understand, the practical discipline looks like this.
First, document your assumptions obsessively, specifically the ones that feel so obvious you almost did not write them down. Those are the dangerous ones. Second, recruit users into the process, not just as test subjects but as ongoing collaborators who can tell you when you have drifted back toward building for yourself. Third, when your product feels wrong to use from the inside, investigate rather than iterate. Ask whether the wrongness is a calibration problem or an insight.
And fourth, resist the pressure to make the product comfortable for the people building it. Internal comfort is seductive. It feels like progress. But it is often just the product converging toward the founders instead of converging toward the user.
The companies that get this right are usually the ones where someone in a leadership role is willing to say, out loud, in a product review, that they personally find this product frustrating to use and that this might be exactly right. That kind of honesty is rarer than it sounds. It requires separating ego from evidence, which is the hardest thing to do when you have staked your professional identity on what you are building.
The founders who crack markets they do not belong to are not smarter than everyone else. They are just more honest about what they do not know, and more disciplined about staying uncomfortable until the product earns the right to feel finished.
