Principles - Processes - Categorization - GitLab the Product - Being a PM - Performance Indicators - Leadership
In order to provide a useful single metric for product groups which maps well to product-wide Key Performance indicators, some product performance indicators cascade upwards. Here is how:
Notes:
We should not give xMAU metrics without clearly indicating one of the three versions, Reported, Estimated, or Projected.
Each xMAU metric should have three versions:
| KPI | Health | Status |
|---|---|---|
| Estimated Total Monthly Active Users (TMAU) | Unknown |
|
| Paid Total Monthly Active Users (Paid TMAU) | Unknown |
|
| Unique Monthly Active Users (UMAU) | Attention |
|
| Direct signup ARR growth rate | Attention |
|
| Free to paid ARR growth rate | Attention |
|
| Net Retention | Attention |
|
| Gross Retention | Okay |
|
| Stages per User (SpU) | Attention |
|
| Category Maturity Achievement | Attention |
|
| Paid Net Promoter Score (PNPS) | Attention |
|
| Active Hosts | Okay |
|
| New hire location factor | Attention |
|
| Refunds processed as % of orders | Attention |
|
| Acquisition impact | Okay |
|
The estimated sum of all stage monthly active users (SMAU) in a rolling 28 day period for Self-Managed and SaaS. We extrapolate estimated TMAU based on the percentage of self-managed instances that report this data (not all self-managed instances do). Therefore the reported number is not the same as the estimated or even the actual number. The chart currently reflects reported TMAU. We plan to change this to estimated TMAU [soon](https://gitlab.com/gitlab-data/analytics/-/issues/6000). Numbers displayed below are for self-managed instances with usage ping (enabled), including the self-managed instance hosting the SaaS product. Data for (TMAU for SaaS) is available separately using GitLab.com Postgres Database Import. Owner of this KPI is the VP, Product Management.
Target: TBD
Is KPI: true
Chart (Sisense↗)
Health: Unknown
The sum of all (paid stage monthly active users ) in a 28 day rolling period. The license information used to generate this metric from usage ping is being validated, and the currently displayed data could be incorrect by up to 20%. Numbers displayed below are for self-managed instances with usage ping(enabled). Data for (Paid TMAU for SaaS ) is available separately using GitLab.com Postgres Database Import. Owner of this KPI is the VP, Product Management.
Target: TBD
Is KPI: true
Chart (Sisense↗)
Health: Unknown
The number of unique users that performed an event within the previous 28 days for Self-Managed and SaaS. Numbers displayed below are for self-managed instances with usage ping (enabled) and GitLab.com. Data for ( Paid Self-Managed (EE) Unique Monthly Active Users (UMAU) (28-day trailing window) ). Data for ( SaaS GitLab.com Unique Monthly Active Users (UMAU) (28-day trailing window) ) is also available using GitLab.com Postgres Database Import. UMAU calculation is the same using both data sources (usage ping and GitLab.com Postgres Database Import). Owner of this KPI is the VP, Product Management.
Target: TBD
Is KPI: true
Chart (Sisense↗)
Health: Attention
Direct signup ARR growth rate is calculated by measuring the difference in actual signup ARR between two consecutive periods (current and prior) and dividing that number by the direct signup ARR of the prior period. Owner of this KPI is the Growth - Acquisition group. The calculation for this metric is (Direct signup ARR in the current period - direct signup revenue in the prior period)/direct signup revenue in the prior period.
Is KPI: true
This KPI cannot be public.
URL(s)
Health: Attention
Free to Paid ARR growth rate is calculated by measuring the difference in actual free to paid ARR between two consecutive periods (current and prior) and dividing that number by the free to paid ARR of the prior period. Owner of this KPI is the Growth - Conversion group. The calculation for this metric is (Free to paid signup ARR in the current period - free to paid signup revenue in the prior period) / free to paid signup ARR in the prior period
Is KPI: true
This KPI cannot be public.
URL(s)
Health: Attention
This is a subset of an existing KPI. Please see the definition for the parent KPI.
Owner of this KPI is the Growth - Expansion group.
Target: Our Target net retention rate is 150%.
Is KPI: true
This KPI cannot be public.
URL(s)
Health: Attention
This is a subset of an existing KPI. Please see the definition for the parent KPI.
Owner of this KPI is the Growth - Retention group.
Target: Our Target gross retention rate is 90%.
Is KPI: true
This KPI cannot be public.
URL(s)
Health: Okay
Stages per user is calculated by dividing Stage Monthly Active User (SMAU) by Monthly Active Users (MAU). The Stages per User (SpU) KPI is meant to capture the number of DevOps stages the average user is using on a monthly basis. This metric is important, as each stage added triples paid conversion. Owner of this KPI is the VP, Product Management.
Target: Our Target SpU is 1.8.
Is KPI: true
Chart (Sisense↗)
Health: Attention
Percentage of category maturity plan achieved per quarter. Owner of this KPI is the VP, Product Management.
Target: Our Target is 70%.
Is KPI: true
Health: Attention
Abbreviated as the PNPS acronym, please do not refer to it as NPS to prevent confusion. Measured as the percentage of paid customer "promoters" minus the percentage of paid customer "detractors" from a Net Promoter Score survey. Note that while other teams at GitLab use a satisfaction score, we have chosen to use PNPS in this case so it is easier to benchmark versus other like companies. Also note that the score will likely reflect customer satisfaction beyond the product itself, as customers will grade us on the total customer experience, including support, documentation, billing, etc. Owner of this KPI is Product Operations.
Target: Our Target PNPS is 40.
Is KPI: true
URL(s)
Health: Attention
The count of active Self Hosts, Core and Paid, plus GitLab.com. Owner of this KPI is VP, Product Management. This is measured by counting the number of unique GitLab instances that send us usage ping. We know from a previous analysis that only ~30% of licensed instances send us usage ping at least. We are planning to update the methodology to track opt-in rate more accurately. once a month.
Is KPI: true
Chart (Sisense↗)
Health: Okay
This is a subset of an existing KPI. Please see the definition for the parent KPI.
Target: Our Target is 0.72.
Is KPI: true
Chart (Sisense↗)
Health: Attention
For a month take the number of refunds and divide that by the total amount of orders (including self-managed and sales initiated orders). More details available here
Is KPI: true
URL(s)
Chart (Sisense↗)
Health: Attention
Acquisition impact measures the number of maturity levels advanced, as a result of acquisitions. The target is 3 per year.
Target: 3 per year
Is KPI: true
Health: Okay
Stage Monthly Active Users is required for all product stages. SMAU is defined as the specified AMAU within a stage in a 28 day rolling period for Self-Managed and SaaS. Numbers displayed below are for self-managed instances with usage ping (enabled), including the self-managed instance hosting the SaaS product. All (SMAU for SaaS) is available separately using GitLab.com Postgres Database Import. Owner of this KPI is the VP, Product Management.
Target: TBD
Chart (Sisense↗)
Health: Attention
user_unique_users_all_secure_scanners statistic in usage ping. More details on AMAUPaid Stage Monthly Active Users is required for all product stages. Paid SMAU is defined as the count of SMAU (Stage Monthly Active Users) that roll up to paid instance for Self-Managed using Usage Ping data or a paid namespace for SaaS using GitLab.com Postgres Database Imports in a 28 day rolling period. The license information used to generate this metric is being validated, and the currently displayed data could be incorrect by up to 20%. Numbers displayed below for self-managed are for instances with usage ping (enabled). (Paid SMAU for SaaS) is available separately using GitLab.com Postgres Database Import. Owner of this KPI is the VP, Product Management.
Target: TBD
Chart (Sisense↗)
Health: Unknown
In categories where there is not a directly applicable SMAU metric as the category is focused on protecting our customer's customer, other metrics need to be reviewed and applied. An example of a group where this applies is [Defend's Container Security group](/handbook/product/product-categories/#container-security-group) where their categories are designed to protect our customers and by extension their customers who are actively interacting with our customer's production / operations environment. Metrics such as stage monthly active clusters (SMAC) can be used in place of SMAU until it is possible to achieve an accurate metric of true SMAU which may include measurements of monthly active sessions into the customer's clusters.
Target: TBD
Health: Unknown
GMAU is defined as the count of unique users who performed a particular action, or set of actions, within a group in a 28 day rolling period. Each R&D group is expected to have a primary performance indicator they are using to gauge the impact of their group on customer outcomes. Where possible, groups should use Group Monthly Active Users (GMAU) or Group Monthly Active Paid Users (GMAPU) as their primary performance indicator. GMAU should be used when the group is early in its maturity and its primary goal is new user adoption. Paid GMAU should be the primary performance indicator when groups are more mature and have proven an ability to drive incremental IACV. We prefer measuring monthly active usage over other potential measures like total actions taken (eg total dashboard views), as we believe that measuring active usage is a better measure of true user engagement with GitLab's product. Since R&D groups often contain more than one category, picking one category to base the action, or set of actions on, is a recommended simplification as we do not have the data bandwidth to support measuring every category's usage at this time.
Target: TBD
Health: Unknown
Paid GMAU is defined as the count of GMAU (Group Monthly Active Users) that roll up to a paid instance for Self-Managed or a paid namespace for SaaS in a 28 day rolling period. When Paid GMAU is the focus area for a group, they should measure actions tied to`Up-tiered features`, which are features that are unavailable in the free tier, as this will ensure we are tracking usage that has a clear tie to incremental IACV.
Target: TBD
Health: Unknown
An action describes an interaction the user has within a stage. The actions that need to be tracked have to be pre-defined. AMAU is defined as the number of unique users for a specific action in a 28 day rolling period. AMAU helps to measure the success of features. Note - There are metrics in usage ping under usage activity by stage that are not user actions and these should not be used for AMAU. Examples include Groups - `GroupMember.distinct_count_by(user_id)`, which is the number of distinct users added to groups, regardless of activity, ldap_group_links - `count(LdapGroupLink)`, which is a count of ldap group links and not a user initiated action, and projects_with_packages - `Project.with_packages.distinct_count_by(creator_id)`, which is a setting not an action.
Target: TBD
Health: Unknown
A GitLab.com user, who is not a UMAU in month T, but was a UMAU in month T-1.
Target: TBD
URL(s)
Health: Unknown
A GitLab.com user, who is a UMAU both in months T and T-1.
Target: TBD
URL(s)
Health: Unknown
A GitLab.com Licensed User. For Self-Managed (data source - usage ping), a paid user is a user that is on a paid instance. For SaaS, a paid user is a user that is on a paid namespace.
Target: TBD
URL(s)
Health: Unknown
Target: TBD
URL(s)
Health: Unknown
A GitLab Group, which contains at least 1 project since inception and has at least 1 Event in a calendar month.
Target: TBD
URL(s)
Health: Unknown
A GitLab.com group, which is not a MAG in month T, but was a MAG in month T-1.
Target: TBD
URL(s)
Health: Unknown
A GitLab.com namespace both in months T and T-1.
Target: TBD
URL(s)
Health: Unknown
A GitLab.com namespace created in the last 30 days.
Target: TBD
URL(s)
Health: Unknown
A GitLab.com namespace, which is part of a paid plan, i.e. Bronze, Silver or Gold. Free licenses for Ultimate and Gold are currently included.
Target: TBD
URL(s)
Health: Unknown
Target: TBD
URL(s)
Health: Unknown
This is the conversion rate of customers moving from tier to tier
Target: TBD
URL(s)
Health: Unknown
A lost instance of self-managed GitLab didn't send a usage ping in the given month but it was active in the previous month
Target: TBD
URL(s)
Health: Unknown
Percent of users or groups that are still active between the current month and the prior month.
Target: TBD
URL(s)
Health: Unknown
The opposite of User Return Rate. The percentage of users or groups that are no longer active in the current month, but were active in the prior month.
Target: TBD
Health: Unknown
Stage Monthly Active Namespaces is a KPI that is required for all product stages. SMAN is defined as the highest AMAN within a stage in a 28 day rolling period.
Target: TBD
Health: Unknown
AMAN is defined as the number of unique namespaces in which that action was performed in a 28 day rolling period.
Target: TBD
Health: Unknown
Acquisition success measures how successful GitLab at integrating the new teams and technologies acquired. An acquisition is a success if it ships 70% of the acquired company's product functionality as part of GitLab within three months after acquisition. The acquisition success rate is the percentage of acquired companies that were successful. The target is 70% success rate.
Target: TBD
URL(s)
Health: Unknown
The sourced pipeline includes companies operating in a DevOps segment relevant for GitLab. Companies have developed or are working on product functionality which is either a new category on our roadmap or at a more advanced maturity than our current categories. Target is ongoing monitoring of at least 1000 companies.
Target: TBD
Health: Unknown
| Value | Level | Meaning |
|---|---|---|
| 3 | Okay | The KPI is at an acceptable level compared to the threshold |
| 2 | Attention | This is a blip, or we’re going to watch it, or we just need to enact a proven intervention |
| 1 | Problem | We'll prioritize our efforts here |
| 0 | Unknown | Unknown |
| Value | Level | Meaning |
|---|---|---|
| 3 | Okay | We are correctly capturing and measuring data for GitLab.com and self-managed instances. |
| 2 | Attention | Missing one of: GitLab.com or self-managed data. |
| 1 | Problem | Missing both: GitLab.com and self-managed data. |
| 0 | Unknown | Unknown |
Pages, such as the Engineering Function Performance Indicators page are rendered by an ERB template that contains HTML code.
Other PI Pages sectionThese ERB templates calls custom helper functions that extract and transform data from the Performance Indicators data file.
kpi_list_by_org(org) helper function takes a required string argument named org (deparment or division level) that returns all the KPIs (pi.is_key == true) for a specific organization grouping (pi.org == org) from the Performance Indicators data file.pi_maturity_level(performance_indicator) helper function automatically assigns a maturity level based on the availability of certain data properties for a particular PI.pi_maturity_reasons(performance_indicator) helper function returns a reason for a PI maturity based on other data properties.performance_indicators(org) takes a required string argument named org (deparment or division level) that returns two lists - a list of all KPIs and a list of all PIs for a specific organization grouping (department/division).signed_periscope_url(data) takes in the sisense_data property information from Performance Indicators data files and returns a signed chart URL for embedding a Sisense chart into the handbook.The heart of pages like this are Performance Indicators data files which are YAML files. Each - denotes a dictionary of values for a new (K)PI. The current elements (or data properties) are:
| Property | Type | Description |
|---|---|---|
name |
Required | String value of the name of the (K)PI. For Product PIs, product hierarchy should be separate from name by " - " (Ex. {Stage Name}:{Group Name} - {PI Type} - {PI Name} |
base_path |
Required | Relative path to the performance indicator page that this (K)PI should live on |
definition |
Required | refer to Parts of a KPI |
parent |
Optional | should be used when a (K)PI is a subset of another PI. For example, we might care about Hiring vs Plan at the company level. The child would be the division and department levels, which would have the parent flag. |
target |
Required | The target or cap for the (K)PI. Please use Unknown until we reach maturity level 2 if this is not yet defined. For GMAU, the target should be quarterly. |
org |
Required | the organizational grouping (Ex: Engineering Function or Development Department). For Product Sections, ensure you have the word section (Ex : Dev Section) |
stage |
Optional | the product stage (Ex: release) as defined in stages.yml |
group |
Optional | the product group (Ex: progressive_delivery) as defined in stages.yml |
category |
Optional | the product group (Ex: feature_flags) as defined in categories.yml |
is_key |
Required | boolean value (true/false) that indicates if it is a (key) performance indicator |
health |
Required | has two additional elements/property - level (inclusive value between 0-3) and reasons. This should be updated monthly before Key Meetings by the DRI. |
urls |
Optional | list of urls associated with the (K)PI |
sisense_data |
Optional | contains elements/properties related to Sisense, including chart (numeric Sisense widget ID), dashboard (numeric Sisense dashboard ID), shared_dashboard (Sisense shared dashboard ID), embed (v2) |
sisense_data_secondary |
Optional | same as sisense_data. Allows a second sisense chart to be included. |
public |
Optional | boolean flag that can be set to false where a (K)PI does not meet the public guidelines. |
pi_type |
Optional | indicates the Product PI type (Ex: AMAU, GMAU, SMAU) |
plan_type |
Optional | indicates if the metric is Free, Paid, or Both. |
telemetry_type |
Optional | indicates if the metric is available on SaaS, SM (self-managed), or Both. |
is_primary |
Optional | boolean flag that indicates if this is the Primary PI for the Product Group. |
instrumentation |
Optional | has two additional elements/property - level (inclusive value between 0-3) and reasons. This should be updated monthly before Key Meetings by the DRI. |
pi_workflow |
Optional | indicates the PI Workflow status |
Above ...Below ...At ...At or above ...At or below ...shared_dashboard, chart , and the dashboard key-value pairs to the corresponding Performance Indicators data file under the sisense_data property: in strings as it's an important character in YAML and will confuse the data parsing process. Put the string in "quotes" if you really need to use a :urls: should be an array (indented lines starting with dashes) even if you only have one urlmaturity.level and health.level display a value between 0 and 3 (inclusive).The PI workflow was presented in the Weekly Product Meeting on August 11, 2020. For a recap of this, please see the slide deck and watch the video presentation.
The objective of the PI workflow is to help the product organization achieve the Product Organizations FY21-Q3 OKRs:
To achieve this, we will be taking the following approach:
To track the stataus of this OKR, we'll temporarily be using the XMAU Tracking Sheet. This sheet is a temporary measure and we have an epic that's currently in progress to move this into the Product PI handbook page.
Note: XMAU is used to represent all the variations of AMAU, GMAU, Paid GMAU, SMAU, Paid SMAU, Section MAU, and Paid Section MAU.
The PI workflow outlines the steps required for putting a product performance indicator in place.
| Step | Description | Responsibility |
|---|---|---|
| Privacy Policy | The privacy policy step describes what product usage data we can collect from our users. | Product Analytics Responsibility |
| Collection Framework | The collection framework step describes our available tooling for collecting product usage data. | Product Analytics Responsibility |
| Event Dictionary | The event dictionary step outlines our single source of truth of the product metrics and events we collect. | PM Responsibility, Product Analytics Support |
| Instrument Tracking | The instrumentation step outlines how each product team implements data collection. | PM Responsibility, Product Analytics Support |
| Data Availability | The data availability step outlines the timing of a product release to receiving product usage data in the data warehouse. | PM Responsibility, Product Analytics Support |
| Data Warehouse | The data warehouse step outlines where our product usage data is stored. | Product Analytics Responsibility |
| Data Model | The data modelling step outlines how we transform raw data into a data structure that's ready for analysis. | Product Analytics Responsibility |
| Dashboard | The dashboarding step outlines how Sisense dashboards are built. | PM Responsibility, Product Analytics Support |
| Handbook PI Page | The handbook PI page describes how product performance indicators are added for each product section, stage, and group. | PM Responsibility, Product Analytics Support |
| PI Target | The target definition step outlines how targets are defined for each performance indicator. | PM Responsibility, Product Analytics Support |
The table below outlines the exact PIs we're asking each section, stage, and group to implement by end of FY21-Q3. This table is based off the previous guidance of focus areas. The implementation status for each of these PIs will be tracked on their respective Section PI pages.
Changes to be table below require sign off from the EVP Product or VP Product Management. To make updates to the table, please submit an MR with the reason behind the change and assign it to Scott or Anoop.
Dashboard data sources:
The standardized dashboard used for our PIs will have segments for both XMAU and Paid XMAU if the data source is available. Product teams may choose to focus on one or many of these segments to drive paid usage or overall usage.
| section.stage.group | XMAU (SM) | Paid XMAU (SM) | XMAU (SaaS) | Paid XMAU (SaaS) |
|---|---|---|---|---|
| dev | Yes, Section TMAU | Yes, Section TMAU | Yes, Section TMAU | Yes, Section TMAU |
| dev.create | Yes | Yes | Yes | Yes |
| dev.create.ecosystem | Yes | Yes | Yes | Yes |
| dev.create.editor | Yes | No | Yes | No |
| dev.create.gitaly | Yes | Yes | Yes | Yes |
| dev.create.knowledge | Yes | No | Yes | No |
| dev.create.source_code | Yes | Yes | Yes | Yes |
| dev.create.static_site_editor | Yes | No | Yes | No |
| dev.manage | Yes | Yes | Yes | No |
| dev.manage.access | Yes | Yes | Yes | Yes |
| dev.manage.analytics | Yes | Yes | Yes | No |
| dev.manage.compliance | Yes | Yes | Yes | Yes |
| dev.manage.import | Yes | Yes | Yes | Yes |
| dev.plan | Yes | Yes | Yes | Yes |
| dev.plan.certify | Yes | Yes | Yes | Yes |
| dev.plan.portfolio_management | Yes | Yes | Yes | Yes |
| dev.plan.project_management | Yes | Yes | Yes | Yes |
| enablement | Yes, PPI | Yes, PPI | Yes, PPI | Yes, PPI |
| enablement.enablement | Yes, PPI | Yes, PPI | Yes, PPI | Yes, PPI |
| enablement.enablement.database | Yes, PPI | Yes, PPI | Yes, PPI | Yes, PPI |
| enablement.enablement.distribution | Yes, PPI | Yes, PPI | Yes, PPI | Yes, PPI |
| enablement.enablement.geo | Yes | Yes | Yes | Yes |
| enablement.enablement.global_search | Yes | Yes | Yes | Yes |
| enablement.enablement.infrastructure | No | No | No | Yes, PPI |
| enablement.enablement.memory | Yes, PPI | Yes, PPI | Yes, PPI | Yes, PPI |
| ops | Yes, Section TMAU | Yes, Section TMAU | Yes, Section TMAU | Yes, Section TMAU |
| ops.verify | Yes | Yes | Yes | Yes |
| ops.verify.continuous_integration | Yes | No | Yes | No |
| ops.verify.pipeline_authoring | Yes | No | Yes | No |
| ops.verify.runner | Yes | No | Yes | No |
| ops.verify.testing | Yes | Yes | Yes | Yes |
| ops.package | Yes | No | Yes | No |
| ops.package.package | Yes | No | Yes | No |
| ops.release | Yes | No | Yes | No |
| ops.release.progressive_delivery | Yes | Yes | Yes | Yes |
| ops.release.release_management | Yes | Yes | Yes | Yes |
| ops.configure | Yes | No | Yes | No |
| ops.configure.configure | Yes | No | Yes | No |
| ops.monitor | Yes | Yes | Yes | Yes |
| ops.monitor.health | Yes | No | Yes | No |
| securedefend | Yes | Yes | Yes | Yes |
| securedefend.defend | Yes, GMAC | Yes, GMAC | Yes, GMAC | Yes, GMAC |
| securedefend.defend.container_security | Yes | Yes | Yes | Yes |
| securedefend.defend.insider_threat | Yes | Yes | Yes | Yes |
| securedefend.secure | Yes | Yes | Yes | Yes |
| securedefend.secure.composition_analysis | Yes | Yes | Yes | Yes |
| securedefend.secure.dynamic_analysis | Yes | Yes | Yes | Yes |
| securedefend.secure.fuzz_testing | Yes | Yes | Yes | Yes |
| securedefend.secure.static_analysis | Yes | Yes | Yes | Yes |
| securedefend.secure.threat_insights | Yes | Yes | Yes | Yes |
| securedefend.secure.vulnerability_research | Yes | Yes | Yes | Yes |
For our current state, see: Privacy Policy. For our roadmap, see: Rollout Plan: Privacy Policy for Product Usage Data.
For our current state and roadmap, see: Telemetry Direction Page: Collection Framework.
We currently have 500+ existing usage ping metrics but no proper documentation of what actions they track. The Event Dictionary will allow us to create a single source of truth for the metrics and events we collect. It will also help PMs better understand what data is currently collected and what metrics can potential be used as an XMAU. The event dictionary includes:
Note: we've temporarily moved the Event Dictionary from our Markdown docs into a sheet for easier editing. We'll eventually move this back into our docs once the majority of changes are done.
Instructions:
Work with your engineering team to instrument tracking for your XMAU. Focus on using Usage Ping as your metrics will be available on both SaaS and self-managed.
The Usage Ping Guide outlines the steps required for instrumentation. It includes:
Also see the Telemetry Guide and Snowplow Guide.
Instructions:
See Data Team Platform: Data Warehouse
Plan instrumentation with sufficient lead time for data availability. Ensure your metrics make it into the self-managed release as early as possible.
Timeline:
In total, plan for up to 51 day cycle times (Examples 1, 2). Cycle times are slow with monthly releases and weekly pings, so, implement your metrics early.
Instructions:
We need PMs to self-serve their own dashboards as data team capacity is limited. The data team will be focused on enabling self-service, advising PMs, and working on the more challenging XMAU dashboards.
To learn how to create your own dashboard, see Data For Product Managers: Creating Charts
To update the SMAU Summary Dashboards: GitLab.com Postgres SMAU Dashboard (SaaS) and Usage Ping SMAU Dashboard (SaaS + Self-Managed), please open a data team issue.
Dashboard Prioritization
For GMAU and SMAU data issues:
XMAU label to the data issues.For non-GMAU and non-SMAU data issues:
Instructions:
There are five Product PI pages: The Product Team page and section pages for Dev, Ops, Secure & Defend, Enablement.
We need all PMs to ensure their PIs are showing on the performance indicator pages. Based off What we're aiming for
To do so, we need a clear way to communicate to PMs exactly which PIs are remaining. We will be adding placeholder PIs for each section into the performance indicator file so that all required PIs show in the handbook. Once a PI is implemented, the actual PI will replace the placeholder PI.For more information about how PIs and XMAUs are related to one another, see PI Structure.
Instructions:
As a product organization, we need to get into the habit of understanding our baselines and setting targets for each stage & group. For the PI Target step, you will work with your Section or Group Leader to define targets for each of your XMAUs.
Instructions:
