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 - Categorization - GitLab the Product - PM Responsibilities - Being a PM - Performance Indicators - Leadership
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.
| Level | Job Titles | Hierarchy Scopes |
|---|---|---|
| IC | Product Manager, Senior PM, Principal PM | Group, Stage |
| Manager | Group Manager Product, Director of Product | Collection of Groups, Stage, Section |
| Director | Director of Product, Senior Director of Product | Section, Collection of Sections |
| Senior Leader | VP | All Sections (though depending on scope and business need, can also cover less) |
| Executive | Chief Product Officer | Entire Function |
Your job as a PM is outlined in Product Manager Responsibilities
The first thing to do is to familiarize yourself with the following handbook pages
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:
#product Slack channel.#questions.#git-help.#mr-buddies.#people-connect.#release-postThe 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
4th of the Month:
Draft of the issues that will be included in the next released (released 22nd of next month). 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.
The product team is responsible for iteration on most of GitLab's products and projects:
This includes the entire stack and all its facets. The product team needs to weigh and prioritize not only bugs, features, regressions, performance, but also architectural changes and other aspects required for ensuring GitLab's excellence
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.
As members of a prolific, product-focused company, GitLab Product Managers are frequently approached with job offers at other companies. Below is a list of criteria to consider when evaluating those roles:
Product Manager onboarding consists of 2 related issue templates.
GitLab People Experience Onboarding Issue is generated by People Experience 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 Experience Associate in the issue or reach out for help in Slack #people-connect. 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.
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. |
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:
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.
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 taking parental leave.
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)
The separate page Product Leadership covers how to be an effective leader in the product management organization.