dogfooding
jargonops cultureprogramming
Using your own product internally, so its failures bite you before they bite customers.
The phrase's tech usage is commonly traced to 1980s Microsoft, where a manager's 'Eating our own Dogfood' email pushed teams onto their own unfinished server software. Dogfooding shortens the feedback loop no survey can: the builders feel the latency, hit the edge cases, and cannot close the ticket on themselves. Its known failure mode is monoculture, since a company of power users eats a diet no customer eats; dogfood accordingly, then still test with strangers.
Dogfooding is running your own product in earnest, and the crude name is the point: nobody claims it is pleasant. The phrase entered software at Microsoft in the late 1980s and stuck because it names an accountability that marketing language cannot.
What it produces is not testing but consequence. A bug that annoys your users is a ticket; a bug that stops your own team from shipping is an emergency, and the priority sorts itself out without anyone arguing about severity levels. It also surfaces the things testing never finds, because tests exercise features while daily use exercises workflows, and the friction lives between features rather than inside them.
The limits deserve stating. Internal users are not representative: they have context, permissions, tolerance and access to the people who wrote the thing, so they route around problems that would stop a real customer cold. Dogfooding therefore catches a specific class of failure very well and systematically misses the onboarding experience, which is the one that decides whether anyone becomes a user at all.
Also known as: eat your own dog food