@@ -22,7 +22,7 @@ For Development specifically, we will calibrate:
1. Anyone in Box 9 who has been with GitLab longer than 3 months (_Note: 3 months is measured from the kick off of the Talent Assessment cycle on 2023-10-16_)
1. Anyone assessed as `Exceeding` for Performance
1. Anyone hired in the last 3 months **not** assessed as [Too New To Rate](/handbook/people-group/talent-assessment/#too-new-to-rate)
1. Anyone promoted in the [Q3 promotion cycle](/handbook/people-group/promotions-transfers/#fy24-q3)(August 1st effective) or later **not** assessed as [Too New To Rate](/handbook/people-group/talent-assessment/#too-new-to-rate)
1. Anyone promoted in the Q3 promotion cycle (August 1st effective) or later **not** assessed as [Too New To Rate](/handbook/people-group/talent-assessment/#too-new-to-rate)
1. Anyone identified as Key Talent
It's important to note that while these will be our focus areas for calibration sessions, managers should feel free to raise any team member's assessment up for discussions if they have any questions or concerns. Calibrating outliers is not a limitation, but rather a structural adjustment to ensure this process is scalable and focused.
@@ -74,7 +74,7 @@ To avoid excessive context-switching, and better distribute the workload, our te
Neither engineer should be allocated to work on Features or critical deliverables. In the context of [Cross-functional milestone planning](/handbook/product/product-processes/cross-functional-prioritization/#cross-functional-milestone-planning), their allocation counts towards the bugs and maintenance ratio.
The [rotation schedule](https://gitlab.com/groups/gitlab-org/secure/-/epics/2#schedule) follows the development cycle, which means using the start/end dates from the GitLab [product milestones](/handbook/product/milestones/). When creating the schedule, the Engineering Manager should aim to minimize the number of back-to-back rotations that engineers do.
The [rotation schedule](https://gitlab.com/groups/gitlab-org/secure/-/epics/2#schedule) follows the development cycle, which means using the start/end dates from the GitLab [product milestones](/handbook/product/product-processes/#understanding-milestones-and-releases). When creating the schedule, the Engineering Manager should aim to minimize the number of back-to-back rotations that engineers do.
Please keep track of the actions you're doing during your rotation and add notes in the corresponding issue (e.g., copying tools command executed locally, sharing relevant changes to projects and processes, etc.),
You can use the [Reaction Rotation issue template](https://gitlab.com/gitlab-org/secure/general/-/blob/master/.gitlab/issue_templates/Reaction%20Rotation%20SCA.md?ref_type=heads) for this purpose.
@@ -6,10 +6,10 @@ title: People Group for Product Management
Generally, the entire organization will be applied to the product function with some adjustments related to specific timing. This page will provide a SSOT for the Product organization and PBP relations.
Other related infromation to People Processes include:
Other related information to People Processes include:
For any questions or updates, please assign `gl-product-leadership`.
@@ -37,7 +37,7 @@ For Product specifically, we will calibrate:
1. Anyone in Box 9 who has been with GitLab longer than 3 months (_Note: 3 months is measured from the kick off of the Talent Assessment cycle on 2023-10-16_)
1. Anyone assessed as `Exceeding` for Performance (I.E. Box 1, 2, 5)
1. Anyone hired in the last 3 months **not** assessed as [Too New To Rate](/handbook/people-group/talent-assessment/#too-new-to-rate)
1. Anyone promoted in the [Q3 promotion cycle](/handbook/people-group/promotions-transfers/#fy24-q3)(August 1st effective) or later **not** assessed as [Too New To Rate](/handbook/people-group/talent-assessment/#too-new-to-rate)
1. Anyone promoted in the Q3 promotion cycle (August 1st effective) or later **not** assessed as [Too New To Rate](/handbook/people-group/talent-assessment/#too-new-to-rate)
1. Anyone identified as Key Talent
It's important to note that while these will be our focus areas for calibration sessions, leaders should feel free to raise any team member's assessment up for discussions if they have any questions or concerns. Calibrating outliers is not a limitation, but rather a structural adjustment to ensure this process is scalable and focused.
@@ -76,7 +76,7 @@ Calibration session attendees will be organized by leadership layer within the P
### Annual Compensation Review
The SSOT timeline for the upcoming Annual Compensation Review can be found [here](/handbook/total-rewards/compensation/compensation-review-cycle/#january). Below you will find additional dates specific to the Product division to ensure all levels have time to review as we move through the process.
The SSOT timeline for the upcoming Annual Compensation Review can be found [here](/handbook/total-rewards/compensation/compensation-review-cycle/). Below you will find additional dates specific to the Product division to ensure all levels have time to review as we move through the process.
@@ -49,11 +49,11 @@ Previously completed Category Maturity Scorecards can be found in this [epic](ht
Category Maturity Scorecards are about judging the quality of experiences against a **defined and confident** JTBD. JTBD are the umbrella component of our product design process, and we use them to guide our product strategy and features. For that reason, before you begin the CM Scorecard process, you should have one or more JTBD that you feel confident about.
Refer to the [JTBD page](/handbook/product/ux/jobs-to-be-done/) to learn [how to write JTBD](/handbook/product/ux/jobs-to-be-done/#how-to-write-a-jtbd).
Refer to the [JTBD page](/handbook/product/ux/jobs-to-be-done/) to learn [how to write JTBD](/handbook/product/ux/jobs-to-be-done/jtbd-playbook/).
Before moving to Step 1, you first need to select the high-priority JTBD statements that you want to assess and translate them into script scenarios. The number of scenarios you will create per job statement often depends on the complexity of the features you're testing. Due to time limitations in a user research study (generally 30 to 60 minutes per participant), we recommend assessing no more than 2 job statements per study to help avoid participant fatigue. However, if you want to test more than 2 job statements, you can. Just be mindful of the total time it will take to run the study.
Tip: Since job statements are persona and solution agnostic, you might find them to be too broad to serve as guidance for writing script scenarios. If that is the case, consider breaking the job statements down into user stories as an intermediary step, in order to bridge the gap between high-level job statements and actionable scenarios. Learn more about the difference between job statements and user stories in [How to Write JTBD](/handbook/product/ux/jobs-to-be-done/#how-to-write-a-jtbd).
Tip: Since job statements are persona and solution agnostic, you might find them to be too broad to serve as guidance for writing script scenarios. If that is the case, consider breaking the job statements down into user stories as an intermediary step, in order to bridge the gap between high-level job statements and actionable scenarios. Learn more about the difference between job statements and user stories in [How to Write JTBD](/handbook/product/ux/jobs-to-be-done/jtbd-playbook/).
To summarise, this is the workflow that should be followed in this step:
@@ -42,7 +42,7 @@ A Product Manager will lead their quad team, in collaboration with a Product Mar
- We also need to be mindful of the acceptable use policies of the competitors we're evaluating. It's often difficult to understand the acceptable use policies of the competitors you're about to evaluate. Rather than try to interpret it yourself, ask your question on the #legal Slack channel before proceeding with the competitor comparison.
-**Step 3 - Decide on the JTBDs to focus on**
- The JTBDs should align directly with the Category Maturity Scorecard testing you're also evaluating (or already have evaluated). The process on how to identify JTBDs is outlined [here](/handbook/product/ux/category-maturity/category-maturity-scorecards/#setup).
- The JTBDs should align directly with the Category Maturity Scorecard testing you're also evaluating (or already have evaluated). The process on how to identify JTBDs is outlined [here](/handbook/product/ux/category-maturity/category-maturity-scorecards/#step-0-jobs-to-be-done-jtbd).
- Sometimes, the scope of a JTBD can span across multiple stage groups, resulting in tighter collaboration across different teams. One suggestion on how to best approach that scenario is to hold an async workshop to land on a set of agreed-upon JTBDs while also discussing the division of labor and timing considerations for the competitor comparison.
