Principles - Processes - Categorization - GitLab the Product - PM Responsibilities - Being a PM - Performance Indicators - Leadership
For guidance about the 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. Every quarter, there will also be a feedback issue linked on this page as part of that quarters timeline/process that anyone can contribute to.
#product Slack channel or PM Weekly if appropriate and helpful for the rest of the team.[FY23-Q4 feedback issue](TBD)[Agenda](TBD)[Agenda](TBD)[FY23-Q4 Shared R&D and Product Org OKR Planning](TBD) and the VPP reviews the proposed OKRs with the CEO#product Slack channel or PM Weekly if appropriate and helpful for the rest of the team.KR owners will be responsible for updating the status of their KRs by monthly. This is inclusive of collaborating with other team members to make sure any of their sub KRs rolling into their KRs are up to date as well. All R&D team members leverage the same scoring method to update OKRs detailed here.
For previous quarters please see previous quarter OKR timelines.
For an overview of GitLab's approach to OKRs visit Objectives and Key Results (OKRs). The product team, in alignment with this guidance and in collaboration with the Engineering team, prioritizes Shared OKRs over functional team specific OKRs.
Note: Parts of this section are still under review/alignment with the Engineering team.
Quarterly priority OKRs from CTO and VPP are referred to as Shared R&D OKRs. The teams responsible for collaborating on these OKRs are Product Groups.
Shared R&D OKRs stem from Objectives the CTO and VPP align on, jointly with their leadership teams and fiscal year product investment themes. These OKRs are not function-specific, as they are identified as a necessary priority across the whole product ecosystem by the CTO and VPP and approved by the CEO. Shared R&D Objectives may be owned by either the CTO or the VPP , and the KRs will be cascaded to cross-functional team members regardless of reporting/organizational structure. For example, the VP of User Experience may own a KR that cascades from an Objective owned by the VPP. Shared R&D OKRs will be worked on as a priority by Product Groups.
To maintain clear focus and prioritization, the CTO and VPP will aim to have no more than three Shared R&D objectives per quarter. There may be times the VPP or CTO need to have functional team-specific Objectives. In those cases, they will still limit the total number of objectives they cascade to their respective teams to be no more than three.
There are times the Product Team will have functional team objectives that do not require collaboration from the cross-functional product group. Those OKRs will still be defined and cascaded by the VPP following the same workflow as Shared R&D OKRs.
All OKRs relevant to the product team are initiated by the Chief Product Officer each quarter per the details and timeline shared on this page.
The CTO drafts any Engineering organization specific OKRs per the engineering OKR process
Note: This section is still under review/alignment with the Engineering team.
The teams responsible for collaborating on the Shared R&D OKRs are the Product Groups. Beside supporting the Shared R&D OKRs, the teams can set quarterly OKRs to define a cohesive plan for the Group to work on in the quarter. These OKRs are meant as a communication channel outside the team, towards product and engineering leadership and the wider community. The core question the team should answer creating an OKR is how they want to contribute to the business results of GitLab in the given quarter.
A Product Group level OKRs should include the group's contribution to Shared and Functional team specific OKRs (including Product, Engineering and UX), and the remaining bandwidth can be spent on Group focused work if any.
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 Product Group (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
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 GPMs and PMs can use epics/issues to plan and outline their product group OKRs:
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 additional training materials and answers on topics such as access, integrations, scoring, and more, please see this issue.
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.