Dogfooding for Product Managers

1. You are here:
2. Handbook
3. Product Handbook
4. Product Processes
5. Dogfooding for Product Managers

On this page

• Dogfood everything
  • When do we dogfood?
  • For Product Team Members
  • Internal Customer DRIs
  • Dogfooding Process
    • Example: configuring GitLab

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 Product Team Members

As a Product organization, it's also our responsibility to ensure that the entire company dogfoods our product. We do this by:

1. Promoting features internally when they are ready for everyday use to get as many internal users as possible. This is particularly valuable when you can get relevant teams using your feature in their daily work. This can be done by recording a demo of the new functionality and sharing it with the team, running through examples of usage on Product calls, or identifying current workflows or processes the feature could help improve.
2. Including top internal user issues in the relevant category epics when they align with our strategy.
3. Maintaining a set of internal customer DRIs who represent GitLab team members who use GitLab for the purposes of developing and operating GitLab and GitLab.com.

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).

Internal Customer DRIs

We define specific DRIs in the categories.yml file. Below are the responsibilities of an Internal Customer DRI:

1. Actively work to improve dogfooding of the features within your internal function and provide proactive feedback to the product managers
2. Be the authoritative voice on what is required to begin dogfooding a feature within your function, and the combined input from your function into prioritization
3. Respond to issue mentions in a timely fashion
4. Periodic meetings between DRI and product development group
5. Stay up to date on the changes in that feature area (i.e. watch the kickoff video / read the release post)

Dogfooding Process

1. Any GitLab team member can create an issue labeled Dogfooding and 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.
2. PMs will consider the issue, make an explicit decision, and add an appropriate label for next steps:
   1. Dogfooding::Build in GitLab when a new feature should be built into GitLab
   2. Dogfooding::Rebuild in GitLab when there is existing work (outside of GitLab) that needs to be rebuilt inside of GitLab
   3. Dogfooding::Keep Outside GitLab when a feature is okay to build outside GitLab because they don't align with product vision
   4. Dogfooding::Use Existing Feature: when a feature already exists, but isn't being used internally yet for whatever reason
   5. Note: Please do not remove the original Dogfooding label when adding the new scoped label.
   6. Note: A good rule of thumb when considering effort to build in GitLab compared to building a tool outside is to use the '5x' rule. The '5x' rule states that if the effort to build the tool inside of GitLab is less than five times the effort to build it outside of GitLab, you should choose to build it inside of GitLab.
3. If the decision is to Build in GitLab or Rebuild in GitLab:
   1. PMs will provide an estimate of when a feature can be delivered, and Internal customers should be prepared to contribute to that effort in order to accelerate delivery.
   2. Internal Customers can track the progress of the issue through the Product Development flow
4. If the feature existed and was identified as Use Existing Feature:
   1. PMs should interview team members to understand why they weren't using that feature already
   2. Based on that feedback, the PM should create and execute a plan to solve those problems, such as:
      • Creating additional documentation in the handbook or product docs site
      • Recording walkthroughs or demos of the feature
      • Writing a blog post about how the feature works or can be used to solve a problem
5. Finally, when the feature is ready for internal consumption:
   1. PMs should change the label to Dogfooding::Promote Feature and promote these features in the weekly Product call and in other relevant channels
   2. Product Directors/Group managers should be actively promoting these features to other leaders throughout the company
   3. Designated team members should work to provide immediate feedback to ensure the feature is serving our team's needs
6. On an ongoing basis, product Directors/Group managers should be reviewing the Dogfooding Board to:
   1. Ensure that issues marked as Dogfooding::Build in GitLab or Dogfooding::Rebuild in GitLab are getting prioritized appropriately
   2. Be aware of new issues marked as Dogfooding::Keep Outside GitLab to understand why these features are explicitly staying out of the product
   3. Be aware of new issues marked as Dogfooding::Use Existing Feature to 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:

Example: configuring GitLab

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.