SA Onboarding - SA Practices - Sales Plays - Tools and Resources - Career Development - Demonstration - Processes - Education and Enablement - SA Content
Proof of value is a combination of technical evaluation and the communication of the expected business value of a solution. The solution, its practical application, and how it drives specific business value are proven and documented through the POV process.
Solution Architects are instrumental in guiding prospects and customers to carry out a successful Proof of Value. POV's should focus on specific prospect/customer business outcomes that cannot be achieved through other consultative interactions.
Any GitLab product evaluation should remain separate from GitLab high availability architecture and implementations.
A POV is conducted with a GitLab trial license either using GitLab.com or a self-managed instance. Due to cost, time, and the associated opportunity risk, a POV should not be the default course of action for GitLab prospects/customers.
Must tie to an opportunity for a new logo or up-tier to ultimate for an existing customer with a net ARR over 100K or with significant LAM
It is guided by GitLab SA to run the scoped hands-on technical evaluation with the prospect/customer, collaborate with the sales (SAE, AE) with defined business outcomes and GitLab values
Prospect/customer has identified and provided available technical and business resources to perform the evaluation, discuss / assess the results to map to the outcomes and value
Top business drivers are identified with POV scope, success criteria of the POV are defined to execute the POV and subsequently drive next step in the deal process
Must identify the champion and economic buyers and they must be in agreement (e.g., “sign-off”) on the success criteria; faciliate the executive connection and sponsorship
A Command Plan is populated in Salesforce for the opportunity with the following fields: Why Now Why do anything at all Metrics Decision Process - stakeholders Pain Access to economic buyer Impact of not solving that(Compelling event with business needs)
Top customer business values mapped to one of the GitLab solutions: DevSecOps, Software Compliance, Automated Software Delivery, and cumulatively DevOps Platform.
SA working with SAE and AE can define the POV scope with the customer, with alignment to the business values and the GitLab solution. For each solution, the typical scope and acceptances are listed for reference but the team should define the scope, time and execution with acceptance for each engagement.
A POV, no matter the type, should be validated by the Solutions Architect. Therefore, the SA Validated Tech Evaluation Start Date field on the Opportunity needs to be filled with the date the POV would start. Likewise, the SA Validated Tech Evalulation End Date field should be entered when it completes.
In order to track a POV correctly in Salesforce, the Strategic Account Executive should position the opportunity as Stage 3. The Solutions Architect will create the POV object within SFDC when the prospect or customer has indicated interest in moving forward with a POV.
To track a POV, click the Proof of Values tab from the top menu bar in Salesforce. Create a new POV using the New button. Alternately, the Solutions Architect may select the relevant Opportunity, scroll down to the related list labeled Proof of Values and click on the "New Proof of Value" button. This will automatically associate the POV with that Opportunity while all other fields need to be manually completed.
Complete the following fields at minimum:
Once the POV begins, the Solutions Architect should change the Status field from New to In Progress. When the POV is complete, the Solutions Architect should change the Status to Closed and the Result should be identified as Successful or Unsuccessful. Freeform notes should be added to support the reason for the successful or unsuccessful result.
When an opportunity is well-qualified for a Proof of Value, Enterprise opportunity win rate is over 90% versus around 30% for other technical evaluations (e.g., tech eval, trials, proof of concept).
The field currently records a considerable volume of technical evaluations as Proof of Values. Recording nonqualified activity as a POV makes it challenging to track where we can up-level our strategy in an opportunity for a qualified Proof of Value or Value Stream Assessment.
Without the ability to efficiently report on the technical win activity and proof of value work, it's difficult for Sales and SA leadership to identify coaching opportunities and better predict outcomes.
An approval workflow is rolling out to allow Sales and SA leaders to regularly review our activity while marking well-qualified technical win activity as Proof of Values.
Please work closely with your SA or Sales leader counterpart to regularly review opportunities with a Proof of Value object while marking well-qualified POVs with approval.
Sales and SA leader participation in the POV approval process will ensure we can quickly and regularly identify opportunities for coaching and predictability.
#troops-pov-created slack channel.#troops-pov-created slack channel for new POVs. When a new POV is created, asynchronous or synchronous collaboration on the quality of the opportunity commences.Solutions Architects are the owners of the POV, guiding prospects through a successful experience with GitLab. As such, Solutions Architects should be the primary contacts for questions and issues experienced by the prospect during the POV. If support is required for an unforseen technical issue, some POVs may qualify as priority prospects and may contact the support team.
Many prospects are tempted to include implementation of GitLab high availability as part of a POV. In this case, the implementation components should comprise a separate POV entirely, separating GitLab functionality evaluations from implementation, load and performance components.
Other best practices for POV’s:
Below is best practice guidance for conducting each type of POV. These processes share a similar goal of meeting identified business outcomes for the customer, but they vary based on engagement style, POV duration, location and intensity. The following applies to all POV's:
POV-related calls may be recorded with customer consent. Recordings may be stored in Chorus, in a folder on Google Drive (if recorded locally), or within the project repository (if small). Any recording links should be identified in the notes stored within the Documents directory of the project repository.
There are multiple options when executing a POV. The POV type chosen should reflect the wishes and best fit for the customer. POV types, in order of usage frequency, include:
Best practices specific to each type of POV follows.
The Guided POV is the most commonly utilized type of POV for Enterprise accounts. These will commonly have a 30 to 60 day duration.
For a guided POV, the SA must utilize parts or entire Guided POV document which validates POV dates, success criteria and assumptions of both GitLab and the prospect. The 4 fields below are mandatory for strategic POVs:
These POV's are marked by regular touch points and consistent interaction over time without requiring full time dedication to the GitLab evaluation on behalf of the customer. It is common to have kickoff meetings, technical support calls, weekly retrospective calls and POV conclusion calls when running a Guided POV. These meetings may be represented by the following suggestions:
GitLab Attendees: Strategic Account Executive, Solutions Architect
Agenda:
Attendees:
Agenda:
Attendees:
Agenda:
Attendees:
Agenda:
The On-site or Hands-On(virtual) POV is typically the shortest and most intense POV. It is critical that before this type of POV begins:
The SA will typically join the client at their chosen location(or virtually) and work directly with the team there to quickly identify the value proposition of GitLab within their environment. The SA will commonly dedicate themselves to the client for a fixed few hours every day(or agreed upon cadence) of the week for this POV.
The objective of the daily(regularly cadenced) meetings will be:
The Paid POV is less common than other types of POV's. These will commonly have duration greater than 60 days, and the customer will pay for usage of GitLab for the duration of the POV. Before this type of POV can begin, it requires a GitLab prorated licensing purchase to be completed. These POV's are marked by regular touch points and consistent interaction over time without requiring full time dedication to the GitLab evaluation on behalf of the customer. This type of POV will commonly have a larger ecosystem focus, where the value of GitLab is dependent on interactions with other tools and environments within the client's ecosystem. It is common to have kickoff meetings, technical support calls, cadenced retrospective calls and POV conclusion calls similar to those identified for a Guided POV.
When a prospect has an internal POV process to follow, or when time is of the essence, a Lite POV is utilized.
For a Lite POV, the SA may utilize the Lite POV document (only accessible to GitLab team-members), which validates POV dates, success criteria and assumptions of both GitLab and the prospect.
In the case of a Lite POV, the Solutions Architect is expected to be the sole GitLab contact. "Lite" is determined case-by-case by the size of the prospect as well as their ability to engage with GitLab.
To use the Lite POV template, begin by making a copy of the master document for each POV.
Edit each area highlighted in yellow within the document to include pertinent information for any particular prospect. This information includes basic data like the prospect name and GitLab team-member details, as well as data to be collaboratively identified with the prospect, such as primary objective, required capabilities and the environment information. Delete any red-colored instructional text.
Finally, ensure both GitLab and the prospect have a copy of the document. Schedule weekly meetings for the duration of the POV via calendar invites prior to distributing the GitLab Enterprise Edition license for the POV.
Commercial Sales POV's are commonly executed as a variety of the Lite POV, though they may not utilize the Lite POV document. Typical customer interactions for Commercial POV's are identified below.
As an alternative (or in addition) to using a collaboration GitLab project, a document is available which helps outline the details of a POV. The POV template document (only accessible to GitLab team members) provides the framework for a successful POV by addressing the primary business value driver, the current situation, the desired objective, the required capabilities, metrics and environment information.
This document suggests and verifies specific success criteria for any POV, as well as outlining a mutual commitment between GitLab and the identified prospect parties. It also specifies the limited timeframe in which the POV will occur.
To use the full POV template, begin by making a copy of the template document (only accessible to GitLab team members) for each POV.
Edit each area highlighted in yellow within the document to include pertinent information for any particular prospect. This information includes basic data like the prospect name and GitLab team-member details, as well as data to be collaboratively identified with the prospect, such as primary objective, required capabilities and the environment information. Delete any red-colored instructional text.
Finally, ensure both GitLab and the prospect have a copy of the document. Schedule weekly meetings for the duration of the POV via calendar invites prior to distributing the GitLab Enterprise Edition license for the POV.
Below is an evolving list of projects that have proven beneficial during POVs, which may be a great starting point to offer customers.
These projects have a very simple set of code that provides the ability to demonstrate the happy-path for a POV. While these are more in the Hello World category of projects, they tend to have simple mechanizations to exercise different parts of GitLab. SAs have used these in the past as a way to assess the installation of self-managed environments.
These projects are demonstrative of specific stages. They are generally built on existing code OSS bases which the customer may be familiar with, are easy to understand, and have good literature to refer to.