As a Product Organization, we work to create a flexible yet concise product development framework for developing products that customers love and value.
Product Management Operations
This page details the meetings and working relationships.
Team Meetings
Below you’ll find overviews for team meetings designed to boost Product team knowledge, communication, and collaboration. Our goal is to have minimal but valuable sync meetings for the Product team. All sync Product team meetings are required to have agendas and recordings that support async collaboration. We encourage any Product team member to propose a new meeting or the re-design of an existing meeting to help drive or improve collaboration amongst the Product team in an effort to drive more product value for our users.
Adding or revising Product team meetings
To ensure transparency and alignment on the design and frequency of team meetings requiring time commitment from the entire or broader Product team, please raise an MR on this page, requesting review and collaboration from Product Operations, the CPO and any other DRIs noted for the meeting. Product Operations should be always be included to review the addition of new or major revision of existing team meetings because they monitor the overall flow, productivity and satisfaction of all Product team meetings. “Broader” Product team refers to meetings that affect team members across Sections, Stages, and Groups on a regular cadence. For example, if a meeting is proposed that requires the participation of all Group Product Managers on the Product team every month.
The intent of this review and collaboration workflow is not to “block” but to help ensure team meetings compliment and flow well together, taking into consideration the following:
the existing macro Product team workflow
non-duplication of existing sync or async meetings
support from Product Operations for successful rollout to and adoption by the Product team
What: A bi-weekly team meeting for Product. All team members can add items to the agenda either as a Read-Only, or as a discussion item.
Who: Product along with interested parties across departments. The meeting is open to all GitLab team members.
When: Every other Tuesday for 50 minutes. The start time alternates each week between and to accommodate timezones.
Format: The agenda is curated and moderated by Product Operations in partnership with the Chief Product Officer
Recordings: The meetings are set as Private Recordings and are saved to the Product Team playlist on YouTube Unfiltered. If you are unable to view a video, please ensure you are logged in as GitLab Unfiltered.
Potential Topics:
READ-ONLY announcements which require no synchronous discussion and are for information sharing only. If any action is required, this should be highlighted specifically by the reporter.
New hire announcements, bonuses, promotions and other celebrations.
Announcements and discussion on department-wide changes (e.g. OKRs, performance indicators, pricing changes).
Learning about the product: showcasing different product areas, their direction, why they matter to GitLab.
Iteration: helping your peers break down issues and designs into smaller steps, across the department.
Guest Speakers: We encourage product managers to nominate guest speakers by reaching out to Product Operations directly with a request.
All product team members are encouraged to add agenda items. The Chief Product Officer will prioritize the discussion items, and any items we can’t get to in the allotted 50 min will be moved to the following meeting. If you are a Product team member and are unable to attend the call, you may add items for READ-ONLY to the agenda.
The Chief Product Officer and their direct reports track our highest priority Product Team initiatives. If one of those initiatives needs to be discussed synchronously the assigned individual should add it to the meeting’s GoogleDoc agenda. Directors can delegate and coordinate cross-product initiatives as needed based on the issues in this board.
What: A monthly meeting for Product Sections to provide updates on Performance Indicators, inclusive of their Stages and Groups and the cross-functional team. The main deliverable from the team is for each group to clearly show what they are doing in the next month to drive their metrics in the right direction.
When: During the last two weeks of every month
Duration: 50 minutes
Format: The meeting is lead by the Section Leader
All data reviewed will be published on the Section’s PI page in the internal handbook (example. Sections may optionally provide supporting slides.
Content will focus on the following areas:
Development - Error Budgets, Past Due Security/InfraDev Issues (S1/S2)
Quality - Past Due Bugs (S1/S2)
UX - Past Due SUS Impacting Issues (S1/S2)
Product - XMAU, XFN Prioritization
Recordings: Each meeting will be recorded, and published so participants can engage async. The meetings have [REC] in the title and will automatically go to the Google Drive Folder. If you cannot find a recording, please message the EBA to the Product Division.
Preparation: Section Leaders will provide the content at least 2 business days in advance of their review by posting a link to the updated PI pages and slides (optional) in the meeting agenda to allow ample time for meeting participants to review in advance. The Chief Product Officer may not attend the sync meeting but will always review async.
Meeting Attendees
The following participants will be included in the sync meeting from each group (attendance can be async):
Engineering Managers or Sr Engineering Manager / Director for the stage
Product Design Manager(s) for the Stage
Quality Engineering Manager for the Stage
Group Manager, Product for the Stage
Product Manager for the Group
All Sections will leverage and personalize this template
All Sections will leverage and personalize this agenda template.
What: A monthly meeting for 4 stages to present 10-minutes on their direction as well as provide a deep dive or demo into a recent product delivery.
When: Monthly, rotating between EMEA and NA Timezone
Duration: 50 minutes
Format: The meeting is lead by the Group Manager of the Stage.
Recordings: The meetings have [REC] in the title and will automatically go to the Google Drive Folder. If you cannot find a recording, please message the EBA to the Product Organization.
Preparation: A monthly issue will get created and 2 weeks before meeting Stage leaders will populate their place in the meeting and will provide a link to a deck or direction page that will be reviewed for their timeslot.
Kickoff meetings
The purpose of our kickoff is to communicate with our community (both internal and external) a view of what improvements are being planned in the coming release. This can help other GitLab teams, community contributors and customers gain an understanding of what we are prioritizing and excited to deliver in our next iteration.
While kickoffs are commonly used to ensure visibility of work across an internal audience, our connection to a broader community and commitment to transparency means we also serve an external audience.
The process for preparing and presenting group and company wide Kickoff meetings is outlined in our Monthly Kickoff issue template. We create an issue from that template each month to collaborate on that month’s Kickoff.
The calendar invite for the monthly kickoff meeting is scheduled for the 18th of each month. When the 18th falls on a Saturday or Sunday, the kickoff date is moved to the following Monday, which is either the 19th or 20th of the month.
Proactively identify small and large strategic UX needs to aid Product Management prioritization
Own and identify test strategy and requirements to complete the definition of done
At GitLab, we develop our product for self-managed as well as SaaS-hosted customers. We realize that while we have DRIs there are many stakeholders who who must have input, including Engineering, Quality, UX, Product, Security, and Infrastructure. For example, the Security team often has the deeper context of what it takes to run a secure SaaS system. Similarly, the Infrastructure team has insights into what we should build into the product to reduce toil and enable efficient, reliable, performant, and scalable systems.
We call this the Product Group model. It is an extension of the classic quad concept at the leadership level and is currently comprised of Development, Quality, User Experience, Infrastructure, Product, and Security.
Working with Product Management across the company
There are many counterparts that PMs work with. Here are some best practices for working across the organization.
Working with Finance Business Partners
In some cases, Product Managers may have items that incur expenses toward the budget. These can be related to external vendors for research, contractors for development staffing, and infrastructure. The CProdO is the DRI for the product budget and all changes or requests for budget spend must be approved through them.
To request a forward-looking new budget item, open an issue in the Product project using the Product Budget Request Template and assign it to the CProdO and manager. Budgets are planned annually and quarterly, so approval may not be immediately given because it depends on the timing of budget planning. The CProdO will bring the budget request to the next budget planning session with Finance.
To request approval for an increase in the expected spend for a pre-existing item, open an issue in the Product project using the Product Budget Request Template assign to the CProdO and tag your manager. The CProdO will review, approve or decline the budget change. The CProdO will then notify the Finance Business Partner of changes for forecast updates.
Working with Content Marketing
Content marketers and Product Managers can partner together when using a Blog to communicate product changes and engaging the market with thoughtful changes. See the blog post handbook page for guidelines on when and how to start engaging Content Marketing for creating a blog post for a feature.
Working with Product Marketing (PMM)
Product marketers and managers should be joined at the hip. Just as a feature without documentation
should not be considered shipped, benefits of GitLab that we’re not actively talking about might
as well not exist.
Product marketers rely on product managers to be guided to what is important and high impact.
In general, you should:
always mention the appropriate PMM on epics and high level issues
regularly meet/talk async with the PMM that is aligned with your product area
proactively reach out for input when contemplating new features
involve PMM as early as possible with work on important changes
Adding Competitive Content to Use Cases
A core element to use cases is effective objection handling against major competitors in the market. In order to effectively support this effort, a partnership between Product Marketing and Product Management to maintain adding competitor walkthroughs and competitive content to the existing use cases is critical. To date we have competitive sections on the following uses cases:
In FY22-Q2, we are taking on an effort to continually update these Tier 1 and Tier 2 use cases and are assigning DRIs, follow along this effort in gitlab&1446
Working with marketing
When working on the release of larger features or new capabilities, it is important the product manager consider various aspects of the go to market plan and inform or partner with the appropriate stable counterparts for strategic and logistical considerations.
Marketing materials
As a PM you’re responsible for making sure changes you’ve shipped are well represented
throughout GitLab’s documentation and marketing materials. This means that on
release, features.yml is updated, documentation is merged and deployed, and
any existing content is updated where necessary.
It’s not acceptable to do this after the release. GitLab is very complex, and features
and functions are easily missed, even those that provide significant value to customers
(e.g. the many ways you can authenticate with GitLab).
You can recruit the help of the marketing and technical writing team if needed,
but it’s highly recommended to do small updates yourself. This takes less time
and overhead than communicating what needs to be done to someone else.
Pages that read from features.yml
It’s important to keep features.yml updated because there are a number of different pages (internal-facing and external-facing) that read from that file. These include:
The standard for working as a team at GitLab is the Product Development Workflow. Product Managers and Product Designers should work together as strategic counterparts to better understand the problem and discover user needs. The Product Designer and the Product Manager will pair to understand the target audience, their challenges when using a particular feature and then designing a solution that helps users solve them.
It’s important to remember that User Experience (UX) does not only relate to visual features or interface design. UX is the intangible design of a strategy that brings us to a solution, so it also refers to the experience of writing code, working with .yml files, designing APIs, working with a CLI, etc. All of those functionalities are meant to be read and used by people. Involving a Product Designer into their planning and development can be highly beneficial. A guide to consider is: anytime a person is interacting with something, there is an opportunity for that interaction to be designed.
Assessing user workflows
As the GitLab product matures, we know we must make important workflows easier to use through feedback-loop mechanisms as is captured in the “Improve” section of the Product Development Flow. We can use the Category Maturity Scorecards and UX scorecards as mechanisms to provide insights into how might be able to improve these user workflows.
What if there is a conflict with the product direction plan and solution proposal?
For areas with minimal maturity, or low/internal-only adoption, iteration and quickly adapting the product is the priority. In cases where the product experience desired would take longer to implement than required for the current maturity stage, it is advised the Product Manager work with the Product Designer and/or Engineering Manager to scope an iteration plan to ensure the experience is delivered incrementally over time to provide value quickly with quality.
For areas with more adoption, or beyond viable maturity, we recommend using the below escalation path if there is a disagreement on the approach to solve for the product direction and experience for users/customers.
As a team, there may be cases where a proposal exceeds the expected time to market to achieve the optimal customer experience. As this impacts potential business results, product managers are the DRIs of the decision.
As DRIs, it is important to consider the input from other team members and to know when to trust in their experience and judgment. It is advised to use an opportunity canvas lite. The PM is expected to compile the canvas lite with inputs from the Product Designer and/or Engineering Manager. The PM then makes a decision after weighing input from the product designer and engineering, as appropriate. The PM should then share the decision, articulating the costs of waiting, and shipping earlier with less polish, as well as why no smaller iteration exists as part of this decision.
In the event that a decision is made to build something that is less polished, has a lesser user experience, or otherwise doesn’t live up to our standards of where we want this UI to end up the team should generate follow-up Deferred UX issues to be addressed in the next upcoming milestone(s).
If a quad member remains concerned and in strong disagreement with the decision made by the PM DRI, the quad member should exercise our disagree, commit, and disagree value, by initiating an escalation to bring in management layers above into the decision.
Results are the most important aspect to consider for the business and our users. If there is a perceived risk to potentially harm the business financially, reduce customer satisfaction or value, or lead to legal trouble, teammates are empowered to seek an alternative perspective for the product decision. Within the Product Division, we recommend escalating first to the management layer immediately above where the disagreement is happening for input and further escalating to PLT and ultimately the Chief Product Officer.
What if your team doesn’t have a designer?
Product Designer assignments are listed in the team.yml file. Unfortunately, we are currently unable to assign a dedicated Product Designer for every group. Instead, Product Designers are assigned to the areas of highest business priority and will continue to provide focused support to those priorities throughout the year. Due to the limited capacity, we are also not able to do UX reviews on MRs for groups without a designer.
If there isn’t a designer listed for a group, then that team is expected to be self-sufficient in taking responsibility for the design needs of their product area. Product Design does not have the capacity to review complex proposed design solutions or provide design solutions for unsupported groups.
If you have questions or need support you can do so in the following ways:
PMs who need to create designs can request access to Figma by creating an Access Request issue. Note: We cannot grant an Editor seat by requesting an upgrade within Figma. An access request issue is required.
Working with Product Management external to the company
Here are some practices for how PMs work with groups outside of GitLab.
Working with community contributors
Product managers are the DRI for their group’s product direction
which must include delivering on our greater company strategy of dual flywheels.
Community contributions are a critical
part of the product direction.
To support contributions product managers may consider the following guidelines:
Aim to review and respond to community contributions within 4 working days- see review response SLO.
Contributions for well-defined ~direction or %Backlog issues will be prioritised.
For contributions that impact user experience, following the contribution guidelines,
the Product Designer for the group should review the MR and provide feedback on the MR.
For contributions that are for features we do not want in the product (either because
of conflicts with our product direction, poor UX, maintenance concerns, or security reasons)
the Product Manager should review the MR and provide feedback on the MR so the contributor
understands this feature is not being accepted by GitLab.
If not involved earlier, tag the PM of the group reviewing the MR before merging the MR.
This is to ensure that the PM stays informed about changes affecting their area and to
allow them communicate the change via a release post, if necessary.
Remember to practice our CREDIT values when communicating with contributors.
Product-Specific “People” Processes Generally, the entire organization will be applied to the product function with some adjustments related to specific timing. This page will provide a SSOT for the Product organization and PBP relations.
Other related infromation to People Processes include:
Product Management Roles Product Management Leadership Product Manger Responsibilities For any questions or updates, please assign gl-product-leadership.
Hiring and budget discussions In the event that there are changes to the R&D Hiring Annual Plan, these changes must be documented in the R&D Headcount Project Issue Tracker.
