Issue Prioritization Framework
Running Working Group Agenda (internal) | Working Group Page
Problems To Solve
- We currently do not have a standard way to attribute customer ARR on a more granular scale to issues that they've requested.
- The User Requested Issues dashboard currently sums total ARR for each customer family per issue, which doesn't adequately support making an a quantifiably accurate ROI for delivering the issue.
- We currently do not distinguish between "nice to have", "blocker", and "this will likely cause a downgrade/churn/prevent upsell." One customer may view Feature ABC as nice to have, whereas another customer desperately needs it.
- There is no clear separation for customer requests in terms of retaining vs. expanding with the customer.
- TAMs spend 30-40% of their time manually aggregating customer requested issues and gathering ad-hoc status reports.
- Manually compile customer requested issues - example
- Manually update master issue based on progress of issues in
gitlab-org/gitlab
- Continuous ad-hoc communication about status of issues and what release they will likely fall within.
- Pain points around setting expectations as Product uses a combination of
~deliverable
+ milestone to communicate to stakeholders if something is likely to be delivered within a given milestone.
Business Goals
- Standardized prioritization framework based on quantifiable data that enables us to determine urgency/value per issue/epic at scale and speed so that Product, Sales, and Customer Success can use a common language and model when discussing prioritization trade-offs.
- Product DRIs have more accurate sensing mechanisms to help them globally optimize their delivery backlogs resulting in increased customer retention and acquisition.
- Positively impact IACV growth and improve retention of existing ARR.
- Improved accuracy of prioritization feedback among departments through automation and standardized inputs.
- Further operationalize the process of creating effective bridges between Customer Success, Sales, and Product.
- Improved trust with Customers by providing self-service updates on their requested items.
- Remove the majority of manual processes required to aggregate customer requested Issues, which effectively represents $1M (30% per TAM = ~$30k per TAM x 35 TAMs) in TAM man hours that they can re-allocate to higher leverage activities.
- Provide a way for customers that don't have a dedicated TAM to self-service their input into the model and have the same experience as larger customers.
- Validate that this more robust prioritization model produces positive, quantifiable business outcomes so it can be incorporated more formally into the product and offered to our customers in the future.
Proposal
Manual Pilot
- Build model prototype
- Collect data from larger TAM group
- Engage with product and collect feedback
- Revise model
Operationalize Model
- Improve the user request issues dashboard by incorporating more granular value and urgency dimensions
- Push prioritization data to Gitlab via labels
Operationalize Customer Dashboards
Operationalize Self-Service for smaller customers
- Self-service form
- Instructions for customers
- ...
Exit Criteria
- Determine a viable model (Product#1458 (closed), https://gitlab.com/gitlab-com/Product/-/issues/1457)
- Implement and validate model (Product#1459 (closed))
- Verify at scale, operationalize processes, and measure outcomes In Progress
Think Both Short Term and Long Term
We want to develop a better prioritization framework for GitLab the company in the short term. Over the long term, we want to build prioritization frameworks into GitLab so other organizations can leverage them.
- Show closed items
Link items together to show that they're related or that one is blocking others.