View the CSM Handbook homepage for additional CSM-related handbook pages.
A success plan is a roadmap that connects a customer's desired business outcomes to GitLab solutions. It is a living document, developed by the CSM. The input for a success plan comes in the first instance from the value-based conversations with the customer in the presales process and documented in the command plan, focusing on articulated business needs and including metrics where available. The success plan echoes these goals and further articulates metrics, and creates a roadmap for implementation via milestones. It is the strategic vision for the customer to realize success and value with GitLab.
These are some of the reasons we use a success plan:
Success plans are another facet of account engagement and are separate from collaboration projects. The success plan is meant for articulating and tracking high-level strategic business objectives, while collaboration projects are best used for async communication outside of cadence calls, particularly for issues where collaboration with cross-functional groups (e.g. Product & Engineering) is necessary.
As you read through this page, you'll likely notice the success plan described as a living document; this is intentional! A success plan is not a "set it and forget it" exercise. It should be something that the CSM maintains on an ongoing basis and iterates on as they learn new information.
Follow this link for the Success Plan certification on LevelUp: Click here
A success plan must contain:
The strategy section should capture the customer's desired business outcomes, and what GitLab is doing in realizing them.
Examples:
Additional resources that may be helpful in discovering your customer's business outcomes are:
Customer highlights is a high-level overview of the customer and other contextual details. This can include the following suggested headings:
It can also be valuable to capture significant past outcomes in this section, for example:
Reviewing the highlights, the reader should be able to quickly understand the customer's business, why they originally bought GitLab/upgraded to Ultimate and any significant achievements to date
Well-crafted objectives provide an actionable plan towards a customer's desired outcome. They should resonate with both GitLab and the customer.
Each objective CTA should be clearly related to a customer's business outcome (the "why"). This is ideally in the title, or within the CTA's comments.
Objectives should capture:
Within a success plan objective (or "CTA"), tasks can be used to further decompose the plan, assign customer DRIs and provide more timeline detail.
With these three elements, you can develop an objective that allows you to measure and report on progress towards outcomes throughout your book in a scalable way.
In FY24, the SA team has begun rolling out customer-agreed strategy roadmaps (Link to overview - GitLab internal).
These roadmaps outline the customer success outcomes that are now being defined in the presales process, in order to engage in a value-based conversation with the customer that starts in the sales process and carries through to the CSM engagement. For guidance on where to put the determined objectives when a strategy roadmap is in place, please see the Translating a Strategy Roadmap to a Success Plan section below.
When a strategy roadmap is not in place, the following guidance details the process the CSM follows to align on a customer's desired business outcomes.
Before we can develop a success plan, we need to understand what is driving the customer's usage of GitLab. This goes beyond the features they are interested in, and extends to the business value GitLab provides.
All stakeholders should agree on the business objectives that the customer is pursuing, which products and services will help them reach that goal, and to keep the scope focused to 1-3 objectives. As you close out objectives, you can restart the process to define and add new ones.
Prepare questions to validate your existing knowledge of the customer's business outcomes and pain points, and learn about business outcomes you don't know yet.
For each business objective, review with the customer:
It's important to share progress with everyone involved as time goes on. The Sales team and the customer should both be kept up to date on where the success plan objectives and tasks stand, so they can continue working on new tasks and in turn sharing the progress with anyone else they think should be aware.
A customer’s business and strategies will change, so the value that they need from you will change with that. To stay up to date, show the success plan to the customer regularly to help keep a fresh understanding of their needs. You can email a report to the customer once a month (or other frequency), listing the objectives and inviting them to reply if they’re out of date. Follow the instructions on how to share a Gainsight ROI success plan.
It's also helpful to identify key times when you interact with a customer that would be good opportunities to review and refresh the success plan. This would ideally be when a discussion of business goals feels appropriate and the right stakeholders are at the table, for example: key handoffs between teams, EBRs, or executive check-ins.
It's recommended for CSMs to use EBRs and/or other recurring meetings such as cadence calls) to review steps achieved thus far and set next steps or new objectives as needed. After these meetings, it's important to log an "Activity" in the relevant objective to record how the customer is trending towards their goals. Before closing an objective, get confirmation from a customer (ideally in writing) that it has been achieved and include that in the activity log.
To keep track that the success plan is up to date, use the custom date field on the Objective in the success plan, “Last Validated”. The CSM will update it when they get confirmation from the customer that it is still a business priority for them.
Internally, CSMs can use the data to track their own trends and objectives achieved over time (e.g. quarter over quarter reports) and use the progress of the success plan to measure the ROI health scorecard.
Gainsight is the platform we use to develop and manage success plans. Below are the steps to create a success plan, followed by best practices and recommendations to apply these steps in practice.
When a CSM is assigned to an account, an active ROI Success Plan will be automatically created with a due date 365 days from the day it is created. To create an additional success plan in Gainsight, perform the following steps:
Customer Name ROI Success Plan" for customer-facing plans and "Customer Name Internal Success Plan" for internal plansAfter a success plan is created, you will need to input the strategy, highlights, and objectives that you've collected from working with the customer.
Success plans can have multiple objectives, though each needs to reflect a key business goal for the customer so typically a customer will have two or three. Key components of the objectives in the success plan include:
Objectives should be actionable, and Gainsight provides a way to create milestones as part of the objective, called tasks. A task in Gainsight is equivalent to a milestone in GitLab's historical success plan terminology. In short, the objective is the goal and the tasks are the key milestones to getting there (similar to Objectives and Key Results).
To create tasks, perform the following steps:
Tasks will affect the overall completion of the objective, and provide more granular visibility into progress on the objective when looking at the Gantt chart. To do this, navigate to the Gantt chart tab (next to the Objectives tab) in the success plan and confirm the representation captures the plan. You can adjust dates accordingly (for example, if a task actually started in the past but the entry defaulted its start date to today's date).
Finally, next to the success plan due date, change the "Status" of the success plan from "Draft" to "Active". Don't forget this step, as it determines if your success plan with have a green health score and if your objectives will show up in your cockpit.
During pre-sales, a Strategy Roadmap is created by the Solutions Architect and shared with the customer. The Strategy Roadmap is a mutually agreed roadmap for achieving value through GitLab adoption. Once an account transitions to post-sales, the CSM will be the directly responsible individual (DRI) for transitioning the Strategy Plan’s objectives and timeline to the customer's Success Plan in Gainsight. The aim is to retain information from Pre-sales to Post-sales without requiring customers to repeat themselves. During the internal account transition between AE/SA to CSM, the pre-sales team will provide the Strategy Roadmap to the CSM. This information can then be utilized during an Executive Business Review (EBR) at the 6-month mark, post implementation.
To translate the Strategy Roadmap to a Success Plan follow the steps below:
Targeted Benefits (by Functional Team) section on Slide 6 to the Success Plan's Strategy sectionObjectives (by Functional Team) from Slide 6 by creating an Objective and filling in all available detailsActivities from Slide 11 by creating Tasks under the respective ObjectiveOn a bi-annual basis (once in the first half of the fiscal year February 1 through July 31, and again in the second half ending January 31), success plans must be manager-reviewed and verified via a checkbox within the Gainsight interface.
Managers are to coach each CSM they work with to ensure that all required components are present, with each plan having at least one active objective.
Once the manager and CSM reach agreement that the success plan articulates the path to customer value realization (through adoption), the manager should click the appropriate checkbox as shown below:
The ROI success plan is the "public-facing" plan that we develop and maintain in collaboration with the customer. It is intended to be shared between GitLab and the customer, and should be considered the foundation of our strategic engagement and the reference for an Executive Business Review.
To share a ROI Success Plan, click the link icon next to the success plan due date and status, search for the users you want to share it with, then click "Preview and Send" and send the email. Alternatively, you can export the success plan by clicking "Export" at the top right.
Note as we have not yet had the capacity to update stages to use cases in Gainsight, you'll see 'stage' referenced at times in this guidance and within Gainsight.
Use case adoption can consist of two different motions: enablement and expansion, and each belongs in a specific success plan. Understanding the differences and similarities between these motions is key to properly building your success plans and driving stage adoption plays.
For understanding the Use Case Enablement and Expansion reporting, see Reporting on Expansion and Enablement Objectives.
The purpose of these fields is to provide additional, helpful information as you create and work on the Success Plan. The fields are from Salesforce.
[CP] fields are all from the Command Plan associated with the most recent Closed - Won New Business. Use these fields to track if the customer is adopting GitLab for their intended purpose. Refer to Command Plan handbook page for details on field definitions.
GitLab’s Value Pillars highlight the current trends in the market and emphasize the importance of being proficient in software development, security, and deployment to succeed in the fast-paced world of innovation. These pillars dive into the challenges faced by companies undergoing digital transformation, such as the need to transition from project-driven to product-driven development, limited visibility, and increasing responsibilities for developers. Another challenge is tool chain sprawl, where the use of multiple point solutions leads to inefficiencies and complexity. All of this emphasizes the need for consolidation of tool chains to drive automation, productivity, and cost-cutting measures as the market is seeking a comprehensive DevSecOps platform like GitLab to help build better software faster and increase developer productivity throughout the software development lifecycle.
Some of the most common goals we hear from our customers are to improve developer experience, increase productivity, measure impact, secure the software supply chain, and ensure a smooth cloud migration. GitLab is the most comprehensive DevSecOps platform that empowers development, security, and operations teams to build better software faster. It offers end-to-end visibility, better insights, improved collaboration, and faster time to value. GitLab covers all aspects of the software delivery process, from planning and creating to integrating and verifying, deploying, operating, monitoring, and improving. It allows for proactive identification and remediation of vulnerabilities, seamless tracking and resolution of issues, and collection of data from requirements to production to ensure high-quality code delivery.
As you continue to have strategic conversations via EBRs or cadence calls with your customers, please reference Level Ups DevSecOps training. FYI: value pillars slide/talk track can be found around the 5:00 min mark in the “The DecSecOps Story: Official Talk Track 2023” portion of the training.
The value pillars slide and overview of the talk track has also been added to the EBR deck (slide 12) to ensure these are being discussed with the right personas during the EBR but please don’t wait for the EBR! These can also be discussed during your cadence calls and reaffirmed with your customer during the EBR.
When talking through the value pillars slide with your customer, what you will want to understand is if the 4 value pillars on the slide resonate with the customer and will allow you to dig deeper if they say “yes” to one of the 4 pillars. If not, or the customer is unsure, that is a great time to ask what other objectives they are looking to pursue in the coming months and what metrics they need to support that.
Highlighting these themes will be crucial in understanding what each of your customers are trying to achieve and how GitLab can help them achieve it. For a full overview of each value pillar, what pain point it’s addressing, along with questions to ask to better align on the metrics and KPIs, please refer to this document. Also, Highspot is a great resource for the entire official customer deck of 2023 including talk track and how to position with your customer.
Below lists out each value pillar and the KPIs / metrics we should be driving toward for each. This can be used as the basis for the value GitLab can show to address these objectives.
| Value Pillar | KPI | |
|---|---|---|
| Make developers more productive | Release Frequency, Cycle time, MR Efficiency, Code Commits, Time to developer onboarding, Time spent in review, # of re-approvals / other interventions, # code defects | |
| Measure Efficiency and productivity | Deployment frequency | |
| Secure the software supply chain | Security audit findings, Incident response time, Context switching time, # of compliance/regulatory frameworks customers have gotten through after adopting GitLab | |
| Accelerate cloud migration | # apps migrated, Percentage of apps targeted for migration that have migrated, Cycle time, Deployment success rate |
When talking to customers about their objectives, we want to level up the conversation to strategic outcomes. Ideally, the customer will provide us a business outcome in their own words. However, we won't always be able to get that from the customer, and in which case we can use our value drivers to describe the strategic outcome.
When evaluating the customer's articulated outcome, a good way to know if it's a strategic outcome is whether you can connect it directly to one of our value drivers. In practice, if you can describe the connection between the outcome and a value driver with little to no intermediary explanation, it's likely a strategic outcome.
Now that we've gone through the parts of a good objective, let's review some examples of good ones as well as ones that could use improvement.
Example 1:
Title: Reduce SDLC times with higher reliability by implementing HA
Category: ROI
Metrics: Reduce SDLC time by 30%; Achieve 99.999% uptime; Scale to 5,000 users
Comments: The customer's GitLab instance struggles with poor performance and instability, sometimes going offline during peak usage times and costing development teams time, slowing their release cycles.
This example provides the three main components. We have the "what" (higher reliability by implementing HA), the "why" (Reduce SDLC times), and the metrics that will let us determine whether we've achieved the objective, both strategic (SDLC time reduction target) and operational (uptime and scalability).
Example 2:
Title: Reduce security risk and operating costs by adopting SAST
Category: Stage Adoption
Metrics: Add SAST scanning to 90% of projects; replace existing scanning tool
Comments: The customer wants to adopt the "shift left" security model, and conduct static code scanning earlier in the SDLC. They have an existing tool that runs late in the cycle and is expensive.
Here we have all of the elements, and actually even have two strategic outcomes with one objective! The customer has given us reducing risk and cost reductions (efficiency). Since this is a new part of GitLab that the customer wants to use it's a use case Adoption objective. We have both a metric related to the adoption across projects, as well as a "binary metric" of replacing a different tool with GitLab. The additional details in the comments help us to shape the narrative of the value we're providing.
Example 3:
Title: Deliver better products faster by adopting GitLab CI
Category: Stage Adoption
Metrics: All new projects use GitLab CI; 75% of existing projects are migrated to GitLab CI from the existing CI tool within 12 months
Comments: The customer's current CI system is cumbersome and requires a lot of administrative overhead to maintain, which slows down the SDLC. They want to replace it with GitLab CI, and conduct a phased migration as well as standardizing on GitLab CI for all new projects.
This objective is using one of our value drivers to describe the strategic outcome. The metrics allow us to track both new projects and existing projects, but as two separate items since they require a different approach. The comments let us describe additional reasons for doing this.
Example 1:
Title: GitLab CI
Category: Stage Adoption
Metrics: Increase GitLab CI usage
Comments: Customer wants to use GitLab CI more.
This objective is lacking in general detail, and provides no strategic outcome for the listed action. There is no definitive metric. At best we can call this an operational outcome since it focuses on tool usage, but since we don't know why they want to use it we can't determine whether they're getting the desired result and value.
Example 2:
Title: Improve reliability with HA
Category: ROI
Metrics: Uptime of 99.99%
Comments: Customer is having downtime issues under heavy load, and needs to be able to scale to the demand.
This is a good operational objective, but we have no articulated strategic outcome. This gives us a "what" and metrics, but there's no "why" that lets us show business value. It's a good starting point, but we'd want to dig deeper into the impact of doing this (and of not doing this) on the business.
The tasks for an objective are the key milestones we will need to accomplish in order to meet the objective. These should be actionable, and they should be granular enough to provide a clear path to success.
Here is an example of a task list that is too broad:
- Initial discovery meeting
- Provide implementation plan
- Implement GitLab CI
The time between each of these tasks is likely weeks, and there is no detail about how we're actually going to implement CI.
Here's a task list/set of milestones that are a little more actionable and detailed:
- Initial discussion about adopting GitLab CI
- Complete discovery call
- Determine interest and create an implementation plan
- Finalize the implementation plan with the customer during review meeting
- Schedule enablement with admins and key users
- Evaluate metrics from the first phase of implementation
- Complete implementation in accordance with implementation plan
- Evaluate metrics after implementation plan has been completed
- Record adoption
The level of detail provides a step-by-step path to moving the customer from the starting point to completion, and accounts for the need to monitor progress on a regular basis.