Blog

Dogfooding in Software Development: Eat Your Own Code

April 17, 2025
 • 
3
Share this article

What is Dogfooding?

Ever been told to “Eat your own dogfood,“ and wondered what it meant. Does your boss really want you to wolf (or woof) down some kibble?

Probably not. In software development, dogfooding refers to the practice of using your own products.

The phrase “eating your own dog food” is believed to have originated in the 1980s. One of the earliest and most cited uses comes from Microsoft, where the term gained popularity as employees were encouraged to use the company’s products internally. However, its true origin may trace back even earlier to pet food commercials in the 1970s. For instance, Kal Kan Pet Food reportedly claimed that its executives ate their own dog food to prove its quality.

Benefits of Dogfooding

Using your own software product before releasing it to users has a number of strategic and practical advantages:

  • Improved Product Quality – By using the product internally, developers and stakeholders are more likely to spot bugs, UX issues, or performance hiccups before the software goes public. Since they’re closer to the codebase, they can often recognize the source of the problem and quickly implement a fix.
  • Empathy with End Users – Dogfooding forces teams to experience the product as customers would. This helps bridge the empathy gap and ensures that user experience isn’t merely theoretical.
  • Internal Buy-In – When employees use and believe in the product, it can lead to a stronger organizational culture, pride in the work, and more consistent feedback loops.
  • Faster Feedback Cycles –Internal users are accessible, leading to quicker iterations, improved features, and better refinement ahead of external release.

Risks of Dogfooding

Despite its benefits, dogfooding isn’t without its risks and challenges. Internal users may not represent the diverse needs and contexts of real customers. This can lead to tunnel vision, where products are optimized for insiders rather than the actual user base. Edge cases that are important to customers can be overlooked, and since the product is "good enough" for internal teams there’s a temptation to bypass broader usability testing or customer feedback.

Therefore dogfooding should never eclipse user testing. Similarly, while internal teams' needs may provide ideas for the development of new features, the Product Manager should not rely on dogfooding for feature development and prioritization.

Best Practices for Effective Dogfooding

To avoid these traps, you can put guardrails around your dogfooding to ensure it produces useful insights:

Define Clear Use Cases

Ensure internal use closely matches the most critical customer workflows.

Include Adjacent Teams in Dogfooding

The dev team, especially the one that developed the feature, shouldn’t be the only ones testing it out. Include other teams, including non-development teams in your dogfooding. If the dev team is always on a Beta version, ensure that other teams are using the production version.

Collect Structured Feedback

To get the most out of dogfooding, use surveys, analytics, and user interviews internally just as you would externally. Make it easy for employees to give candid feedback without fear of judgment or hierarchy.

Complement your Dogfooding with External Testing

Dogfooding should be one layer of testing, not a replacement for beta testing or user research.

Examples of Dogfooding in Action

So who uses dogfooding? In a now famous story, Microsoft bigwig sent a test manager an email titled "Eating our own Dogfood", challenging him to increase internal usage of the company's product. Companies like Google and Slack are also known to use dogfooding.

Dogfooding at HeroCoders

Here at HeroCoders – makers of Checklists for Jira and Clockwork Pro for Jira Time Tracking – we’re also fond of eating our own code. Our dev team uses global checklists to ensure new features work as expected in multiple environments, and that new code is released to all of the appropriate instances. Local checklists are created on individual stories and tasks to break work into bite-sized pieces.

And of course, we use Clockwork for time tracking. When the accountants recently told us that there was new data we needed to track, we didn’t flinch. It was a simple matter of adding a custom field, a new breakdown on our Jira time tracking reports.

Dogfooding remains a time-tested and effective approach in software development that can enhance quality, foster user empathy, and build organizational pride. But like any tool, it works best when used alongside other testing and feedback strategies. So, yes, eat your own dogfood.  But don’t eat only your own dogfood.