Product categories

  1. You are here:
  2. Handbook
  3. Product
  4. Product categories

On this page

Interfaces

We want intuitive interfaces both within the company and with the wider community. This makes it more efficient for everyone to contribute or to get a question answered. Therefore, the following interfaces are based on the product categories defined on this page:

Hierarchy

The categories form a hierarchy:

  1. Departments: Dev, Ops, Sec, and Enablement. Maps to departments in our organization structure. At GitLab the Dev and Ops split is differently than the infinity loop suggests because our CI/CD functionality is one codebase, so from verify on we consider it Ops so that the codebase falls under one department.
  2. Stages: Stages start with the 7 loop stages, then add Manage and Secure to get the 9 (DevOps) value stages, and then add the (Enablement) team stage. Values stages are what we all talk about in our marketing.
  3. Group: A stage has one of more groups. Each of the groups has a dedicated backend engineering team. Within shared functions, like quality and product management, individuals are paired to one or more stages so that there are stable counterparts.
  4. Categories: A group has one or more categories. Categories are high-level capabilities that may be a standalone product at another company. e.g. Portfolio Management. To the extent possible we should map categories to vendor categories defined by analysts. There are a maximum of 8 high-level capabilities per stage to ensure we can display this on our website and pitch deck. There may need to be fewer categories, or shorter category names, if the aggregate number of lines when rendered would exceed 13 lines, when accounting for category names to word-wrap, which occurs at approximately 15 characters.
  5. Features: Small, discrete functionalities. e.g. Issue weights. Some common features are listed within parentheses to facilitate finding responsible PMs by keyword. Features are maintained in features.yml.

A group might have the same scope as a stage but containing all the categories in them, might contain only a single category, but most will form part of a stage and have a few categories in them. Only in case their scope is the same as a stage or category can they have the same name. Group names can be a summation of the categories they cover.

Every category listed on this page must have a link, determined by what exists in the following hierarchy:

Marketing product page > docs page > epic > label query > issue

E.g if there's no marketing page, link to the docs. If there's no docs, link to the Epic. etc.

Solutions can consist of multiple categories as defined on this page, but there are also other ones, for example industry verticals. Solutions typically represent a customer challenge, how GitLab capabilities come together to meet that challenge, and business benefits of using our solution.

Capabilities can refer to stages, categories, features, but not solutions.

Adding more layers to the hierarchy would give it more fidelity but would hurt usability in the following ways:

  1. Harder to keep the interfaces up to date.
  2. Harder to automatically update things.
  3. Harder to train and test people.
  4. Harder to display more levels.
  5. Harder to reason, falsify, and talk about it.
  6. Harder to define what level something should be in.
  7. Harder to keep this page up to date.

Changes

The impact of changes to stages and groups is felt across the company. Merge requests with changes to stages and significant changes to categories need to be approved by:

  1. Head of Product
  2. VP of Engineering
  3. CEO needs to merge the change

DevOps Stages

DevOps Loop

Dev department

Manage

Product Manager: Jeremy Watson | Product Marketing Manager: John Jeremiah | Engineering Manager: Liam McAndrew | Frontend Engineering Manager: Dennis Tang (Interim) | UX Designer: Chris Peressini | Content Marketing: Suri Patel | Technical Writer: Evan Read

Plan

Product Manager: Victor Wu | Product Marketing Manager: John Jeremiah | Engineering Manager: Sean McGivern | Frontend Engineering Manager: André Luís | UX Designer: Pedro Moreira da Silva | Content Marketing: Suri Patel

Create

Product Manager: James Ramsay | Product Marketing Manager: John Jeremiah | Engineering Manager: Douwe Maan | Frontend Engineering Manager: André Luís | UX Designer: Jeethu | Content Marketing: Suri Patel | Technical Writer: Marcia Ramos

Ops department

Verify

Product Manager: Brendan O'Leary | Product Marketing Manager: William Chia | Engineering Manager: Elliot Rushton | Frontend Engineering Manager: Tim Z (Interim) | UX Designer: Dimitrie Hoekstra | Content Marketing: Aricka Flowers | Technical Writer: Evan Read | Internal Customers: Quality Department, UX Department

Package

Product Manager: [Joshua Lambert (interim)] | Product Marketing Manager: William Chia | Engineering Manager: Marin Jankovski (Interim) | Frontend Engineering Manager: Clement Ho | UX Designer: Hazel | Content Marketing: Aricka Flowers | Technical Writer: Axil | Internal Customer: Distribution Team

Release

Product Manager: Jason Lenny | Product Marketing Manager: William Chia | Engineering Manager: Darby Frey | Frontend Engineering Manager: John Hampton | UX Designer: Dimitrie Hoekstra | Content Marketing: Aricka Flowers | Technical Writer: Marcia Ramos | Internal Customers: Distribution Team, Gitter, Security Department

Configure

Product Manager: Daniel Gruesso | Product Marketing Manager: William Chia | Engineering Manager: Dylan Griffith | Frontend Engineering Manager: Tim Z (Interim) | UX Designer: Taurie | Content Marketing: Aricka Flowers | Technical Writer: Evan Read | Internal Customers: Site Availability Engineering, Site Reliability Engineering

Monitor

Product Manager: Joshua Lambert | Product Marketing Manager: William Chia | Engineering Manager: Seth Engelhard | Frontend Engineering Manager: Clement Ho | UX Designer: Amelia | Content Marketing: Aricka Flowers | Technical Writer: Axil | Internal Customer: Infrastructure Department

Sec department

Secure

Product Manager: Fabio Busatto | Product Marketing Manager: Cindy Blake | Engineering Manager: Philippe Lafoucrière | Frontend Engineering Manager: Tim Z (Interim) | UX Designer: Andy | Content Marketing: Erica Lindberg | Technical Writer: Axil | Internal Customer: Security Department

Defend

Product Manager: Fabio Busatto | Product Marketing Manager: Cindy Blake | Engineering Manager: Philippe Lafoucrière | Frontend Engineering Manager: Tim Z (Interim) | UX Designer: Andy | Content Marketing: Erica Lindberg | Technical Writer: Axil | Internal Customer: Security Department

Enablement department

Enablement

Maturity

Not all categories are at the same level of maturity. Some are just minimal and some are lovable. See the category maturity page to see where each category stands.

Solutions

GitLab also does the things below that are composed of multiple categories.

  1. Software Composition Analysis (SCA) = Dependency Scanning + License Management
  2. Application Performance Monitoring (APM) = Metrics + Tracing + Real User Monitoring (RUM)

Other functionality

This list of other functionality so you can easily find the team that owns it. Maybe we should make our features easier to search to replace the section below.

Other functionality in Manage

Control group

Framework group

Other functionality in Plan

Other functionality in Create

Other functionality in Verify

Other functionality in Secure

Edit this page — please contribute. Creative Commons License