dogfooding-program ยท diff
git:20260718.7c1285c to git:20260728.fac4544
19 added, 15 removed. Audit A to A.
---
name: dogfooding-program
description: Run an internal dogfooding program with staged cohorts, one feedback intake, and numeric exit criteria to general availability. Use when a pre-release product needs real internal use to surface bugs and adoption risk before it ships to customers.
---
# 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.
+ 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
+ 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.
+ 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?
+ - 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.
+ 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.