The Product Manager Role at GitLab

On this page, you’ll find an overview as well as links to helpful resources for working as a product manager at GitLab. To better understand how we evaluate a product manager’s work at GitLab, please visit Product Management CDF and Competencies

Principles - Processes - Categories - GitLab the Product - Being a PM - Leadership

Product Organizational Structure

The GitLab Product team includes team members at various levels of Product Management job titles and Product Management - Leadership job titles. They map across our organizational levels with scope at various points in our product hierarchy outlined in the table below.

• The product org abides by GitLab’s layer structure. Sometimes, there can be instances where peers across layers don’t have the same title.

Working as a PM at GitLab

Responsibilities

Your job as a PM is outlined in Product Manager Responsibilities

Getting started as a PM at GitLab

The first thing to do is to familiarize yourself with the following handbook pages

• Product Principles
• Product Processes
• Product Manager Responsibilities
• Product Manager Career Development Framework
• Product Development Flow
• Product Development Timeline
• Product Management Learning & Development
• GitLab Values

As a GitLab Product Manager, your product scope is huge! It may seem daunting at first, but GitLab is constantly iterating on our processes and organization so that you can be successful. Since everything is in draft, please make a proposal to improve things.

As a PM you may be extremely busy if you try to do everything that people ask you to do. This is not our expectation for the role. We do expect you to prioritize expertly and be a manager of one. And remember what your core responsibilities are! If you find yourself drowning in To-Dos, take a step back, prioritize, push-back, and focus your energy on the most important things.

Some helpful reminders:

• As a PM, you’re the person that has to kick-off new initiatives. You’re not responsible for shipping something on time, but you are responsible for taking action and setting the direction. Be active everywhere, over-communicate, and sell the things you think are important to the rest of the team and community.
• As a PM, you need to set the bar for engineering. That is, to push engineering and the rest of the company. You almost want engineering to complain about the pace that product is setting. Our default instinct will be to slow down, but we can’t give in to that.
• As a PM you don’t own the product; ask other people for feedback and give team members and the community the space to suggest and create things without your direct intervention. It’s your job to make sure things are decided and planned, not come up with every idea or change.

Where should you look when you need help?

• The first thing you should do is read this page carefully and the pages linked from this page.
• Most answers can also be found in the handbook. If you can’t find the answer, please add a proposal!
• You can ask questions related to Product in the #product Slack channel.
• General questions should be asked in #questions.
• Specific Git related questions should be asked in #git-help.
• If you have problems with a MR, ask in #mr-buddies.
• HR questions should be asked in HelpLab.
• Anything Release Post related can be found in the Release Post handbook and #release-post

Job Requirements

The job requirements and expectations for Product Managers, Sr. Product Managers, and Principal Product Managers, Group Manager, Product Management Director of Product and VP of Product are outlined in our job families pages.

As product managers progress in their product career, we encourage our product managers to take on new challenges by moving to new product areas. Alternatively, IC PMs are encouraged to apply for roles in the management track and vice versa.

The progression of responsibilities allocation between tactical, operational and strategic in product roles is well illustrated by this chart.

Source File. Note - Thanks to Melissa Perri for the inspiration

Important dates PMs should keep in mind

4th of the Month:

Draft of the issues that will be included in the next release. Start capacity and technical discussions with engineering/UX.

12th of the Month:

Release scope is finalized. In-scope issues marked with milestone Kickoff document is updated with relevant items to be included.

15th of the Month:

Group Kickoffs calls recorded and uploaded by the end of the day.

Also see Product Development Timeline.

Scope of responsibilities

The product team is responsible for iteration on most of GitLab’s products and projects:

• GitLab CE and EE
• GitLab.com
• about.gitlab.com
• customers.gitlab.com
• version.gitlab.com

This includes the entire stack and all its facets. The product team needs to weigh and prioritize not only bugs, features, regressions, and performance, but also architectural changes and other aspects required for ensuring GitLab’s excellence. Product managers are the DRIs for overall work prioritization but work collaboratively with their EM, UX, and QEM stable counterparts to ensure the right priorities from each work type are considered as each has a different DRI.

Learning and Development for Product Management

We have a library dedicated to collecting and highlighting the best resources to support the growth and success of product managers in doing their job at GitLab as well as beyond, to achieve their long term career goals. We encourage product managers to work with their managers to identify areas for improvement, and leverage the learning and development for product management resources accordingly.

Product Manager Onboarding

Product Manager onboarding consists of 2 related issue templates.

