Eat Your Own Food: When Software Makers Become Their Own Users

Imagine walking into a restaurant, hearing the chef recommend the signature dish, and asking whether they eat it themselves. Their answer: “No, I order delivery from the place across the street.”

Something similar can happen with software. A company may deliver a flawless demo, promise that its system saves time, and show a presentation full of arrows. But one question is much more revealing: Does it use the product to do its own work?

That is the idea behind Eat Your Own Food, a gentler way of referring to a concept known in technology as eating your own dog food or dogfooding: using the product you develop in real situations to discover its problems and improve it. The phrase has less glamour than a sales presentation. And a much more entertaining backstory.

First Came the Dogs. Then Came the Servers

One of the most frequently told stories connects the expression to ALPO commercials featuring Lorne Greene in the 1970s. The actor recommended the food and showed that he also fed it to his own dogs. The advertising message was easy to understand: I trust what I sell enough to use it at home.

Below is an archival copy of one of those commercials, uploaded to YouTube by Bionic Disco and attributed to 1976:

An ALPO commercial featuring Lorne Greene, attributed to 1976. This campaign is often cited as a precursor to the expression. Watch the video on YouTube.

There is an important detail: it has not been established that this commercial gave rise to the term at Microsoft. There is no need to imagine Greene eating dog food, either: the point was that he chose it for his dogs. GeekWire’s account distinguishes that popular association from the story told by one of the people involved.

Microsoft Turned the Phrase into a Way of Working

The term’s move into software is usually traced to Microsoft in 1988. Paul Maritz, then a company executive, later recalled hearing the expression from Jim Harris, one of Compaq’s founders.

According to his account, Maritz emailed the LAN Manager team to ask them to use the software they were developing. Brian Valentine responded by setting up a server called dogfood. The product was no longer just something being built for others: it now supported its creators’ everyday work.

Maritz tells the story firsthand on the TiE Seattle podcast, starting at roughly 11:32. It is a retrospective account, rather than the original email preserved on screen, but it explains why the expression stuck: when your workday depends on the product, its problems stop being abstract.

A Bug Gets a New Priority When It Ruins Your Morning

Suppose you are developing a task management system. In the demo, you create a task, assign it, and mark it as complete. Everything works perfectly. Applause.

Now use it for two weeks to coordinate a real project. Different questions start to appear: How do you find unfinished work? Why do you get five notifications about the same change? What happens when someone goes on vacation? How do you recover a task you closed by mistake?

The dogfooding process brings the team face to face with that friction. An unnecessary step that seemed minor in a meeting becomes considerably less charming when you have to repeat it twenty times a day.

For the software industry, this brings several benefits:

• Problems surface earlier. Sustained use can reveal bugs, slowdowns, and situations that an isolated test did not cover.
• Priorities reflect real work. Teams get a better understanding of what prevents someone from finishing a task and what is simply an aesthetic preference.
• Better communication across teams. Development, product, and support can discuss concrete experiences rather than just tickets or assumptions.
• Responsibility for the whole experience. Account creation, permissions, error messages, documentation, and recovery when something fails all matter, too.

Google and GitLab Also Took a Seat at the Table

In December 2009, Google published An Android dogfood diet for the holidays. It explained that employees were testing a mobile device running Android to experiment with new capabilities and provide feedback. The product was leaving the lab and entering the pockets of people who could encounter problems during their day.

GitLab, meanwhile, documents dogfooding as part of its product and engineering work. Using its own platform to develop software allows the company to turn internal needs into observations about the product.

These examples show something useful: the value comes when experiences are recorded, discussed, and turned into improvements. Installing the application and forgetting about it does not count as much of an experiment.

The Catch: The Chef Already Knows Where Everything Is

The people who built a system know its shortcuts, understand its terminology, and know which button they should probably avoid for now. A new customer has none of those advantages.

The internal team may also work with few users, fast computers, and an excellent internet connection. Customers may have different needs, different experience levels, accessibility requirements, and much larger volumes of data.

That is why using your own product complements testing and research with real users. Security checks, automated tests, performance evaluations, and conversations with the people the product is intended to serve are still necessary. The fact that something feels convenient to the team does not prove that it will be useful to the entire market.

How to Put It into Practice Without Putting Operations at Risk

You do not need to be Microsoft or manufacture phones. You can start with a small, well-defined process:

1. Choose a task that matters. Managing requests, preparing reports, or tracking sales opportunities. There must be real work behind it.
2. Follow the normal user journey. Test with an ordinary user’s permissions, without solving every problem directly in the database.
3. Set limits and have a way out. Choose appropriate data, protect information, and keep an alternative available if the system fails. Critical processes require more controls.
4. Record what gets in the way. Confusing steps, tasks that take too long, errors, and improvised workarounds. Measure how long it takes to finish the work.
5. Fix it and test again. Check what you have learned with external users before turning every internal need into a new feature.

In custom software development, this can also apply to components and processes that a provider shares with its customers. When the domain is highly specialized, such as a medical or industrial operation, people who truly know that field need to be involved. The technical team cannot replace that experience.

Taste It Before You Serve It

The dogfooding approach offers a test of consistency: if you believe your software improves someone’s work, find a real, safe opportunity to experience that improvement yourself.

And if using it makes you want to go back to the old spreadsheet, it is better to find out before your customer does.

The next time you evaluate a tool, ask for more than a demo: “Which parts of your own work do you do with this product, and what did you change after using it?” The answer may tell you more than several slides. The chef can explain the recipe. What matters is what happened when they sat down to eat.