A few years ago, I was sitting in a product review meeting at a mid-sized SaaS company. The team had just shipped a new project management feature they’d been building for six months. The product manager running the meeting, someone who had championed this feature through every sprint review and stakeholder call, pulled up her own screen to walk us through it. She was using a plain text file and a handwritten notebook to manage her own work. Nobody in the room said anything. Nobody was surprised.
This scene plays out constantly in tech, and most people treat it as a quirk or a contradiction. It isn’t. The gap between what tech workers build and what they actually use is one of the most revealing fault lines in the entire industry. Once you understand why it exists, you start seeing the whole business of software differently.
The User You’re Building For Is Never You
Here’s the uncomfortable truth that nobody puts in the pitch deck: most software is not built for the people building it. It’s built for a specific kind of user, usually someone with less context, less tolerance for complexity, and different constraints than the engineers, designers, and product managers who are crafting the experience.
A developer who builds a consumer password manager probably uses a combination of custom scripts, a hardware key, and muscle memory developed over a decade. The product they’re building is for someone who reuses the same password across forty sites and genuinely does not know what two-factor authentication is. These are not the same person. They will never be the same person. The architecture of the internet itself makes certain problems unsolvable for average users in ways that experts can route around entirely.
So when an engineer refuses to use the product they just shipped, it doesn’t mean the product is bad. It means they are not the customer. The confusion happens because we assume builders and users should be the same, and in consumer tech especially, that assumption is almost always wrong.
The Expert Blind Spot Goes Both Ways
There’s a second layer to this that gets less attention. When builders do try to use their own products, they often can’t get an accurate read on the experience. They know too much. They know where every feature is buried, what every error message actually means, and how to work around every limitation. They are constitutionally incapable of being confused by something they designed.
This is why tech companies deliberately slow down their own websites during user testing. They’re trying to simulate conditions that their own teams can’t authentically recreate. You can’t un-know something. Once you’ve built a system, you can’t experience it the way a stranger would.
This is also why the best product teams treat internal non-usage not as a failure but as a data point. If your own engineers are routing around your product, you want to understand exactly how and why. That behavior is a map of the product’s real friction points, drawn by people who are too expert to be confused but not too loyal to be honest.
The Deliberate Distance Problem
Here’s where it gets more complicated and more damaging. Some companies don’t just accept that internal teams won’t use the product. They institutionalize the separation. Feedback loops between builders and real users get formalized into quarterly surveys and focus groups. The product team starts treating user research as an event rather than a practice.
At that point, you’ve got a company optimizing for an abstraction of a user rather than an actual one. Features get built based on what users say they want in a structured interview rather than what they demonstrably do when nobody is watching. The product roadmap becomes a document of stated preferences, which are almost always different from revealed preferences.
This is related to a phenomenon you see in AI development, where models perform differently when they know they’re being evaluated. The behavior you observe in controlled conditions is not the behavior you’ll see in the wild. The same principle applies to users in focus groups. The gap between observed behavior and authentic behavior is where most product failures are born.
What Smart Teams Do Instead
The companies that handle this well don’t try to force their engineers to use consumer products they have no reason to use. They do something more useful: they close the distance between builders and users through structure rather than expectation.
That means embedding product people in customer support rotations. It means hiring critics as early employees specifically because those people will use the product with adversarial attention. It means treating every support ticket as a product review rather than a complaint to be resolved and closed.
The best CEOs I’ve seen operate with a version of this principle baked into how they run meetings and make decisions. They create deliberate processes to stay close to information that would otherwise get filtered out as it moves up the organization. The boring meeting rule that some operators swear by is essentially a mechanism for staying connected to ground-level reality before it gets dressed up for executive consumption.
The Honest Version of “Eating Your Own Dog Food”
The tech industry has always had a complicated relationship with the idea of dogfooding, the practice of using your own products internally. As a cultural norm, it’s often more performance than practice. Companies announce that employees use the product, but the employees who matter most for feedback, the ones who would be the target user, are often the least like that user.
A more honest version of dogfooding would acknowledge the asymmetry and work with it rather than pretending it doesn’t exist. That looks like: specific employees who match the target user profile given structured time to use the product as that user, without their expert knowledge as a crutch. It looks like deliberately hiding features from new internal testers the same way you’d hide them from new users in a real onboarding flow.
The companies that close the gap between what they build and what works aren’t the ones where everyone uses the product. They’re the ones that have stopped pretending the gap doesn’t exist and built processes to see across it clearly.
