Eating more dog food
by Warren Runk

Eating more dog food

Not just for children anymore

Contents #

Intro #

We’ve all seen the sad product that no one loves:

A login screen that helpfully suggests both "Log out" and "Log in" — the kind of UI only a team that never uses its own product could ship.

And we’ve also felt the pure joy that is a product built, tuned, labored after, obsessed over, and maintained at near perfection by true craftspeople:

Asana — a product that feels like every pixel and every interaction has been argued about for years, by people who use it every day.

A product that is fast, works on all hardware/browsers/situations, and never seems to have a bug.

I'm here to claim that good dogfooding is what makes the latter possible. And even if you already know what dogfooding is, keep reading — the AI age changes the stakes in ways most teams haven’t internalized yet.

Necessary but not sufficient #

The best products are made by the best product and engineering teams, where excellence, meticulousness, and attention to detail permeate the whole org from bottom to top. Dogfooding usually plays a huge role in that ongoing quality — it’s really hard to imagine that level of scrutiny channeled without a real dogfooding process in place.

A good dogfooding culture gives you the scaffolding to create and maintain excellence. But you still need to do the hard product work — like actually talking to customers — and you have to be honest with yourself about the limits of dogfooding.

The good news:

Figma: only design in Figma #

For roughly 18 months before its 2015 closed beta, Figma’s team had one ironclad rule: every new design happens in Figma. Dylan Field:1

"We made it a rule for ourselves to only make new designs in Figma. … While initially painful, dogfooding early in our product’s lifecycle helped us prioritize the right things and create processes to keep the quality of the product high."

Initially painful. That’s exactly the right phrase. Real dogfooding is, at first, slower than the alternative — and that’s the point.

So what actually is good dogfooding? #

Most people in product and engineering have heard of this concept, but it’s always worth re-checking the definition you’re carrying around.

At the simplest level, "eating your own dog food" means nearly everyone in your company using your own product(s) often, and in a way that’s consistent with how your customers do. Done well, this:

And keeping it that simple is important; there are plenty of ways to over-engineer it, and we’ll get to pitfalls in a minute.

The origin: Microsoft 1988 and Apple 1980 #

"Dogfooding" was popularized inside Microsoft in 1988, when manager Paul Maritz emailed test manager Brian Valentine with the subject line "Eating our own Dogfood," challenging him to drive internal adoption of Microsoft LAN Manager.2 The phrase came from Jim Harris, Microsoft’s first head of OEM sales, who used to ask after presentations, "Yes, but will the dogs eat the dog food?" — likely echoing 1970s Alpo commercials in which Lorne Greene said he fed Alpo to his own dogs. Microsoft’s networking server was literally named \\dogfood.

Eight years earlier, Apple president Mike Scott had issued a memo on Feb. 1, 1980 making the same move in physical-product form:3

"Effective Immediately!! No more typewriters are to be purchased, leased etc., etc. … We believe the typewriter is obsolete. Let’s prove it inside before we try and convince our customers."

That single line is still the cleanest articulation of the philosophy.

Why now? AI just raised the stakes #

At Chorus, as more and more software was created by non-humans in 2024+, it became clear that we had to heavily invest in verification — loads of tests, from unit to e2e — and dogfooding fit there nicely.

By late 2025, some estimates put even large, well-established companies’ rates of code generation at 3x+ pre-LLM levels. That’s a staggering figure no matter how you look at it, and it makes a strong case for some form of increased verification. Code, tests, and even AI-generated code summaries are still difficult and time-consuming to read.

The verification problem compounds even harder when the LLM is exposed directly to users:

Anthropic: antfooding #

Anthropic calls their version "antfooding." Roughly 70–80% of technical Anthropic employees use Claude Code every day4. The product team gets a feedback message about every five minutes. The internal alpha hit 20% engineering adoption on day one, 50% by day five. Mike Krieger, CPO:4

"Claude is now writing Claude."

That’s not a slogan; it’s a release strategy. And it’s the natural endpoint of taking dogfooding seriously when the product itself is non-deterministic.

How not to dogfood #

A few traps worth naming up front:

Dogfooding is easiest for business products — Asana, Slack, Outlook, Linear — that staff can use directly as part of their day-to-day. Anything else takes more care and creativity, which unfortunately is most products. But also: not dogfooding a business product like that is a glaring red flag, and a fatal one if customers ever find out.

Forced testing sessions outside of your product/eng team can backfire:

Putting too much emphasis, structure, or process on dogfooding is often inappropriate:

Notion: the lost years #

Notion almost died from over-dogfooding. Co-founder Ivan Zhao described an early phase he calls Notion’s "lost years," where the team was building "for ourselves, not for the world." Dogfooding without enough external customer contact almost killed the company. The fix wasn’t less dogfooding — it was pairing it with deep customer immersion.5

Going deep #

Beyond the "just use your product" mantra, a few things help you actually go deep. You’ll notice a lot of overlap with plain good product development and business building — that’s a feature, not a bug.

