Principles - Processes - Categorization - GitLab the Product - PM Responsibilities - Being a PM - Performance Indicators - Leadership
OKRs (Objectives and Key Results) are a simple goal setting technique propelled by Google and implemented by many leading companies with astounding success. Five key OKR benefits include: Focus, Alignment, Accountability, Status and Ambition.
John Doerr is a leader in the OKR world and authored the book Measure What Matters, a handbook for setting and achieving audacious goals. He as since built a company called What Matters, that gives leaders the tools they need to achieve their goals. The What Matters website is a rich and detailed resource for OKRs. You can also check out the how to write OKRs section of this page for more guidance.
Product Management has the potential to drive and influence growth as well as company goal attainment in ways that other organizations in a company cannot. When we consider our Objectives and Key Results (OKRs) across the Product, Engineering, UX, and Quality organizations, we can do more to make them connected and concerted. One of the key implications for alignment across teams is that you share goals and KPIs. This enables us to be product-led by focusing on Essentialism to drive results that matter most for the customer across the aligned product groups. As it is written in the handbook, GitLab's OKRs are meant to be the "how to achieve the goal" of a KPI. So, the question we need to consider is are we optimizing our goals to achieve the KPI in the best way?
GitLab uses the OKR (Objective and Key Results) framework to set and track goals on a quarterly basis. You can read more about OKRs at GitLab OKRs including the overall process as well as current and past OKRs here. Every department participates in OKRs to collaboratively goal set across the organization. GitLab does quarterly objectives which align with our Fiscal Year.
Through FY22-Q2, Product team OKRs will be tracked as Epics gitlab.com and the KRs are tracked as Issues in the Product project and on the Product OKR Board. Starting in FY22-Q2, all OKRs are also in Ally.io so we can get familiar with the tool before FY22-Q3. Starting in FY22-Q3, we're aiming to replace use of GitLab epics, issues and boards and fully port all OKRs into Ally.io. Details on that process and instructions on how to participate will be added to this page as they solidify.
To learn more about the rollout process for Product and Engineering see the linked Ally OKR Rollout GitLab Project.
Each organization at GitLab may follow a slightly personalized process for OKRs. Below is the process for Product. Product works closely with Engineering and collaborates on some of the same Objectives and Key Results. You can reference the Engineering's process here. One important thing to not is that the Engineering team leverages indivdiual OKRs more broadly than the product team. To manage scope, each engineering team member is limited to no more tha 9 committed KRs per quarter.
The Product OKRs are initiated by the Chief Product Officer each quarter per the details and timeline below.
Below is our Q4 iteration on the OKR process. This Q4 process/timeline incorporates FY22 Q3 OKR pilot learnings. To address some of the findings, we're introducing Shared R&D OKRs to help clarify and highlight Objectives aligned upon by the CProdO and the CTO. The Shared R&D OKRs will then serve as the priority across Product and Engineering as teams and individuals define their KRs and identify plans for the quarter. Please share your feedback in Feedback on Q4 Shared R&D OKR Process
For guidance about the Product OKR process, team members can post in Slack #product and tag Product Operations. Team members can also attend Product Operations office hours for live support. For guidance on how to use Ally.io please check out how to use ally.io or post in Slack #ally-okr-rollout and tag Product Operations.
Notes:
Important note on when Product Manager participation in OKRs
Product Managers may be pulled in for collaboration throughout the OKR drafting process. Regardless of whether a Product Manager is a KR owner or not, they may need to work with their manager and Quad/Hive to plan and execute work to support OKRs throughout the quarter.
When to update the status of Product OKRs
How to report progress (% score in Ally) of Product OKRs
In order to maintain consistency in evaluating progress across R & D, all Product OKRs will follow the scoring method outlined below as proposed in Scoring Shared OKRs Consistently Across R & D.
At the beginning of each quarter, shared product KR owners should lead and align the Hive (the cross-functional team doing the work) to define a plan to accomplish their KRs as scorable in the following manner:
Scoring Method: Scale
This method allows for flexibility and can give you credit for achieving part of the key result. KRs are scored on a 0-100% scale. If you deliver part of the KR you can credit that result as a % score.
Example:
Objective: Improve License Management
- KR1 - Close 16 License issues
- KR2 - Reduce license-related support tickets by 4%
- KR3 - Manually audit 100% of missing license data
If you use the scale scoring method it would look like this:
- KR1 - Closed 8 of 16 issues - 50%
- KR2 - Reduced license-related support tickets by 3.8% - 95%
- KR3 - Manually audited 100% of missing license data - 100%
In this scenario you didn’t complete two of the KRs, but since you selected the Scale method you were able to get credit for what was completed. For example, 8 of 16 pain points is 1/2 of the KR, so the score is 50%. If additional issues were found during development, you would create a new OKR to resolve those issues the following quarter rather than shift the target of your current quarter.
Note: It is recommended to leverage the Ally/GitLab issue integration to help automate the % tracking of the progress of KRs in Ally in tandem with the methodology above. This will create a clear tie between KRs in Ally and the work related to the KR in GitLab. However, KRs can also be scored manually in Ally.io. For more guidance on how to leverage the Ally/GitLab issue integration see this sample issue and other resources in how to use Allio.io.
How this will look in Product Key Review slides
In FY22 Q3/Q4 we'll have an updated process to fully leverage Ally.io as SSOT for OKRs and sunset usage of GitLab epics/issues. Details forthcoming.
During FY22 Q3, we expect many questions as we pilot Allied Product Group OKRs and the adoption of Ally.io. Any time Product Managers or any other team members need live support, they should add themselves to the agenda and attend Product Operations office hours.
Context:
The Q3 OKR process outlined below is a follow-up to the Q2 OKR experiment and designed to pilot Shared Product Group OKRs. Shared Product Group OKRs are encouraged to be drafted against GitLab's yearly product themes and focus on driving ground-up motion to inform the business and deliver value to customers. They may however also be drafted outside of a product theme, targeting a Stage or Group level KPI for example, if the cross-functional team aligns and chooses to do so. Product management will collaborate closely with the Hive: Engineering, UX and Quality, as well as Infra and Security when needed, to create Shared Product Group OKRs. This approach aims to get ahead of the executive OKR process and provide the e-group with our opinionated view of what we plan to do. The Hive will collectively create shared key results at the Product Group level. Three key benefits of this approach:
We realize the introduction of Shared Product Group OKRs may initially cause some perceived or actual conflicts with other team members' functional team OKRs. By first doing this as an optional pilot for product groups, rather than a full roll-out, we hope to capture these challenges and work through them. Please surface any challenges to your manager, in Product Operations office hours or in Feedback on Q3 Product Group Planning.
Guiding themes for Shared Product Group OKRs:
IMPORTANT NOTES:
As DRI of Shared Product Group OKRs, Product Managers own the SSOT of the KRs, be they housed in GitLab epics/issues or in Ally.io. If duplicate drafts are found anywhere, it should be flagged in Feedback on Q3 Product Group Planning, tagging Product Operations @fseifoddini and Quality @meks for resolution.
For guidance on drafting clear and achievable OKRs check out how to write OKRs
5 weeks prior to the start of the fiscal quarter, the CEO and Chief of Staff initiate the OKR process. The CEO will share an MR in the #e-group Slack channel with the 3 Company Objectives for the quarter, and one to three Key Results for each objective.
4 weeks prior to the start of the new quarter the Chief Product Officer will draft their OKRs in the Product Org FY22-Q3 Planning Issue in the Product Project and reviews the drafted Product OKRs with the CEO.
How and when Product Managers can add additional OKRs
Product Managers will be pulled in for collaboration throughout the OKR drafting process. Regardless of whether a Product Manager is a KR owner or not, they will need to work with their Hive to plan and execute work to support a product OKRs starting around 2 weeks prior to the start of the new quarter for which the OKR is assigned. For an overview of how to review or add OKRs and how to plan/track the work, check out how to use ally.io as well as this overview video for Product Managers and this video explaining how OKR alignments work in Ally.
When to update the status of Product OKRs
Note: OKR owners will get reminders via Slack/Ally.io on or near the 5th of each month to do status updates. To set up more reminders or opt out of reminders, check out how to use Ally.io
How to report progress (% score in Ally) of Product OKRs
In order to maintain consistency in evaluating progress across R & D, all Product OKRs will follow the scoring method outlined below as proposed in Scoring Shared OKRs Consistently Across R & D.
At the beginning of each quarter, shared product KR owners should lead and align the Hive (the cross-functional team doing the work) to define a plan to accomplish their KRs as scorable in the following manner:
Scoring Method: Scale
This method allows for flexibility and can give you credit for achieving part of the key result. KRs are scored on a 0-100% scale. If you deliver part of the KR you can credit that result as a % score.
Example:
Objective: Improve License Management
If you use the scale scoring method it would look like this:
In this scenario you didn’t complete two of the KRs, but since you selected the Scale method you were able to get credit for what was completed. For example, 8 of 16 pain points is 1/2 of the KR, so the score is 50%. If additional issues were found during development, you would create a new OKR to resolve those issues the following quarter rather than shift the target of your current quarter.
Note: It is recommended to leverage the Ally/GitLab issue integration to help automate the % tracking of the progress of KRs in Ally in tandem with the methodology above. This will create a clear tie between KRs in Ally and the work related to the KR in GitLab. However, KRs can also be scored manually in Ally.io. For more guidance on how to leverage the Ally/GitLab issue integration see this sample issue and other resources in how to use Allio.io.
How this will look in Product Key Review slides
Please note that the FY22-Q2 process is a "hybrid" model as we continue to leverage Gitlab epics and issues as SSOT for OKR content but shift to scoring OKRs in Ally.io. We fully transition into Ally.io in FY22-Q3. Thank you for your patience!
Updating the status of Product OKRs
It is highly recommended that product groups limit the number of OKRs they commit to so they have reasonable bandwidth to deliver on them. PMs should consider either setting 1 OKR that's not related to a product theme OR 3 or fewer KRs if they are using the product themes as their objectives.
Here's are some examples of how GMPs and PMs can use epics/issues to plan and outline their product group OKRs:
Create stage - Create: Editor group - Create: Code review group
To learn more about what OKRs are and the importance of OKRs at GitLab, see the company OKR handbook page.
To learn about the industry best practices for OKRs, how setting the right goals can mean the difference between success and failure, and how we can use OKRs to hold our leaders and ourselves accountable, watch John Doerr's Ted Talk. You can also find more resources in Product Management Learning & Development
For information on getting started with OKRs and writing basic okrs see the linked courses from our OKR vendor Ally.
Samples of well written KRs from GitLab team members from the Q2 product group KR experiment. What makes these great is that they're succinct in scope and have clear metrics to measure success.
Product theme (Objective): Drive a meaningful impact on Usability (Bugs, Infradev, Security) KRs (Key Results):
For an overview of how Product is currently using Ally.io and how to do some basic tasks, check out this overview video. We also have additional training materials provided by Ally.io and Gitlab in this issue We recommend you check out everything in this issue but these are some specific links for common topics:
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, please assign all MRs for collaboration, review and approval to Product Operations and the EBA to the Chief Product Officer.
