This page details the meetings and working relationships.
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.
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:
DRI: Product Operations and Chief Product Officer
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.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.
DRI: Chief Product Officer and EBA to Chief Product Officer
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.
As part of this Product Leadership Meeting we also review progress towards our OKRs.
Non-public items for discussion should be added directly to the agenda document for the meeting.
DRI: Appropriate Product Section Leader & Senior Director, Product Monetization
DRIs: Director, Verify & Package and Product Operations
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.
GitLab is designed and developed in a unique way.
Consistent with our value of Efficiency the product is developed with directly responsible individuals from Product, UX, Quality and Development working together.
| Product Managers | Engineering Managers | UXers | SETs |
|---|---|---|---|
| Set milestone priorities and define what features Engineering works on | Own the definition of done; decide what gets merged into Product. Prioritizes maintenance work | 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.
The Product Group can be used to facilitate a global optimization, including product-wide technical debt.
There are many counterparts that PMs work with. Here are some best practices for working across the organization.
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.
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.
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:
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
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.
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.
features.ymlIt'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:
External
Internal
Product Managers and Product Designers should work together as strategic counterparts to better understand the problem and discover user needs. Product Designer will support the Product Manager in understanding 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.
As the GitLab product matures, we know we must make important workflows easier to use. As part of this effort, the UX department is collaborating with Product Management to select highly used workflows in stable areas of the product. We'll assess and score these workflows using the UX Scorecards methodology and then work together to prioritize recommended improvements.
This effort aligns with the Category Maturity goals that move areas of our product from minimal to viable to complete and, finally, lovable.
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:
#ux or #ux_coworking Slack channel.Here are some practices for how PMs work with groups outside of GitLab.
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:
~direction or %Backlog issues will be prioritised.