Dogfooding Program

Dogfooding program

Dogfooding means your own company uses the unfinished product to do real work, so the bugs that only appear in real use surface on employees instead of customers. It fails in two directions: as theater, where people install the build and never touch it, and as a popularity contest, where ten enthusiasts' praise hides a hundred quiet abandonments. A program with cohorts, routed feedback, and hard exit gates keeps it honest.

Method

1. Define what counts as using it. A passive install is not dogfooding. Require the cohort to do actual work on the new thing, and demote or remove the old tool so falling back takes effort. If people can quietly keep using the incumbent, you learn nothing.
2. Ramp cohorts in rings. Start with the team (dozens), widen to the org (hundreds), then the whole company (thousands). Each ring is a gate: do not widen until the current ring's crash rate and top bugs sit under threshold. Microsoft calls these rings; Google runs fishfood before dogfood.
3. Route all feedback into one intake. Bugs go to the tracker with build number and repro steps, feature requests to a backlog, sentiment to a survey. A screenshot dropped in a chat thread is feedback that dies where it lands.
4. Instrument adoption instead of trusting the mood. Track daily actives inside the cohort, task completion, and the fallback rate to the old tool. Loud fans in a channel are not data; silent churn is the signal that matters, and only telemetry shows it.
5. Triage on a cadence and close the loop. Hold a weekly bug review, keep a visible burn-down, and reply to reporters. Dogfooders who never hear back stop reporting, and then the program looks healthy precisely because it went quiet.
6. Set numeric exit criteria before you start. Name the crash-free rate, zero open P0 and P1 bugs, a retention floor, a CSAT or NPS bar, and no open data-loss defect. Exit to GA is a checklist met, not a launch date arrived.
7. Keep exit reversible and write the known-issues list. If the bar is not met, hold. A tool your own company will not use is the clearest possible no-go, and shipping past that signal to hit a date is how the program becomes theater.

Checks

• Can a cohort member get their real work done on the build, or do they quietly reach for the old tool?
• Do you know the fallback rate and daily actives from telemetry, not from vibes?
• Are the exit criteria numbers you can check, or adjectives you can argue about?

Boundaries

Dogfooding surfaces real-use bugs and adoption risk; it is not a valid usability study, since employees are a small, expert, biased sample and not your customers. Pair it with an external beta for representativeness, and route the GA go decision itself to the launch-review skill rather than treating a clean dogfood as a launch.