dogfooding-programlisted

# 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