Best Practices for Building Value with Customers

The below page overviews some best-practices to build value with customers. For a full overview of Sales Operating Procedures, see the four phases here.

Studying your customer and prospects accounts to bring maximum value

Every GitLab customer is unique. For this we believe we must spend time understanding which of their Problems can GitLab solve in order to show them how and if we can help.

It starts by understanding the bigger picture your customer is working towards, this means taking a step back from the technical requirements, to understand why those are important to the business.

Build a Value Deck

A Value Deck is dedicated to your focus accounts on which you will be spending more time. It is a deck that contains high level information on the Corporate Objectives, Business Strategies, Key initiatives and Challenges.

We then use this information to formulate a Problem Statement that sums up your customer’s Challenges and what could happen if the Business Strategies and thus Corporate Objectives are not met.

Spending time on this will help you understand your customers better to work smart together, it will also help you formulate the business value at the Commercial Validation stage.

You can introduce the Value Deck at any stage but it is always best to do it before you start prospecting as it can help you build customised emails to your different accounts.

Make it collaborative: work on it with your customer (or print a blank version and offer them to fill it), and have them review your findings to see if there is anything to add. Your champions will appreciate that, and can share more details about their Challenges and Key Initiatives than Uncle Google.

Standard Implementation Sequence

The GitLab product is incredibly well matched to customer needs. In fact, we almost always earn a customer and grow quickly if they simply 1) give it a real try and 2) understand it. That means our best sales motion is to ensure we accomplish both at the same time. We’ve learned that a hands-on workshop is the best way to help the customer understand and make good decisions from the first conversation to the first expansion decision to the move to a higher tier and to the renewals down the road. At every step, a workshop is the most efficient and effective way to serve the customer.

Goal for every conversation with a customer:

• Agree to a workshop
  • A workshop is a great way to give value to our prospect and have a conversation in context about GitLab. Even if the prospect does not move forward with GitLab, they should always be much better off for having done the workshop. This can be a workshop of any kind as long as a) the key people at the account are learning about the full capability of GitLab in their context and b) they are learning hands-on with the product (not just in slides). When the customer has the right people in one place and working hands-on to see what’s possible, GitLab almost always moves to the next stage of the adoption or growth process with the customer. The product is an incredible fit, they simply need to see it live and in their context. A workshop is much more effective than a “trial” opportunity as we can greatly accelerate both the time to value for the customer and the time to understanding GitLab in their own unique environment.

Sales Motion and Sequence:

1. Initial conversations: In an early conversation when a customer is still trying to learn about GitLab, agree to a workshop with decision maker and involved team members to learn about end-to-end DevOps in a hands-on workshop to see what would be possible in their environment and exit with a working example to evaluate and better understand DevOps at 5x speed and better security and quality at the same time.
   1. DELIVER: DevOps Best Practices workshop
   2. Give customer a complete understanding of how their own company could be successful with end-to-end DevOps and GitLab in their own environment
   3. Hands-on setup of GitLab in their own environment => This is now the PoC deployment in place and running
   4. Begin PoC and with framework to measure success and report back on their real-world experience
   • On completion, move to an initial deployment and opportunity to become a customer.
2. First Purchase: When a successful PoC is completed: _agree to another workshop
   1. DELIVER: Demo of how to use GitLab in their phase 1 deployment. Show the desired end-state to the customer.
   2. Train customer on GitLab best practices
   3. Set customer up with Shared Compute (attached Runners and Kubernetes clusters)
   4. Leave demo with agreed deployment plan, timeline and target results
   • On completion: customer purchases subscription
3. CI Expansion conversations: If not in the first deployment, as soon as possible agree to a CI workshop
   1. DELIVER: CI best practices workshop, training and hands-on training for customer
   2. Set up shared runners for the customer during the workshop every time. Ensure this is in place before completing the workshop
   3. Schedule CI training for the broader team at the customer
   • On completion: Expand subscription user base as customer gets broader value from use of CI without having to move up in tier
4. Department expansion conversations: When a customer has great success with GitLab in part of the company but other departments/organizations have not yet adopted: agree to a workshop with the new organization to save them time. In a 4 hour workshop, that new organization can have developers, DevOps managers, integration teams, etc. all emerge with:
   1. A complete understanding of how their own company has been successful with end-to-end DevOps and GitLab in their own environment
   2. A working example to evaluate real development in their own environment
   3. A framework to measure success and report back on their real-world experience
   • On completion: deploy production users on already implemented instance and ensure all are fully trained and successful.
5. Up Tier conversations: When a customer is interested in capabilities in a higher tier (security in Ultimate, for example) agree to a workshop so they can see the benefit of end-to-end DevOps with security from the very first commit. These are 1 day workshops and a big investment in our customers’ success:
   1. DevSecOps Workshop: Dev, Ops, and Security team members fully understanding DevSecOps and how to implement it. Security automation, auto DevOps, etc. Implement Ultimate in workshop to allow hands-on experience and results.
   2. Kubernetes Workshop: Cloud-native best practices workshop for fully-modern development with fast cycle time and high security and quality. Support our customers to be expert in Kubernetes.
   3. End-to-end DevOps: Using all stages of DevOps. Use remaining stages of GitLab for fastest possible cycle time with highest possible security and quality.
   • In both workshops, deliver a framework to measure success and proof points in agreed cases that are important in their specific context.
   • On success, renew customer on higher tier (Ultimate, in this case) and ensure all users are trained and fully utilizing the new capabilities.

Tracking Proof of Concepts (POVs)

In Stage 3-Technical Evaluation, a prospect or customer may engage in a proof of concept as part of the evaluation. If they decide to engage, please fill in the following information, as we will use this to track existing opportunities currently engaged in a POV, as well as win rates for customers who have engaged in a POV vs. those that do not.

1. In the opportunity, go to the 3-Technical Evaluation Section.
2. In the POV Status field, you can enter the status of the POV. The options are Not Started, Planning, In Progress, Completed, or Cancelled.
3. Enter the POV Start and End Dates.
4. Enter any POV Notes.
5. Enter the POV Success Criteria, ie how does the prospect/customer plan to determine whether the POV was successful or not.

View page source - Edit this page - please contribute.