Dogfooding: what it means, benefits, limits and how to do it well

What is dogfooding?

Dogfooding, short for "eating your own dog food", means a company uses its own product internally, in real work, before and after customers do. The goal is to find bugs, rough edges and missing features in day-to-day use, and to give the people who build the product first-hand experience of what customers go through.

The phrase became common in the software industry in the late 1980s, when Microsoft managers pushed teams to run the company's own products internally. Some companies prefer softer names such as "drinking our own champagne"; the practice is the same.

Why teams dogfood

• Real usage finds real problems. Test plans cover expected paths; daily use finds the unexpected ones, such as slow screens, confusing settings and broken edge cases.
• Faster feedback loops. An internal user can report a bug the same day it ships, with context.
• Empathy and product sense. Engineers and designers who depend on the product notice friction they would otherwise read about in tickets.
• Credibility. A team that relies on its own product can speak about it honestly in sales and support.

The limits of dogfooding

Internal users are not your customers, and treating their experience as representative is a classic sampling mistake (see sampling bias):

So dogfooding complements customer research, usability tests and beta programs; it does not replace them. It is weakest for onboarding, because nobody inside the company is a first-time user.

How to run a dogfooding program

1. Pick real work, not demos. People should use the product for tasks they would do anyway.
2. Make feedback cheap. A dedicated channel or in-product report button, with a clear owner who triages daily.
3. Ship internal builds first. Run the next release internally for a week before customers get it.
4. Track it like a beta. Count active internal users, the share of their work done in the product, bugs reported per week and time to fix.
5. Close the loop. Tell reporters what happened to their feedback, or the program dies.

Example dashboard for a four-week internal rollout (sample data):

Falling bug reports with rising usage is the signal you want; falling reports with falling usage means people gave up.

Keep dogfooding out of your customer metrics

Internal usage distorts product analytics: employees open features nobody else uses, log long sessions, and trigger edge-case errors. Two practices keep the data clean:

• Exclude internal traffic from customer reports by IP range, hostname or a flag set for staff accounts; see exclude internal traffic.
• Analyze it separately on purpose. Tag internal users with a property such as is_internal: true and look at that segment on its own, so dogfooding data informs the team without polluting conversion rates and activation.

Dogfooding at TapCub

TapCub measures its own website and product with TapCub: sign-ups, logins, project creation and orders are sent from our servers to a TapCub project, and the team reads the same funnels, retention and reports that customers do. Internal and test accounts are filtered out of those reports so they reflect real customers. Many of the help articles on this site started as questions we hit while using the product ourselves.

See also: What is beta testing? Types, process and exit criteria.

Sources

• Wikipedia. Eating your own dog food.
• Harrison, W. (2006). Eating your own dog food. IEEE Software, 23(3).
• The New York Times (2022). Why tech companies "dogfood" their products.