5.8 Dogfooding
At a Glance
Other names Eat Your Own Dog Food · Internal Use Test
In Brief
Your team uses your own product in real daily work, just as a customer would, and records every bug, friction point, and unexpected use case they hit. There is no script: you go through the actual workflows, note where things break or feel awkward, and capture ideas for improvement. The output is a firsthand issue list that formal testing often misses.
Common Use Case
Your team has built the first version of your product and you want a quick reality check before putting it in front of customers. You and your teammates use the product in your daily work for a week, noting every moment of friction, confusion, or delight so you can fix the biggest issues before anyone else sees it.
Helps Answer
- Does the product actually deliver on the value proposition?
- Is the product working correctly in real use?
- What is the minimum viable feature set?
- Where does the workflow break down or feel awkward?
Description
Using your own product is common practice among technology startups, especially when the team built the product to solve a problem they have themselves. There is no predefined script and it is not a formal quality assurance (QA) process. Its main advantage is surfacing unorthodox use cases that the requirements and QA tests never covered.
Treat the output as generative research, not an experiment. Your team is not a representative sample of your users, so dogfooding generates ideas and finds obvious breakage but cannot validate that a feature works for the people you are building for. Pair it with external Usability Testing before drawing conclusions about real-user behavior.
You cannot delegate dogfooding to an AI agent or an automated testing script. The value comes from a person encountering friction, confusion, or delight while trying to finish a real task, so AI helps with capture and synthesis but not with the using. If your product includes AI features, firsthand use matters more: you need direct experience of how the model behaves in real scenarios, where it fails, and where it produces unexpected results. Automated QA and AI-powered testing tools catch bugs, but they are not dogfooding.
How to
Prep
- Set a clear scope. Pick the workflows and personas you intend to walk through (new-user signup, daily power-user task, admin path) so the team exercises the same surfaces and you can compare notes afterward.
- Set up a low-friction capture channel. Have a place to take notes that is easy to reach and does not interrupt the workflow: a shared issue tracker, a single team-chat channel, or a running doc.
- Decide who participates. Pull in teammates outside the build team where possible. Engineers and designers carry too much prior knowledge to notice every friction point alone.
Execution
- Use the product in real work. Do not switch to a workaround when something annoys you. Record the friction and the workaround you reached for; both are data.
- Log wins and failures as they happen. Take notes whenever something works surprisingly well or falls short, and record any ideas that occur while using the product.
- Flag every hand-off. Note any point where the workflow is interrupted or another service is needed to finish the task. These hand-offs are the most common hidden friction.
- Capture context, not just bugs. Screenshot the screen, note what you were trying to do, and write down what you expected to happen.
Analysis
- Read the findings as generative, not evaluative. Your team knows the product design too well to stand in for a first-time user. This is especially true for the new-user flow, where internal users carry far more prior knowledge and expectation about signup and onboarding than any real user would.
- Watch for missing edge cases. A team that is not diverse may never exercise the product the way users with disabilities or users from other backgrounds would, and thus overlook substantial parts of the experience. This grows as the product scales beyond its initial niche audience.
- Surface patterns, not gripes. When multiple team members dogfood the product, collect and sort the notes with Card Sorting, stack ranking, or other standard UX methods rather than reacting to individual complaints.
- Confirmation bias Creators of a product can subconsciously avoid situations and use cases they know are incomplete or buggy, leaving a positive impression that the product works according to the specification even if it has serious flaws in ordinary usage.
- Expert blind spot Team members know the product too well to notice friction a first-time user would hit immediately. Recruit teammates outside the build team or pair internal testing with external usability testing.
Learn more
Case Studies
Microsoft, Lyft, Facebook: Dogfooding roundup
A practitioner roundup of dogfooding programs, including Microsoft’s 25,000+ employee Elite program, Lyft’s “four hours per quarter” driver shift requirement for executives, and Facebook’s internal block on desktop access during its Android push.
Twitter: Odeo’s internal SMS tool
The first Twitter prototype was an internal service for Odeo employees built by Jack Dorsey and Florian Weber; the team’s enthusiasm and SMS-bill spikes were the demand signal that prompted the July 2006 public launch.
PostHog: Dogfooding drove the data warehouse and surveys
PostHog’s internal use of its own product shaped major features: the data warehouse came from engineers needing PostHog to query Stripe and HubSpot, and the surveys feature began as an internal popup the product team built to streamline user-interview booking.
Bubble: Building Bubble on Bubble
Bubble built its website (everything except the editor) on its own no-code platform, turning internal developers into demanding users and creating a “forcing function” that drove the platform to support complex multi-page apps.
Microsoft: From “Eating our own Dogfood” memo to 20,000-node network
Paul Maritz’s 1988 email to LAN Manager test manager Brian Valentine, titled “Eating our own Dogfood,” coined the term; Windows NT later involved 200+ developers running daily builds, and by 2005 InfoWorld reported Microsoft running its 20,000+ node international network on 99% Windows technology.
Lyft: Mandatory driver shifts for corporate
Lyft requires corporate employees to drive as part of the platform, forcing leadership to experience the supply-side product and surfacing driver-facing UX issues that internal dashboards miss.
CrowdStrike: Dogfooding as post-outage remediation
Following the July 2024 worldwide outage, CrowdStrike’s Adam Meyers testified to Congress that increased internal dogfooding of agent updates was part of the company’s remediation plan — a rare case of dogfooding as regulatory commitment.
Frontegg: Running on its own Entitlements Engine
Frontegg uses its own Entitlements Engine to manage subscription plans and permissions for its own products, so internal subscription changes continuously validate the same engine customers depend on.
Further reading
- Intercom: The Danger of Dogfooding
- PostHog: How We Do Dogfooding (with Examples)
- PostHog: Why Every Team Member Should Be Dogfooding
- Wikipedia: Eating Your Own Dog Food — History and examples of the practice
- Eric Ries, The Lean Startup (Crown Business, 2011, ISBN 978-0307887894) — frames continuous internal use of a product as part of the build-measure-learn loop.
Got something to add? Share with the community.
