Dogfooding

What is Dogfooding?

Dogfooding means using your own product internally, day to day, instead of only watching customers use it. If your team runs its own support tickets through your own ticketing tool, or closes its own deals in its own CRM, that's dogfooding, applied to two different parts of a stack.

The phrase's exact origin is debated. One camp traces it to 1970s Alpo dog food commercials, where actor Lorne Greene said he fed Alpo to his own dogs, alongside a rumor that the president of Kal Kan Pet Food ate his own product at shareholder meetings (Wikipedia). The other camp, reported by GeekWire, credits Microsoft's first head of OEM sales, Jim Harris, who used to ask after product pitches, "Yes, but will the dogs eat the dog food?" (GeekWire).

What's firmer is how the term entered tech culture. In 1988, Microsoft manager Paul Maritz sent test manager Brian Valentine an email titled "Eating our own Dogfood," pushing him to increase internal usage of Microsoft LAN Manager. The term spread through the company from there and eventually into the wider industry (Wikipedia). Produck uses "dogfooding" the way most SaaS teams do now: running your own product as a live, daily user, not a periodic tester.

Why it matters for product-market fit

Dogfooding is a Ship-stage habit, but its payoff shows up earlier in the loop. When your team is a real user of your own product, you catch the rough edges before a customer has to file a complaint about them. That changes the raw material flowing into Listen: instead of only external user feedback, you get a constant internal stream of friction reports from people who understand the roadmap and can describe the problem precisely.

That internal signal still needs to go through Diagnose and Decide like any other input. A frustration your own team hits daily is a strong prior, but it's not automatically what your paying customers need next. The discipline is to treat dogfooding as a feedback source that feeds product discovery, not a substitute for it. Teams that skip this step end up building for themselves, which is a common reason products drift from actual market fit. Produck's the PMF stack is broken piece makes a related point: most teams have plenty of raw signal and no working system for turning it into decisions, and dogfooding is one more signal source that needs that same system.

Done well, dogfooding also tightens iteration. A bug or a clunky flow you hit yourself gets fixed faster than one you only hear about secondhand, because you don't have to wait for a ticket to reproduce it. Over time, that faster loop is part of what protects retention: fewer papercuts reach the customer in the first place, and the ones that do get fixed sooner.

When it works, and when it doesn't

It works when

• Your team's daily use of the product closely resembles a real customer's workflow, not an edge case only engineers hit
• You have a real channel for turning what your team notices into logged, prioritized items instead of Slack complaints that evaporate

It falls short when

• Your product serves a very different user than your own team, like a consumer app built by B2B veterans
• Internal use is performative, a mandate to "use the product" once a quarter, rather than a genuine daily habit
• Your team's context lets them route around problems a real customer would get stuck on, so the friction never surfaces
• Nobody owns turning internal findings into shipped fixes, so the same complaints resurface every month

How to apply it

1. Pick one workflow your product is meant to support and have your own team run it for real work this week, not a staged test.
2. Give the team a two-minute way to log friction as they hit it: a shared channel or a form tied to your Listen stage.
3. Route those internal reports into the same Diagnose process as customer feedback, tagged so you can see if internal and external users are hitting the same wall.
4. In your next planning session, treat internal dogfooding reports as one data source among several, not an automatic top priority.
5. Ship the fix and have the same internal team verify it in their normal workflow before you call it done.
6. Revisit monthly whether your team's usage still resembles a real customer's, since products and teams both drift over time.