Also called: Eating Your Own Dog Food, Drinking your own Champagne
See also: Beta Launch, Guerilla User Testing
Difficulty: Intermediate
Evidence strength
Relevant metrics: Internal bug reports, Time‑to‑fix, Employee satisfaction score
Validates: Feasibility, Usability
How: Roll out pre‑release versions of your product for employees to use in their daily work. Capture structured feedback, log bugs, and measure adoption to guide fixes before external launch.
Why: Internal use exposes functional gaps and usability problems under real workloads and builds a shared understanding of the product across teams.
“Eating your own dog food,” often shortened to dogfooding, means that the people who build a product rely on it themselves before asking anyone else to do so. The practice has become a proven way to raise quality, sharpen empathy, and keep teams aligned. This chapter traces dogfooding’s history, explains how to organise a repeatable programme, and shows where its value ends.
Microsoft popularised the term in an email titled “Eating our own dogfood” in 1988, and the label has stuck ever since. In the email internal teams were required to run pre-release versions of Windows and Office to catch issues early. The results—earlier defect discovery, stronger feature ideas, and higher release confidence—spread the phrase “dogfooding” across the industry.
Today companies such as GitLab, Slack, and GitHub treat internal use as a standard phase of development. It sits next to quality assurance, usability research, and beta testing, giving teams a daily test of whether the product meets real needs.
Why internal use changes the conversation
Once teams depend on their own tools, they confront the question Would we choose this product ourselves? The answer becomes visible through several effects:
- Immediate friction. Usability problems interrupt daily work and are fixed sooner.
- Shared language. Designers, engineers, and support staff discuss the same interface and the same pain points.
- Deeper ownership. A flaw that affects customers now affects the people responsible for it.
GitLab showed this dynamic during the launch of GitLab Duo. By using AI features—code suggestions, vulnerability fixes, and test generation—in real development tasks, staff refined both the feature set and the user experience long before public release.
Setting up a Dogfooding programme
Dogfooding works best when it’s intentional. Ad hoc use is better than nothing, but structured internal use yields more actionable insight. Common practices include:
- Running internal builds across all departments, not just engineering.
- Providing lightweight channels for reporting friction (Slack threads, GitLab issues, embedded feedback forms).
- Documenting and prioritizing internal feedback similarly to customer input.
- Treating internal teams as users, with onboarding, documentation, and support.
Learning from Slack
Slack’s compute platform case shows how this works in practice. Their infrastructure team adopted a mindset of treating internal platforms like customer-facing products. They didn’t just passively use their tools—they proactively applied product thinking to enhance reliability, user experience, and team workflows. Slack’s developers became early adopters of the internal platform, using it to deploy their own services and build real applications. This daily use allowed them to experience issues like unclear documentation, brittle onboarding flows, and edge-case performance gaps firsthand.
The team then instituted a structured feedback loop: engineers shared input via surveys and interviews, and usage data was collected to identify drop-off points and friction areas. Product managers reviewed these inputs alongside error logs and support requests to prioritize roadmap decisions. As a result, the platform team was able to fix bugs more efficiently, streamline onboarding for new internal users, and create a service that scaled smoothly as Slack grew.
What’s particularly powerful about this example is how dogfooding wasn’t an afterthought—it was a foundation. It elevated the internal platform team’s visibility, fostered trust with other engineering squads, and built internal credibility. It also clarified the performance expectations and service boundaries for Slack’s platform—knowledge that eventually fed into better external developer tools and documentation. Their infrastructure team used its own developer tools daily and treated engineers like customers, gathering ongoing feedback, running interviews, and iterating on usability and performance.
Short‑term sprints and long‑term dogfooding habits
Dogfooding can be scoped in two ways:
- Short-term dogfooding typically happens in a fixed time window before release. Teams test new features over one or two sprints, with feedback shaping the final launch.
- Long-term dogfooding embeds internal usage as an ongoing habit. Teams use daily builds, log real-time feedback, and make dogfooding part of company culture.
The best programs use both: short-term sprints for focused validation, and long-term use for continuous quality improvement and deeper alignment.
| Rhythm | Focus | Typical Duration | Primary Goal |
|---|---|---|---|
| Short‑term | Specific feature before release | 1–3 weeks | Remove show‑stoppers |
| Long‑term | Daily use of live builds | Continuous | Provide steady insight and trends |
Strong teams combine both: bursts catch urgent problems; habits guide roadmap direction.
Metrics of Success
Measuring the success of a dogfooding initiative isn’t always straightforward, but some indicators include:
- Volume and frequency of internal feedback submissions.
- Number of bugs or UX issues identified before public release.
- Time from internal discovery to fix deployment.
- Internal Net Promoter Score (NPS) or satisfaction scores.
- Reduction in support tickets post-launch.
Over time, improvements in product quality, reduced churn, and faster iteration cycles can also signal the long-term impact of dogfooding.
Comparing approaches to product validation
Validation is strongest when it moves gradually from the inside out, collecting evidence as each new group of users puts the product under a different kind of pressure. At the centre sit dogfooding and fishfooding—two flavours of internal testing that share a code base but answer different questions.
Dogfooding keeps the product close to its builders. Because developers, designers, and product managers rely on daily builds to do real work, workflow defects surface quickly, and fixes can ship the same day. Yet these same creators carry deep context and may subconsciously forgive awkward flows.
Fishfooding widens the lens without yet exposing the product to outsiders. Marketing, support, legal, and finance teams adopt the near‑final build and attempt to perform their routine tasks. Their distance from day‑to‑day development brings fresh eyes: they trip over jargon, uncover permission gaps, and gauge whether documentation makes sense to someone who did not write it. Fishfooding therefore acts as a bridge between the intimacy of dogfooding and the objectivity of external trials.
The table below shows how these two internal methods relate to other common forms of validation. Reading left to right—dogfooding through quality assurance—reveals a natural progression: each layer adds new perspectives while retaining what the earlier layer already tested.
| Layer | Primary Participants | Core Question | Typical Timing | Cadence | Common Tools |
|---|---|---|---|---|---|
| Dogfooding | Builders (engineering, design, product) | Does the product work for its creators under real load? | Alpha / early development | Continuous | Issue trackers, in‑app widgets |
| Fishfooding | Internal non‑creators (marketing, support, legal, finance) | Is the product clear and complete for colleagues outside the dev team? | Late alpha / pre‑beta | Time‑boxed (1–2 weeks) | Centercode, survey forms |
| Usability Testing | Recruited target users | Can representative users complete key tasks without guidance? | Any stage | Scheduled sessions | Lookback, UserTesting |
| Beta Testing | Selected external customers | Does the product deliver value in authentic environments? | Pre‑release | Weeks to months | Analytics, feedback portals |
| Quality Assurance | Dedicated QA engineers / automated pipelines | Does the product meet functional and performance standards? | Continuous | Every build | CI/CD suites, load tests |
Because each layer answers a different question, none is optional. A defect missed during dogfooding might surface in fishfooding, but only if non‑creators feel the pain; a scaling bottleneck invisible to beta customers can still trigger an automated QA alert. The safest path is therefore to add layers sequentially, verifying core workflows internally before courting external opinion.
From internal insight to organisational action
Dogfooding’s first dividends appear in code quality, but the practice changes far more than defect counts. When every department depends on the latest build, roadmaps converge, customer conversations grow more confident, and the organisation becomes reluctant to ship half‑finished work. Pride and accountability rise together because employees directly feel the consequences of their own decisions.
That intimacy also carries risk. Internal users work on powerful hardware, share deep context, and tolerate rough edges that would frustrate newcomers. Their feedback, useful though it is, can bias priorities toward workflows that matter inside the building. To stay balanced, healthy teams pair dogfooding with usability research, customer interviews, product analytics, and external betas. Common blind spots include
- untested edge devices or bandwidth constraints,
- jargon that feels natural only to insiders, and
- silent acceptance of legacy work‑arounds that mask larger design flaws.
Collecting feedback is only half the battle; turning insight into action demands discipline. Mature programmes tag each report by category—usability, performance, navigation, missing capability—link it to a backlog item with a clear owner, and display cycle time on a public dashboard. Lightweight widgets embedded in the product raise reporting volume and remove the friction of switching tools.
Extending Dogfooding across the organisation
True organisational dogfooding reaches well beyond engineering. When support staff troubleshoot real customer issues with the same interface, they file precise tickets instead of vague complaints. Marketing teams that craft campaigns inside the product refine claims that resonate, discard those that do not, and speak with authority. Sales engineers who demo live builds gain credibility through first‑hand experience.
The circle widens further when legal, finance, and HR teams perform their routine tasks in the evolving product. Legal may uncover compliance gaps before launch, finance often spots reporting errors in billing flows, and HR reveals accessibility concerns buried deep in onboarding screens. Their perspectives close gaps that core teams rarely see.
Employees outside development are also ideal proxies for future customers. Struggling to install the product or decipher terminology, they highlight missing steps, confusing labels, and inconsistent language. Addressing these issues early lowers support load and raises first‑week retention once the product reaches the market.
Some organisations institutionalise participation through company‑wide campaigns. GitLab’s “Dogfooding Week,” for example, invites every employee to exercise selected features, log observations, and compete on a public leaderboard. The event compresses months of diffuse feedback into a focused surge while development capacity is still available to act on it.
From internal confidence to public release
Many teams convert dogfooding insight into objective release gates. A product may remain internal until the company reaches a minimum Net Promoter Score, closes every critical issue surfaced during dogfooding, or completes documentation and onboarding tasks flagged by fishfooders. These criteria create a fact‑based handshake between engineering and go‑to‑market leaders, preventing wishful schedules from overriding evidence.
Maintaining that rigor over multiple cycles calls for a few durable habits:
- Integrate dogfooding into the development cadence—daily for core tools, weekly or sprintly for larger systems.
- Include every department, not just those writing code.
- Record and triage feedback with the same urgency granted to external bug reports.
- Respect internal user experience as a predictor of external churn.
Continuous use is the gold standard, yet several moments offer special leverage: early architecture reviews catch foundational gaps before they harden, pre‑launch sprints validate features under near‑real conditions, internal platform rollouts expose edge cases impossible to simulate, and periodic alignment checks restore a shared perspective when strategy drifts.
Dogfooding converts assumptions into lived experience. By making builders and stakeholders into everyday users, it surfaces defects, accelerates fixes, and grounds strategy in reality. Its power multiplies when teams recognise its limits, invite every function to participate, and pair internal insight with external research. If your organisation is not yet running on its own product, the simplest step toward improvement may be to log in and start working today. Dogfooding is rarely the final verdict, but it remains the earliest—and often the most honest—proof of readiness.
Popular tools
The tools below will help you with the Dogfooding play.
-
Centercode
A platform designed for managing internal and external beta tests, including structured dogfooding programs. Centercode supports feedback collection, participant management, analytics, and product readiness scoring.
-
LaunchDarkly
A feature flagging tool that enables teams to release features to internal users for dogfooding before public rollout. Helps with progressive delivery and risk-managed testing in real environments.
Examples
GitLab
GitLab’s policy is to dogfood every feature, such as the AI‑powered GitLab Duo suite, capturing bugs and workflow gaps ahead of general availability.
Source: about.gitlab.com
Atlassian
Atlassian teams plan and track work in Jira and Confluence, stress‑testing new functionality under real workload conditions before customer rollout.
Source: atlassian.com
Assembled
Assembled’s support team uses an early AI tool internally, revealing practical issues in live support rotations prior to launch.
Source: assembled.com
Frontegg
Frontegg runs its own SaaS integration platform for internal services, boosting ownership and shortening feedback loops.
Source: frontegg.com
Microsoft
Microsoft popularized the term “dogfooding” in the late 1980s. The company has institutionalized this practice through programs like the Microsoft Elite program, which encourages employees to use and provide feedback on pre-release versions of products such as Outlook and Windows. This internal testing helps identify bugs and usability issues before public release.
Source: instabug.com
Apple
Apple is known for its rigorous internal testing processes. Designers and engineers regularly use early versions of operating systems and applications, observing each other’s interactions to identify issues and iterate quickly. This hands-on approach ensures a high level of polish and user experience in their products.
Source: uxplanet.org
Google employs dogfooding across various products, including Google Pay and Gmail. Employees use these services internally to test new features and gather feedback, allowing the company to refine products based on real-world usage before public deployment.
Meta (formerly Facebook)
Meta utilizes dogfooding to test new features and products. For instance, employees tested the React framework internally before its public release. This practice helps in identifying potential issues and gathering valuable feedback from internal users.
Source: testdevlab.com
Lyft
Lyft requires corporate employees to spend a minimum amount of time each month as drivers. This initiative allows employees to experience the platform from the driver’s perspective, leading to insights that improve both driver and passenger experiences.
Source: testdevlab.com
IBM
IBM uses its own cloud services to monitor and manage its cloud infrastructure. This practice ensures that IBM’s tools are robust and reliable, as they are tested and validated through internal use.
Source: arxiv.org
Slack
Slack applies product thinking to its internal compute platform, treating internal tools as products. By using these tools internally, Slack identifies usability issues and iterates on solutions, enhancing the overall developer experience.
Source: slack.engineering
Related plays
- Eating your own dog food at Wikipedia
- Applying Product Thinking to Slack’s Internal Compute Platform by Javier Turegano at Slack Engineering
- Dogfooding 101: Use Your Product To Drive Internal Alignment by UserVoice Team at UserVoice
- Developing GitLab Duo: How we are dogfooding our AI features by GitLab Product Team at GitLab
- Should companies eat their own dogfood? by Work Check Podcast at Atlassian
- What is Dogfooding? A Complete Guide at Testomat.io
- Dogfooding: A Simple Practice to Help You Build Better Products at Medium
- Fishfooding vs. Dogfooding: What’s the Difference? at Centercode
- Developing GitLab Duo: How We Are Dogfooding Our AI Features at GitLab
