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.
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.
As a Product organization, it's also our responsibility to ensure that the entire company dogfoods our product. We do this by:
Working with internal stakeholders comes with the added benefit of getting immediate feedback that reduces cycle times and de-risks early investments in new categories and features. Beyond feature velocity, internal dogfooding saves the money that we would spend on third-party tools.
Internal users can help quickly identify where workflows might break down or where potential usability or performance issues must be explored. We should heavily weigh internal feedback to shape our perspective on customer needs, and then compare it to what we know about both large and small customers (and if we’re unsure, then we should proactively ask).
We define specific DRIs in the categories.yml file. Below are the responsibilities of an Internal Customer DRI:
Dogfoodingand spur a discussion with PM. This label should never be removed so that the decision-making process gets memorialized on the Dogfooding board. When creating a Dogfooding issue, consider using the Dogfooding Issue Template for existing features that need Dogfooding or the Feature Proposal template for new features.
Dogfooding::Build in GitLabwhen a new feature should be built into GitLab
Dogfooding::Rebuild in GitLabwhen there is existing work (outside of GitLab) that needs to be rebuilt inside of GitLab
Dogfooding::Keep Outside GitLabwhen a feature is okay to build outside GitLab because they don't align with product vision
Dogfooding::Use Existing Feature: when a feature already exists, but isn't being used internally yet for whatever reason
Dogfoodinglabel when adding the new scoped label.
Build in GitLabor
Rebuild in GitLab:
Use Existing Feature:
Dogfooding::Promote Featureand promote these features in the weekly Product call and in other relevant channels
Dogfooding::Build in GitLabor
Dogfooding::Rebuild in GitLabare getting prioritized appropriately
Dogfooding::Keep Outside GitLabto understand why these features are explicitly staying out of the product
Dogfooding::Use Existing Featureto help their PMs promote these issues for internal usage
To see all the
Dogfooding work that is happening, here is a board that collects all the scoped labels.
Check out this 10 minute discussion about dogfooding:
Most of GitLab is configured through the file
gitlab.rb. It's tempting to
add a new parameter in this file - it's easy, fast to do, and won't require
adding a new UI element to allow the configuration of this new setting. However,
changing this file requires you to reconfigure GitLab. To do that, you have to
login to your server and type in commands to reconfigure your instance,
possibly multiple times if you have more than one server.
This is not something that we can ask our customers to do. Only by using your own product and features will you realize that some practices should be avoided as much as possible.