GitLab People Connect Onboarding Issue is generated by People Connect at around 4 business days prior to the start date of the new hire. More details can be found on the GitLab Onboarding Processes. The issue will be assigned to the hiring manager, who will after performing their tasks, assign it to the new product manager hire. There is a product specific section in this issue that includes clerical product tasks, i.e. schedule introductory calls with your team, that need to be completed within the first 4 weeks. The hiring manager can ping the assigned People Connect Team member in the issue or reach out for help in HelpLab. The product manager should not spend more than 4 weeks on this general onboarding and consult with their manager to prioritize the items in the template as needed to manage the time commitment.

Additionally, the product team has the First 100 days template.

The hiring manager will prep/personalize the First 100 days template. We encourage these issues to default to public per our values but they may be marked confidential if there is any sensitive or personal data per the manager’s discretion. The First 100 days issue should be open for the new product manager on their start date. It isn’t expected that they get started on this issue, but it is intended to give them a general idea of what is coming. Generally, the First 100 days issue kicks off around the start of the new milestone, around 2-4 weeks after the product manager’s start data. This timing is intended to help to allow enough time for tactical/general onboarding, before the new product manager starts to figure out what their first 100 days in “office” looks like more strategically. However, the timing/content of the first 100 days is ultimately up to the product manager and their manager to agree upon.

The new hire should also participate in defining and adding to the goals of the First 100 days template. It is recommended that the manager leverage this goal-oriented onboarding issue for the new product managers first CDF review, to effectively align teammates in supporting the PM as they settle into their role at GitLab. Take a look at these first 100 days onboarding issues as examples: 3291 and 2809.

We use two templates, so the Product Manager can focus on GitLab onboarding for the first month with more urgent, tactical tasks. As the new Product Manager becomes more familiar with GitLab they can transition to more strategic and less time-sensitive onboarding tasks in their first 3 months at GitLab.

Onboarding issues can be tracked in the Product Onboarding Issue Board.

Product Manager Onboarding Buddy

As part of onboarding a new hire will be given an Onboarding Buddy. As a Product Manager onboarding buddy there are many processes and resources to share with the new hire. A list of tasks and resources specific to Product Managers can be found here

Interviewing Product Management Candidates

A unique and important step in the interview process for Product Management candidates is our Deep Dive Interview. The goal of this interview is to understand the candidate’s ability to communicate a long term vision as well as a short term MVC, both verbally during the interview itself, and written via two follow up issues. Once the issues are ready for you to read, it is an opportunity to provide feedback and see how the candidate responds to that feedback.

You can find more information and instructions on the Deep Dive interview here(internal only). For information on our hiring process, head over to our hiring handbook pages. |

Taking Time Off

Team members are strongly recommended to take two weeks of consecutive time off a year. Extended leave longer than the no ask, must tell GitLab paid time off is common, especially for parental leave. Leaving for a longer period of time can be daunting, but it is critical to ensure your rest ethic meets your work ethic and also to ensure we don’t have single points of failure in the company. Here are a few suggestions for product managers to help plan for this time.

On a high level, these are the two most important things to do:

1. Communicate your time off
2. Create a PM coverage issue (details below)

Creating a PM coverage issue

You can use this issue template to define handshake responsibilities. For extended leave, it is important to find one or more Directly Responsible Individuals (DRIs) that will be able to make product decisions while you are away. This may be your manager, another PM, or maybe the engineering manager for your team. The coverage issue should contain all the necessary information for the DRIs to make good decisions in your absence, so please make sure to include as much detail as needed.

In addition to creating the issue, it may be useful to have a specific handover meeting to ensure that everyone is on the same page before you leave.

It is recommended to work with your manager and Quad members when considering cross-functional teammate capacity for a coverage task assignment. For example, while it’s optimal for PM, EM, and PDs to assist in covering for each other given their shared knowledge of their product area including customers and users, UX teammates may or may not have the bandwidth or expertise to take on covering PM specific responsibilities. Alternatively, it may be better for the manager of the PM or another PM in the same stage to aid in coverage. Plan to have the necessary conversations across teams and managers.

Returning from Time Off

Returning from time off can be overwhelming and daunting. You should work with your DRIs to understand what has changed during your absence and what the current priorities are. Also, communicate transparently that your response time may be slower because you are catching up. Here are some additional tips on how to return back to work after time off.

Product Shadowing with Engineering

The Product Shadowing program is loosely based on the CEO Shadow program and is designed to facilitate greater understanding between Product Managers and Engineers within a stage. The program was trialed with success in the Plan stage.

A Product Manager can host an Engineer within their stage to shadow them over two working days, or the equivalent split over multiple days to maximize experience with different functions of the role.

To propose a shadow, please create an issue in the stage issue tracker using other shadowing issues as an example (example)

Product Leadership

The separate page Product Leadership covers how to be an effective leader in the product management organization.

View page source - Edit this page - please contribute.