Product Division OKRs
Principles - Processes - Categorization - GitLab the Product - PM Responsibilities - Being a PM - Performance Indicators - Leadership
Product Division OKR Overview
For an overview of our overall approach to OKRs, as well as any company-wide OKR due dates, see Objectives and Key Results (OKRs).
General timeline and process
Guidance on timeline and process
This page provides an overview of the Product Division OKR workflow. All departments (product management, UX, etc.) collaborate by following this guidance. For clarifications on the OKR process, team members can post in Slack #product.
Timeline and process for every quarter
OKR Kick-off by Chief Product Officer
- 5 weeks prior to the start of the quarter, an automated drafting issue kicks off the OKR drafting process:
- Product EBA updates the issue with due dates and signals the Chief Product Officer the drafting issue is available for drafting
- 4 weeks prior to the start of the quarter:
- 3 weeks prior to the start of the quarter:
- CProdO shares proposed Product OKRs with Product Leadership Team
- Product Leadership team provides their feedback or any alternate OKRs in the drafting issue
- 2 weeks prior to the start to quarter:
- Product EBAs create Product Division OKRs in GitLab and mention
@gl-product-pm (section, stage, and group product leads) to finalize KR drafts with their respective Product Quad
- Product leads must have at least 2 weeks to review CProdO OKRs, propose changes, and plan any additional OKRs that cascade up to CProdO OKRs.
- Product leads from each section, stage, and group review Product Division OKRs and provide feedback directly in GitLab on changes that may be needed.
- Product leads plan and propose their respective section, stage and section OKRs following the guidance on how to write OKRs.
- 1 weeks prior to start of fiscal quarter:
- Product leaders at all levels (division, section, stage, group) discuss and finalize OKR changes needed to ensure alignment with the goal of finalizing OKRs when the new quarter starts.
- At the end of the week, Product Division OKRs are reviewed by the Product Leadership Team and updated in GitLab to ensure that they reflect what the section/stage/group KRs show that can be delivered within the quarter.
- Ongoing after quarter start:
Updating the Status and Progress of OKRs
When to update the status of Product OKRs
- For all Product team OKRs, the KR owners are responsible for keeping the status of their KRs in GitLab up to date
- Team members who own specific OKRs will update the score (% complete) in GitLab monthly and ping any relevant stakeholders as needed. For example, since FY23-Q1 begins February 1, KR owners will provide score updates by February 15, March 15 and April 15. We follow this mid-month cycle to ensure there are accurate OKR status updates for Key Reviews which typically happen around the 20th of each month.
- Owners of KRs will get pinged with reminders update their KRs via Slack around the 5th of each month.
- Owners of KRs will also get pinged in the Product Key Review issue as needed to update the Product Key Review slides around the 18th of each month based on what is in GitLab.
How to report progress of Product OKRs
- Prior to the start of each quarter, shared product KR owners should lead and align on a plan for the Product Group to accomplish their KRs.
- For guidance on how to structure and score OKRs, refer to the Scoring OKRs section on the GitLab OKRs page (/company/okrs/#scoring-okrs).
- At the end of each quarter the OKR owner will do a final scoring of the OKRs. If the OKR shifted from the original OKR, always score the the latest agreed to KRs that are still valid.
Sharing OKR completion at the end of the quarter
During the first two weeks of a new quarter, every Product stage should complete an OKR retrospective leveraging the Product OKR Retrospective template. The retrospective DRI is the PM leading the stage. Beyond the stage members, the product and engineering lead of the section needs to be invited to the retrospective.
We recommend sharing the results of the retrospectives with @gl-product-pm and other relevant stakeholders.
How to change an OKR within the quarter
In certain circumstances, it is appropriate to change an OKR within the quarter. To make a change to an OKR:
- OKR assignee review: The OKR assignee needs to review and agree to the proposed OKR change.
- Tradeoffs review and communication: OKR assignee should ensure that the right tradeoffs are made to make the OKR feasible for the quarter.
- If another OKR needs to be deprioritized this should be clearly outlined as part of the OKR change.
- If an OKR that needs to be deprioritized is a shared OKR, or a dependency for another team’s work, the other teams and stakeholders must be informed of the change and their feedback considered.
- Inform manager: As part of making the OKR change, the assignee should inform his manager and impacted stakeholders, including any owner of an objective that this OKR rolls up to and owners of OKRs below the one being changed.
- Track the change and update the OKR: Once the manager and impacted stakeholders acknowledge the change, the assignee should:
- Update the description of the parent objective to add a summary of the change and link to the rationale. This helps keep track of OKR changes throughout the quarter.
- Update the actual OKR in the GitLab OKR tracker to reflect the latest agreed to OKR.
How this will look in Product Key Review slides
- Product team OKR owners may leverage this slide template if additional details are needed for their KRs
How to write OKRs
Product groups should limit the number of OKRs they commit to so they have reasonable bandwidth to deliver. When planning OKRs:
- Consider non-OKR commitments. While OKRs are the big commitments that the team is making for the quarter, they do not supersede core team members responsibilities. For R&D, this means retaining team capacity beyond OKRs for work that falls higher in our prioritization framework, such as forced prioritization items with an SLA/SLO. Meeting SLOs is not an OKR, as OKRs focus on what’s different.
- Other than core team member responsibilities such as those outlined above, all other major commitments should be prioritized via OKRs and consider team bandwidth.
- If a team gets a request for a major effort within the quarter, they can change the OKR by following the guidelines above about [how to change an OKR within the quarter](#how-to-change-an-okr-within-the quarter)
- Plan for OKRs to be ambitious, but achievable within the team capacity that you have for OKRs. While OKRs are meant to be ambitious, you should aim to complete them and strive to hit the ambitious plan. We recognize that with ambitious planning some OKRs will not be completed, but it is striving and reporting on OKRs with the goal of hitting 100% that helps us accomplish strong results. We score individual OKRs as “on track” when they are at least 80% complete. In aggregate, we expect that the average completion score across OKRs is 70%.
- Review cascading OKRs first and allocate time for those. Cascading OKRs are those at the CEO level or Product Division level that need your group’s contributions to be achieved. You should prioritize these first.
- It is OK to push back on OKRs. If you can’t prioritize a cascading or shared OKR due to more important work, contact the owner of the OKR and make adjustments so that it is achievable without your team’s contribution, or remove it. It is OK to do this, with clear communication and collaboration. It is not acceptable to simply ignore the cascading OKR or shared OKR without clear upfront communication and prioritize other work instead.
- When writing OKRs, follow our company guidelines on how to write OKRs. In particular, focus on outcomes, not tasks, and make key results measurable.
- For any OKR with a dependency, make sure to get commitment on the dependency with shared objectives. If you don’t get commitment in the shared objective, make changes as needed to keep to feasible OKRs.
Examples of good OKRs
Objective: Establish GitLab leadership in X area.
- Avoid ❌ KR1: GitLab X becomes available in beta, including Y functionality in beta, with a path to general availability next quarter.
- Instead ✅ KR1: GitLab X reaches 100k paid MAU by end of quarter.
- Avoid ❌ KR2: Ship 10 components to support the use of X.
- Instead ✅ KR2: 30% of GitLab users are able to use X with the components built.
This aligns with a focus on outcomes and business results instead of KRs tracking tasks or launches.
Organizing Product OKRs in GitLab
Product Objectives and Key Results are drafted and entered into GitLab by PLT as per (/handbook/product/product-okrs/#timeline-and-process-for-every-quarter). This includes all Chief Product Officer level OKRs that the Product Division is tracking and reporting on. The R&D org as a whole encompasses many stages, groups, and teams. As a result, it can be challenging to track all OKRs in one place. As of Q4FY24, we are using the following organizational structure to track our OKRs in GitLab:
- R&D’s OKRs
- FY24Q4 Top Priority R&D OKRs (entered by PLT)
- Objective 1: [high priority item A]
- Objective 2: [high priority item B]
- Objective 3: [high priority item C]
- Objective 4: [high priority item D]
- FY24Q4 Other R&D OKRs (entered by all stage/group leaders per area)
- Monetization & Operations
- Sec & Data Science
- CI/CD, Core Platform, & SaaS
- Dev & Analytics
Additional Resources
Timeline and process for previous quarters
For previous quarters, please see previous quarter OKR timelines
How to contribute to this page
We encourage suggestions and improvements to the Product OKR process so please feel free to raise an MR to this page. To keep us all aligned, as the process touches all teams across the company.
Principles - Processes - Categorization - GitLab the Product - PM Responsibilities - Being a PM - Performance Indicators - Leadership
FY23 Q3 Incorporates FY23-Q2 learnings FY23-Q3 feedback issue OKR Kick-off by the Product and Engineering Leadership Teams 8 weeks prior to the start of the fiscal quarter, the Product Leadership Team drafts initial OKRs aligned to the annual product investment themes. Product Operations will lead this effort with the FY23 Q3 PLT OKR Pre-planning issue in preparation for Shared R&D OKR planning with Engineering.
