Dogfooding for R&D

Dogfood everything

The best way to understand how GitLab works is to use it for as much of your job as possible. Avoid dogfooding antipatterns and try to find ways to leverage GitLab (instead of an external tool) whenever possible. For example: try to use Issues instead of documents or spreadsheets and try to capture conversation in comments instead of Slack threads.

As a PM, but also as any GitLab team member, you should actively use every feature, or at minimum, all the features for which you are responsible. That includes features that are not directly in GitLab’s UI but require server configuration.

If you can’t understand the documentation, or if you struggle to install something, would anyone else bother to do it? This hands-on experience is not only beneficial for understanding what the pain points are, but it also helps you understand what can be improved and what features GitLab is missing.

When do we dogfood?

The Dogfooding process should begin during the validation phase of the Product Development flow. PMs should set up conversations with internal customers to gather their feedback on the problem and possible solutions. This helps the group by providing feedback from teams deeply familiar with GitLab, and allows internal customer requirements to be considered from the beginning. We’ve seen that features that have been dogfooded internally are more successful than those that have not gone through this process, and internal usage is required to achieve Viable maturity.

When a feature is minimal and moving toward viable, designated GitLab team members (and anyone else interested!) should be using the feature extensively and actively providing feedback to the PM and team developing it.

When a feature is viable and moving toward complete, designated GitLab team members should be using the feature exclusively, and actively providing direct feedback to the PM in situations where exclusive use is not possible.

Exceptions to dogfooding:

When a feature is planned and/or moving towards minimal, dogfooding is not required; although, the initial conversation to seek feedback from internal customers should occur.

GitLab the company works in a specific way, but GitLab the product is designed to work for lots of different companies and personas. When we have validated through research that the wider GitLab community wants a feature that doesn’t align with how our organization works, dogfooding is not required.

For R&D Team Members

As an R&D organization, it’s also our responsibility to ensure that the entire company dogfoods our product. This is aligned to understanding our customers, delivering a product that we love ourselves, and using our own product to surface improvements..

1. Add the Dogfooding and Dogfooding::Promote Feature label to the issue tracking the feature. Ensure a feedback thread has been started on the issue.

   Note: In the future we intend to add tracking and visibility to see what features are requesting dogfooding and the engagement associated.