Software Growth

Dogfooding

Dogfooding means using your own product internally, as a real customer would, so your team finds its problems before customers do.

Dogfooding is the practice of your own team using the product you sell. If you build a project management tool, you run your company on it. The point is to feel the same friction your customers feel, early, while it is cheap to fix. For a small SaaS team it is one of the cheapest sources of product insight, and it signals confidence to customers.

Where the term comes from

The phrase is usually traced to Microsoft. Wikipedia's account says that in 1988 Paul Maritz sent a message titled "Eating our own Dogfood" to Brian Valentine, a test manager on Microsoft LAN Manager, challenging him to increase internal usage of the product. The term then spread through the company. The same account describes Dave Cutler's push for daily internal use of Windows NT builds in 1991, and notes that the early software was crash prone, but the feedback and social pressure of breaking the build were strong motivators.

How to do it well

  • Use it for real work. Running a fake test account does not surface real problems. Run your invoices, support or planning through the product.
  • Use it as a customer. Sign up with a fresh account and go through onboarding on a free plan sometimes, instead of using an admin shortcut.
  • Dogfood new releases first. Ship to your team behind a feature flag for a week before customers see it.
  • Write down friction. A shared channel where anyone drops "this was annoying" keeps the list alive.

Limits and pitfalls

  • You are not your customer. Your team knows the product's quirks and has expert habits. Dogfooding does not replace customer interviews and usage data.
  • It can push you toward feature creep. Internal users ask for features that fit their workflow. Check demand outside the team.
  • It only works if you are a customer. If you build a tool for dentists, you cannot dogfood it the same way. Spend time in a dentist's office or shadow users instead.
  • Enthusiasm wears off. Make it part of a routine, not a campaign.

Joel Spolsky gives a concrete case from Fog Creek. Weeks before CityDesk was due to ship, he took a build home and tried to make a real site with it. Careful menu-by-menu testing had missed bugs that stopped him within a minute of using the product the way a customer would.

For bootstrapped teams

It is easiest when you started by solving your own problem. If you did, keep running your company on the product, and publish what you learn in your changelog. If not, find at least one real internal workflow it can handle, even something small like tracking your own feedback requests.

Related terms

Sources

Back to the SaaS glossary