View the TAM Handbook homepage for additional TAM-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 TAM. 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 technical and tactical initiatives and to act as the primary communication method besides cadence calls on a day-to-day basis on issues to solve.
As you read through this page, you'll likely notice that the success plan is continually 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 TAM maintains on an ongoing basis and iterates on as they learn new information.
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 TAMs 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 TAM will update it when they get confirmation from the customer that it is still a business priority for them.
Internally, TAMs 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 TAM 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 NameROI Success Plan" for customer-facing plans and "
Customer NameInternal Success Plan" for internal plans
Success plans can have multiple objectives, though it’s best to only have up to three at a time for focus and achievability. Key components of the objectives in the success plan include:
Stage Adoption, then select from this dropdown which stage you're helping the customer adopt
Objectives should be actionable, and Gainsight provides a way to create action items 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 set of tasks are the way to get 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.
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.
This success plan contains a few key components that combine to provide a summary of the customer, their business outcomes, and what we are doing to achieve them with GitLab.
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.
When planning for future initiatives you want to work on with your customer that aren't yet on the roadmap, the internal success plan is the right approach. Unlike the ROI Success Plan, the internal plan is internal to GitLab only. It is for use by the TAM and the rest of the account team to keep track of things you're working on and/or plan to do at a later point.
A good example of when to use an internal success plan is when the team is working on stage expansion (as opposed to stage enablement).
The strategy section is a high-level overview of what GitLab is doing with the customer. At a glance, the reader should be able to see what we plan to do with the customer to drive value and success, and also to improve adoption and growth. This does not need to be as detailed as the objectives, but it should still let the reader understand what our overall plan is. This is required and especially important for ROI success plans, but still important for internal success plans so it's easy to understand what our strategy is.
Customer highlights, like the strategy section, is a high-level overview of the customer. This can include:
Reviewing the highlights, the reader should be able to quickly understand the customer's business, why they bought GitLab, and what they are interested in achieving. The highlights section is also required for ROI success plans and recommended for internal success plans.
Objectives are at the heart of a strong success plan, because they describe both the intended business outcomes and the actions we will take to achieve those outcomes. Well-crafted objectives provide an actionable plan that resonates with everyone involved, both within GitLab and on the customer side.
A good objective should contain three components:
With these three elements, you can develop an objective that allows you to track progress on the actual implementation, while measuring progress and tying the results back to a strategic business outcome. You are able to address the needs of the customer's operations team, as well as their business and strategic interests.
There are two types of objectives: Stage Adoption and ROI.
Stage adoption can consist of two different motions: stage enablement and stage 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.
Please review this 3-minute video (GitLab only) on how to open a stage adoption objective and categorize it correctly in Gainsight to enable reporting on our team's progress; the topics the video includes are:
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.
Title: Reduce SDLC times with higher reliability by implementing HA
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 objecive, both strategic (SDLC time reduction target) and operational (uptime and scalability).
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 Stage 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.
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.
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.
Title: Improve reliability with HA
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 actual steps we will take to acheive the objective. These should be actionable, and they should be granular enough to provide a clear path to success. If your objective is likely going to take a long time and require coordination between a lot of different groups, incorporate the need for check-ins and planning meetings into the tasks, so that you can stay on track by regularly reviewing progress with the customer.
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 that's a little more actionable and detailed:
- Initial discussion about adopting GitLab CI - Schedule discovery call with stakeholders - Complete discovery call - Send follow-ups and review the interests discussed during discovery call - Schedule implementation plan review meeting - Finalize the implementation plan with the customer during review meeting - Progress check-in meeting - Evaluate metrics from the first phase of implementation - Progress check-in meeting - Evaluate metrics from the second phase of implementation - Progress check-in meeting - Complete implementation in accordance with implementation plan - Evaluate metrics after implementation plan has been completed
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.