How to Run a Dogfooding Program Before You Open a Public Beta
Picture a small devtools startup with a public beta launch date locked to a conference keynote. Three weeks out, the team is behind, and someone suggests skipping the two-week internal dogfooding phase on the roadmap to buy back time. Engineering is already running the product for their own builds anyway, the argument goes — that counts as dogfooding. It doesn’t. The internal engineering usage never touches the new project-import flow, because engineering’s own accounts were already configured months earlier. Public beta users hit the flow on day one. A silent failure in the import step drops commit history for any repo over a certain size, and the team spends the first 48 hours of the public launch fixing data loss instead of collecting the feedback the launch was supposed to generate.
This is a common enough pattern to be worth naming up front: a dogfooding program exists to catch exactly that category of failure — the one that only shows up when someone experiences a product the way a genuinely new user would, not the way the team already uses it out of habit. It’s the step most teams skip when they’re behind schedule, which is exactly when skipping it costs the most.
The term itself comes from a Microsoft engineering culture in the late 1980s, where the expectation that teams should “eat their own dog food” — run the software they shipped, not just the software they were assigned to test — became internal policy rather than a suggestion. The organizations that have written the most about this since, groups like SVPG and Reforge, converge on the same point almost forty years later: dogfooding only works as a discipline with structure around it, not as a byproduct of a team happening to use its own product.
Why a Dogfooding Program Catches What a Beta Test Program Can’t
A beta test program that gives real signal depends on external users, which means it depends on the product being stable enough that external users don’t churn out of it in week one. Dogfooding is the phase before that — internal usage, on unreleased or newly-released features, run with enough rigor that it actually surfaces the failure modes a beta would otherwise catch at a much higher reputational cost.
The distinction matters because the two catch different things. A beta test program is built to catch product-market signal — do users want this, does it solve their problem, where’s the friction. A dogfooding program is built to catch the more mundane failures that make a product genuinely painful to use for anyone encountering it fresh: onboarding steps built by someone who forgot what onboarding feels like, error states that were never triggered because the person who wrote the code never made that mistake, edge cases that only exist for a new account and not a two-year-old internal one.
Who Should Be In a Dogfooding Program?
A common misstep, in the launch scenario above and elsewhere, is staffing the dogfooding program entirely with engineers. Engineers are the easiest group to mobilize and the worst possible proxy for a new user, because they already understand the product’s mental model and its known workarounds. An engineer who’s used to typing a specific flag to avoid a known bug isn’t testing the product a real customer will experience — they’re testing around the bug.
The dogfooding roster that actually surfaces UX and onboarding failures needs people who don’t already know the product’s internal logic: sales, support, and customer success, plus if company size allows it, employees from a completely unrelated function who’ve never touched the product. At a company under 30 people, that might mean recruiting the office manager or a finance hire for a 20-minute session — a strange ask, but a genuinely uncontaminated first impression is hard to manufacture any other way once everyone on the product and engineering team has seen the flow a dozen times.
Running the Dogfooding Program: Cadence, Feedback Loop, Exit Criteria
A dogfooding program without a feedback loop is just internal usage with an optional label. A structure that holds up well at small teams: a dedicated Slack channel for friction reports, triaged daily by the PM personally — a realistic setup for a lean team with no dedicated QA function — and a two-week minimum duration with explicit exit criteria before anything moves to public beta.
Triage needs a severity system or the channel turns into an undifferentiated wall of noise nobody prioritizes correctly. A simple three-tier split works well: P0 for anything that loses data or blocks task completion entirely, P1 for anything that causes real confusion but has a workaround, and P2 for cosmetic or minor friction that doesn’t change whether the task gets done. The daily triage isn’t a meeting — it’s the PM reading every new report each morning, tagging severity, and assigning an owner within the hour for anything P0. That daily cadence matters more than the tooling. A friction report that sits untriaged for three days trains people to stop filing them, which quietly kills the program from the inside even though it technically still exists.
Dogfooding vs. Internal Alpha vs. Public Beta
| Phase | Who Tests | What’s Gated | Exit Criteria |
|---|---|---|---|
| Internal alpha | Engineering only | Core functionality, crash-level bugs | Feature technically works end to end |
| Dogfooding | Whole company, cross-function | Onboarding, error states, edge cases | Zero unresolved P0/P1 friction reports for 3 days |
| Public beta | External users, opted in | Product-market signal, real-world scale | Retention/activation targets met |
Exit criteria matter more than duration. Two weeks is a reasonable default, but a stronger gate is zero unresolved P0 or P1 friction reports for three consecutive days — a team that hits that bar in nine days shouldn’t wait out a calendar-driven two-week slot, and a team still generating P1 reports on day thirteen shouldn’t ship on schedule just because the box on the roadmap says two weeks.
Feature Flags: How PMs Gate a Dogfooding Rollout
Feature flagging is what makes a dogfooding program operationally possible without branching a codebase or maintaining a separate internal build. A flag scoped to an internal user group lets engineering ship to production continuously while the feature stays invisible to anyone outside the dogfood cohort, and — critically — lets the same feature flip to a beta cohort later without a second deployment. The mistake in the launch scenario above wasn’t a lack of feature-flagging infrastructure; the team had it. The mistake was gating the new import flow behind a flag that defaulted to “on” for all internal accounts that had been created before the flag existed, which is exactly why longtime engineering accounts never hit the code path a brand-new account would.
The operational lesson: a dogfooding flag should be scoped by account creation date or explicitly opted in, never inherited by default from an account’s prior state. If a test cohort’s accounts don’t resemble a new customer’s account in age, configuration, and data volume, they’re not actually dogfooding the new-user experience, no matter how much traffic they generate.
When This Breaks: Dogfooding Blindness
The most common way a dogfooding program fails isn’t skipping it — it’s running it and still missing the failure, because the internal team is structurally blind to the same things a new user would be. An engineering team can use a product daily and never once encounter an import bug like the one above, not because they’re negligent, but because their own accounts were configured months before the buggy code path existed. Institutional familiarity is itself the blind spot.
The fix isn’t more internal usage — it’s deliberately simulating a fresh account. Every dogfooding cycle should include at least one tester who creates a genuinely new account, with no pre-existing configuration, and completes the full onboarding flow from a cold start, the same day, in front of someone taking notes. That single ritual catches a large share of what generic “everyone’s already using it” dogfooding misses, because it forces at least one person to actually be new.
There’s a second, quieter version of dogfooding blindness worth naming: data volume and account age. An account that’s been live internally for two years has years of accumulated data — hundreds of projects, thousands of records — and performance problems that only appear at that scale get exercised constantly. A brand-new customer account has none of that, so a totally different category of bug shows up: empty states nobody designed for, onboarding checklists that assume prior context, first-run tutorials that were written once and never re-tested. Dogfooding on a mature internal account tests the “this breaks under load” failure mode well and the “this is incomprehensible with zero data” failure mode not at all. Both matter, and testing only one because it’s the account everyone already has open is how a program that looks thorough on paper still misses what a real new customer hits first.
From Dogfooding to Public Beta: What Changes
Moving from dogfooding to public beta isn’t just widening the flag — it’s a different kind of feedback being collected. Run well, dogfooding also overlaps with the delivery side of dual-track agile — while one track is deep in discovery on the next feature, the dogfooding cohort is delivery-side validation on what already shipped, running in parallel rather than in sequence. Teams that treat dogfooding as a one-off pre-launch checklist item, instead of a standing track running alongside discovery, tend to rediscover the same onboarding failures every release.
The feedback itself also changes in kind, not just in volume: internal testers report defects, external beta users report fit. Dogfooding feedback is mostly “this is broken” or “this is confusing.” Beta feedback should be mostly “I don’t need this” or “this doesn’t fit how I work,” the product-market signal a voice-of-customer program is built to capture systematically rather than anecdotally. If the dogfooding phase is still generating “this is broken” reports when the beta opens, the launch moved too early, and the beta cohort will spend their attention on bugs instead of the signal actually needed from them.
Teams that add a mandatory two-week dogfooding phase with hard exit criteria as a permanent step — instead of an “if we have time” step that gets cut under launch pressure — consistently report lower public-beta support ticket volume in the weeks after future launches compared to launches that skipped the phase. It isn’t a controlled experiment in any single case, but the pattern shows up often enough across teams that most stop debating whether the phase is worth the calendar time.
This is also the point to revisit anything learned from a first product launch and check it against what dogfooding actually surfaced this time — the mistakes that surprise a first-time launcher are frequently the exact ones a properly staffed dogfooding cohort would have caught two weeks earlier, cheaply, with nobody outside the company watching.
What to Track While the Program Is Running
Beyond the P0/P1/P2 friction count, a few other signals are worth tracking during the dogfooding window itself, not just at the exit-criteria check. Time-to-first-completed-task for a cold-start tester is one of the most useful — if a brand-new account takes twenty minutes to reach the product’s core value moment when the intended experience is five, that gap is worth fixing before public beta regardless of whether anyone files a formal friction report about it. Testers rarely file a report for “this took longer than it should have”; they just quietly get frustrated and move on, which is exactly the kind of signal a raw friction count misses.
It’s also worth tracking which parts of the product generate zero friction reports at all, not just which parts generate the most. A feature nobody complains about during dogfooding is either genuinely solid or completely unused by the cohort — and those look identical in a report count. Checking basic usage logs against the friction channel closes that gap: if a feature has real usage and zero reports, that’s a good sign; if it has near-zero usage and zero reports, the dogfooding cohort simply never exercised it, and it’s still untested going into public beta.
Finally, track reopened reports — friction that was marked resolved and then reappears in a later session. A high reopen rate usually means fixes are being shipped without the original reporter re-testing the exact flow that broke, which is a weaker form of the same blindness that makes engineers a poor dogfooding cohort in the first place: a fix that looks complete to the person who wrote it can still miss the actual failure a fresh user hit.
Set the Exit Criteria Before You Start
The single highest-leverage change most teams can make to an existing dogfooding habit is writing the exit criteria down before the phase starts, not deciding after two weeks whether it “feels ready.” Pull five people outside engineering into a cold-start session this week — no primed accounts, no pre-existing configuration — and count how many friction reports come back in the first twenty minutes. Whatever that number is, that’s more information about the onboarding flow than existed an hour ago, and it arrives before a customer has to deliver it the hard way.
Write the P0/P1/P2 definitions down before running that session, not while triaging its results — deciding severity in the moment, under the pressure of a launch date, is exactly how a genuine P0 gets waved through as a P1 because nobody wants to be the person who delays the keynote. A five-minute definitions doc, agreed on before anyone files a single report, is cheap insurance against that pressure showing up later when it’s harder to resist.
References
Reforge — “Beta Programs and Internal Testing,” 2026
Silicon Valley Product Group — “The Role of Internal Testing Before Launch,” 2026
Microsoft — origin of “eating your own dog food” as an internal engineering practice, 1988
