The Customer Prioritization Framework was developed by the Issue Prioritization Framework Working Group as a way to improve the efficiency of the feedback loops among Sales, Customer Success, and Product. It provides a comprehensive system to categorize and measure customer, and prospective customer, demand for capabilities within GitLab. This page covers how the first iteration of the model works and how to interact with and interpret, the not public, internal-only dashboards that it powers.
The outcomes the framework is aimed at providing:
"What problems should I prioritize solving that would have the greatest impact on ARR retention and growth?"
"How can I easily find all of the customers interested in a given issue or all of the issues a given customer cares about?"
"Where should we consider investing additional resources relative to customer needs?"
"Which groups are critical to retaining ARR and which are critical to growing ARR?"
"How can I most easily influence global prioritization of customer related needs across all of Product?"
"What is the ratio of net new ARR to renewable ARR that is driving product feature requests?"
"How much existing account ARR is at stake vs. potential new opportunity net ARR?"
"How can I communicate my prospect's needs such that they are appropriately prioritized in a timely manner?"
"How can I easily see and track a list of issues requested by my customers without having to manually compile and maintain a list that requires constantly check-in on when solutions are expectd to be shipped."
"How can I most efficiently and effectively communicate the relative priorities of my customer's needs to Product?"
"How can I raise the visibility of, and escalate appropriately, my customer's support tickets?"
The customer prioritization framework is loosely based on concepts rooted in cost of delay and CD3. Important: While ARR is a key input to determining value, the scores are derivitive measurements and should not be conflated with the notion that if a given issue or epic is delivered, GitLab's ARR will increase by the derivative score amount or the customer is guaranteed to continue buying GitLab.
There are many inputs to the framework with the underlying goal of segmenting and measuring the value of an open issue on the basis of how it will contribute to the retention of current ARR and/or growth of net new ARR, and to do so within the context of every other issue in order to get a better understanding of what customer requested issues we could prioritize within R&D to significantly impact retaining existing customers or growing net ARR via landing or expanding.
The model is re-calculated on a daily basis to incorporate the dynamic nature of the inputs. Changes made to issues/epics on any given day will be reflected in the dashboards the following day.
The framework is powered by a model that consists of several key components:
To link an account, opportunity, or support ticket to an issue or epic, use the feedback template and Salesforce/Zendesk link to add a comment to the issue or epic in gitlab-org or any project or sub-group within this top-level namespace (ex: /gitlab-org/gitlab). For best results, only include one Salesforce or Zendesk link per comment. If you want to "unlink" an account from an issue or epic, simply remove the Salesforce or Zendesk link from the respective comment(s) on the issue or epic.
Supported link types:
CARR (total) field value in Salesforce.1. New - First Order, 2. New - Connected, and 3. Growth. This will map the issue or epic to the Net ARR in the linked opportunity.CARR (total)~customer priority:: label present, a default value of 1 is assigned.~customer priority:: label per description or comment. If there are multiple Salesforce or Zendesk links referenced in the same comment or description, we will attribute the first ~customer priority:: label to all of the links found in the comment or description.~customer priority:: label to the respective open issue./gitlab-org/... issues that are referenced in a customer's collaboration project creates an automated link between the account and the issue/epic, but the recommended path to take full advantage of the model is to add a comment directly to the /gitlab-org/... issue as ~customer priority:: can't be defined from a collaboration project.You can think about a priority point representing a "vote" on an issue or epic. Each customer or prospective customer starts with a retention priority point pool and growth priority pool of 0. When a Salesforce or Zendesk link is added to an issues or epic, we default to attributing 1 "vote" to the issue to either the retention or growth priority point pool depending on which type of link was referenced.
Optionally using the ~customer priority::2 through ~customer priority::10 label in the same comment as the Salesforce or Zendesk link provides a mechanism to cast additional votes (up to 10) on a single issue. There is no upper bound on how many retention or growth priority points a customer can "vote" in total across all issues. The fewer points, the more value each point will represent. The converse is also true. The more points that are distributed across issues, the less value each point will carry.
If you are adding a link to an issue or epic, here are some guidelines on how to think about which customer priority:: label to use:
| Label | Impact |
|---|---|
~customer priority::10 |
Blocker: The account is likely to churn or we will not be able to win the opportunity because the customer or prospect is unable to address their business needs. |
~customer priority::9 |
|
~customer priority::8 |
|
~customer priority::7 |
Critical: Not having an adequate solution to the problem is causing a significant loss of productivity or inability to achieve the desired business outcomes. |
~customer priority::6 |
|
~customer priority::5 |
|
~customer priority::4 |
Major: There is currently a workaround, but it's not ideal and should be addressed in the near future. |
~customer priority::3 |
|
~customer priority::2 |
|
~customer priority::1 |
Low: Purely a quality of life improvement but does not prevent the customer or prospect from realizing the value of GitLab. |
The value of one retention or growth priority point where the value is unique to each account as it represents a distribution of the account CARR for retention or total open opportunity net ARR for growth. It is calculated by counting the total number of retention and growth priority points an account has across all issues and epics to which they are linked.
retention priority point value = account CARR / SUM(retention priority points)
growth priority point value = open opportunity net ARR / SUM(growth priority points)
The score of an issue or epic taking into account all retention priority points and their respective values from all accounts that are linked to the issue. This effectively represents all account CARR evenly distributed across all linked issues in a non-duplicated manner.
The value for each account is calculated on a per issue basis as follows:
account retention score = ~customer priority::1-10 x retention priority point value
Once we have the scores for each unique account that is linked to an issue or epic, we sum them to get the retention score for the issue:
retention score = SUM(account retention score, account retention score, ...)
The score of an issue or epic taking into account all growth priority points and their respective values from all open opportunities that are linked to the issue. This effectively represents all open opportunity net ARR evenly distributed across all linked issues in a non-duplicated manner.
The value for each opportunity is calculated on a per issue basis as follows:
account growth score = ~customer priority::1-10 x growth priority point value
Once we have the scores for each unique account's opportunities that are linked to an issue or epic, we sum them to get the growth score for the issue:
growth score = SUM(account growth score, account growth score, ...)
This represents the combined score for growth and retention:
combined score = SUM(retention score, growth score)
Urgency allows us to incorporate the dimension of time into the overall prioritization model. The value ranges can be updated at any point in time depending on how GitLab leadership would like to globally influence prioritization across all product teams.
Retention urgency is a function of a customer's overall health as defined in Gainsight and their renewal date.
| Overall Health | Renewal > 18 mo. | Renewal > 12 mo. | Renewal > 6 mo. |
|---|---|---|---|
| Unknown | 1 | 1 | 1 |
| Green | 1 | 1 | 1 |
| Yellow | 1.5 | 2 | 2.5 |
| Red | 2 | 3 | 4 |
Growth urgency is a function of an opportunity close date and win probability. The value ranges were determined based on the observed distribution of probabilities and close dates across all open opportunities.
| Opportunity Probability (%) | Close Date > 6 mo. | Close Date = 3-6 mo. | Close Date = 0-3 mo. |
|---|---|---|---|
| Unknown | 1 | 1 | 1 |
| 61-100% | 1 | 1 | 1 |
| 40-60% | 1.25 | 1.5 | 2.0 |
| 0-39% | 1.5 | 2.0 | 2.5 |
Priority score is calculated similar to how retention score, growth score, and combined score but layers in the dimension of retention and growth urgency to the model.
account retention score with urgency = account retention score x account urgencyretention score with urgency = SUM(account retention score with urgency, account retention score with urgency, ...)account growth score with urgency = account growth score x opportunity urgencygrowth score with urgency = SUM(account growth score with urgency, account growth score with urgency, ...)priority score = SUM(account score with urgency, account score with urgency, ...)The priority score of the issue or epic that is inclusive of effort where effort is the weight of the issue or the sum of all issues within an epic. If there is no weight defined, a Input Weight message will be shown which links to the issue or epic that needs to be estimated by the relevant product group.
weighted priority score = priority score / weight
The higher the value, the higher the return that will be realized relative to the investment required.
Please refer to this spreadsheet for a practical example of how the model calculates each of the computed fields. In the example, there is only a single customer, but the same methodology applies to how scores are aggregated for a given issue or epic across all customers and prospective customers.
Column definitions:
Notable ID: The ID of the issue or epic.Notable Type: If the link is on an issue or epic.Notable Title: The title of the issue or epic.Group: The relevant product group that is the DRI for the issue or epic.Stage: The relevant stage to which the issue or epic belongs.Category: The relevant category to which the issue or epic belongs.Notable Weight: The weight of the issue or the aggregate weight of all issues within an epic.Milestone: The milestone to which the issue is currently assigned or the furthest out milestone to which an issue within an epic is assigned.Upvote Count: The number of 👍 an issue or epic currently has.Unique Accounts: The number of unique SFDC accounts linked to the issue or epic.Customer Reach: The number of total licenses across all SFDC accounts linked to an issue.Retention Score: See "Retention score"Growth Score: See "Growth score"Combined Score: See "Combined score"Priority Score: See "Priority score"Weighted Priority Score: See "Weighted priority score"Filters:
Column definitions:
Link Last Updated Date: The date the comment or descrption containing the link on the issue or epic was last updated.Milestone: The milestone the issue or epic is scheduled to be completed.Deliverable: Whether or not the relevant engineering team has committed to delivering the issue or epic within the scheduled milestone.CRM Account Name: The customer or prospect name from their respective SFDC account.Issue Epic Title: The title of the issue or epic.User Request Link: Which type of link is referenced on the issue. Account and ZenDesk ticket are retention while an opportunity is growth.Filters:
#wg_issue_prioritization