Tighten the feedback loops. Mary works for you and has found a bug. How does she report it? Does she get notified when it’s fixed, or going to be fixed? Does she get recognized for her contribution? And what about Barry, who doesn’t work for you but found the same bug — should he go through a separate process? Probably not.

Keep the process simple, organized, and as low-effort as possible. A Slack channel for bugs can be fine, but how do you reconcile customer support requests, GitHub issues, and other sources? AI can help flag duplicates, ask for missing info, and triage — but the goal is not a giant mess of half-routed signal.

Does everyone in the org use the product? Especially leadership. This will usually make or break the process. Diverse teams with diverse backgrounds testing the same product is invaluable.

Does your product even allow for near-constant usage? If your product books hotel reservations, dogfooding is still important — but it’s likely not constant enough to receive the full benefit. (More on tricky products below.)

Dogfood as pre-release feedback. Do you have a culture of experimentation, and acceptance of (measured) failure? This is often difficult to attain, especially in regulated environments, but it compounds beautifully when it works — as demonstrated by Anthropic.4 The ability to internally test a new concept with a sizeable internal quorum helps you catch duds and quickly identify hits (ahem Claude Code ahem).

Valve: the Cabal and silent playtesting #

Valve’s "Cabal" is the gold standard of going deep. For Half-Life, Valve ran 200+ two-hour playtests. A level designer and an engineer sat silently behind each tester, forbidden to speak. Ken Birdwell wrote:6

"Nothing is quite so humbling as being forced to watch in silence as some poor play-tester stumbles around your level for 20 minutes, unable to figure out the 'obvious' answer."

And on settling design disputes:

"It became obvious that any personal opinion you had given really didn’t mean anything, at least not until the next play-test session."

The lesson generalizes far beyond games: observed use beats opinion. Half-Life 2 scaled this further — three semi-independent "cabals," ~100 playtesters per chapter, playtests re-run after the art pass to confirm the gameplay still held. Naughty Dog runs the same loop, weekly, near launch.

Food for thought: dogfooding tricky products #

Some products resist dogfooding by their nature. A few angles worth thinking about:

Then there’s the elephant in the room: Howard Schultz, the former Starbucks CEO, was once asked how he got all his baristas to smile. He replied: "I hire people who smile." The point holds either way — it’s almost impossible to force someone to regularly use a product they don’t enjoy. Sometimes great dogfooding means rethinking who you hire, or having some difficult conversations.

Shopify: when the product IS the dogfood #

Shopify is the ultimate dogfood-as-origin story. Tobi Lütke built the e-commerce engine because he couldn’t find good software for his snowboard shop, Snowdevil. The shop became the proof, and the platform became a $100B+ company. The product was the dogfooding.7

Get started now! #

The cheapest competitive edge in software has always been: actually use the thing you ship. AI just made it the only edge that scales. Start small, mandate it, instrument it — and don’t confuse it for customer research.

Appendix #

1. AI dogfooding (deserves its own post) #

I'm collecting these here because the AI angle is rich enough for a separate post. Highlights for now:

2. Cautionary tales #

4. Memorable quotes #

5. Sources #

Origin of "dogfooding" — Microsoft (1988) and Apple (1980) #

How Anthropic teams use Claude Code #

OpenAI / Codex adoption #

Cursor and GitHub Copilot #

Valve, Naughty Dog — playtesting as dogfooding #

Figma, Slack, Shopify, 37signals — modern case studies #

Linear, Atlassian, PostHog, Lyft — operational patterns #

Cautionary tales #

Footnotes #

  1. Dylan Field — "Design: Meet the Internet" (Medium). ↩
  2. GeekWire — "Origin of 'Eat Your Own Dog Food'"; also Wikipedia. ↩
  3. Apple’s "No More Typewriters" memo (Feb 1, 1980 — Internet Archive); also EDN coverage. ↩
  4. How Anthropic teams use Claude Code (PDF); Cat Wu and Boris Cherny interviews on Every and Pragmatic Engineer; Mike Krieger via IT Pro. ↩
  5. Ivan Zhao on Notion’s "Lost Years" (Wantrepreneur Show). ↩
  6. Ken Birdwell — "The Cabal: Valve’s Design Process for Creating Half-Life" (Game Developer, 1999); "Valve’s Design Process for Half-Life 2" (GDC 2008); Lemarchand interview (Games User Research). ↩
  7. "From Coder to Commerce King: How Tobias Lütke Built Shopify". ↩
  8. Altman, OpenAI DevDay 2025 keynote (Cybernews); VentureBeat coverage; OpenAI Sora-for-Android post. ↩
  9. Pragmatic Engineer — "Real-world engineering challenges: building Cursor". ↩
  10. Build a personal organization command center with GitHub Copilot CLI (GitHub Engineering Blog). ↩
  11. Sinofsky, Hardcore Software — "Platform Disruption While Building Windows 7". ↩
  12. "How we do dogfooding at PostHog" — see caveats section. ↩