@@ -6,7 +6,7 @@ As a Product Manager (PM) at GitLab, you are primarily responsible for:
1. Defining requirements for a solution that is loved by our users and customers
1. Ensuring our product is viable for GitLab
In addition, as a PM, you also play a critical role in the regular development and operating cadence of GitLab. There are a few specific required tasks that the PMs are directly responsible for in [Core PM Tasks](/handbook/product/product-manager-responsibilities/#core-pm-tasks).
In addition, as a PM, you also play a critical role in the regular development and operating cadence of GitLab. There are a few specific required tasks that the PMs are directly responsible for in [Core PM Tasks](/handbook/product/product-management/product-cdf-competencies/#core-pm-tasks).
### How does a Product Manager ensure they are solving a problem for our users?
@@ -27,7 +27,7 @@ We established these processes because we saw these benefits:
One common concern newcomers to the handbook express is that the strict documentation makes the company more rigid.
In fact, writing down our current process in the handbook has the effect of empowering contributors to propose change.
As a result, this handbook is far from rigid. You only need to look at the [handbook changelog](/handbook/about/changelog/) to see the evidence. Every attempt is made to document guidelines and processes in the handbook. However, it is not possible to document every possible situation or scenario that could potentially occur. Just because something is not yet in the handbook does not mean that it is allowed. GitLab will review each team member's concern or situation based on local laws to determine the best outcome and then update the handbook accordingly. If you have questions, please discuss with your manager or contact the [People Success](/handbook/people-group/) team.
As a result, this handbook is far from rigid. You only need to look at the [handbook commits list](https://gitlab.com/gitlab-com/content-sites/handbook/-/commits/main) to see the evidence. Every attempt is made to document guidelines and processes in the handbook. However, it is not possible to document every possible situation or scenario that could potentially occur. Just because something is not yet in the handbook does not mean that it is allowed. GitLab will review each team member's concern or situation based on local laws to determine the best outcome and then update the handbook accordingly. If you have questions, please discuss with your manager or contact the [People Success](/handbook/people-group/) team.
## Handbook Interpretation
@@ -70,6 +70,4 @@ GitLab uses [Snowplow](/handbook/enterprise-data/platform/snowplow/) to track ha
We've gathered *some* information about the handbook here, but there's still more elsewhere.
@@ -100,7 +100,7 @@ See the [Searching GitLab like a pro](/handbook/tools-and-tips/searching/) page
1. After it is merged you can post this in the `#whats-happening-at-gitlab` slack channel if applicable. You can remind other people of this by asking "Can you please send a merge request for the handbook?"
1. When substantially changing handbook layout, please leave a link to the specific page of the review app **that is directly affected by this MR**. Along with the link, include as much info as possible in the MR description. This will allow everyone to understand what is the purpose of the MR without looking at diffs.
1. Keeping up with changes to the Handbook can be difficult, please follow the [commit subject guidelines](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html#commit-messages-guidelines) with a particular focus on your merge request's title, to ensure someone reading the [Handbook Changelog](/handbook/about/changelog/)can quickly understand the MR's content.
1. Keeping up with changes to the Handbook can be difficult, please follow the [commit subject guidelines](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html#commit-messages-guidelines) with a particular focus on your merge request's title, to ensure someone can quickly understand the MR's content.
1. Communicate process changes by linking to the **merged diff** (a commit that shows the changes before and after). If you are communicating a change for the purpose of discussion and feedback, it is ok to link to an **unmerged diff**. Do not change the process first, and then view the documentation as a lower priority task. Planning to do the documentation later inevitably leads to duplicate work communicating the change and it leads to outdated documentation. You can remind other people of this by asking "Can you please update the handbook first?"
1. When feasible, introduce process changes iteratively. It is important that you contribute to the handbook by [making small merge requests](/handbook/values/#make-small-merge-requests). This will help gain adoption among the process's intended audience. We want to avoid significant process changes that are unnecessarily large, top-down, and disruptive. These types of process changes can disempower [DRIs](/handbook/people-group/directly-responsible-individuals/) and cause people to focus on process rather than results.
1. Like everything else, our processes are always in flux. Everything is always in draft, and the initial version should be in the handbook, too. If you are proposing a change to the handbook, whenever possible, **skip the issue and submit a merge request**. (Proposing a change in a merge request is preferred over an issue description). Mention the people that are affected by the change in the merge request. In many cases, merge requests are easier to collaborate on since you can see the proposed changes.
@@ -98,7 +98,7 @@ The CoS to the CEO is coordinating the OKRs process detailed below. The EBA to t
Function objectives should cascade from one of the Company OKRs in GitLab.
**3-4 weeks before** the start of the fiscal quarter, E-Group firms up KRs.
**2-3 weeks before** the start of the fiscal quarter, during a designated block of time in an [E-Group Weekly](/company/e-group-weekly/), Executives propose OKRs for their functions. At a minimum, they should have 2-3 function KRs that cascade from each company-level objective. They may choose to have more OKRs for function management purposes and have discretion to what degree other goals are highlighted in this forum.
**2-3 weeks before** the start of the fiscal quarter, during a designated block of time in an [E-Group Weekly](/handbook/company/e-group-weekly/), Executives propose OKRs for their functions. At a minimum, they should have 2-3 function KRs that cascade from each company-level objective. They may choose to have more OKRs for function management purposes and have discretion to what degree other goals are highlighted in this forum.
After this meeting, as OKRS are finalized, functional OKRs should be posted in GitLab. This should be noted through a Slack message in the #okrs channel. The CEO and Chief of Staff to the CEO should be @ mentioned. The CEO will confirm sign-off on objectives by commenting directly on them. While the CEO is the DRI, this responsibility may be delegated to the CoS to the CEO. The CoS to the CEO will also post company OKRs in GitLab.
@@ -126,7 +126,7 @@ It is each team's responsibility to proactively identify dependencies in which t
### Documenting How to Achieve
A dedicated session during an [E-Group Weekly](/company/e-group-weekly/) is the key the forum for introducing new function OKRs. During the draft review meeting, each function should share:
A dedicated session during an [E-Group Weekly](/handbook/company/e-group-weekly/) is the key the forum for introducing new function OKRs. During the draft review meeting, each function should share:
