GitLab wants prospects to enjoy a successful Proof of Concept (also known as Proof of Value) with GitLab Enterprise Edition. A POC is a collaboration between GitLab and the prospective customer for evaluating GitLab Enterprise Edition. As a best practice, GitLab product evaluations should remain separate from GitLab high availability architecture and implementation evaluations. Due to cost and time intensity, a POC should not be the default course of action for most GitLab buyers. POC's should focus on specific customer business outcomes that cannot be achieved through other technical and/or business interactions.
POC's are commonly entered into once an NDA is signed, budget for the project is in place, any competition has been identified and success criteria have been documented.
The target duration for a POC is between 1 and 8 weeks depending on complexity and style of engagement. A GitLab Customer Success collaborative project is the default method for POC management. The project template is only accessible by GitLab team members, but once a collaborative project is created, the customer will be granted access to that project. When utilizing a collaborative project, follow the instructions in README.md closely in order to properly copy and configure the entire project. If a prospect has an internal process to follow or cannot use GitLab.com to manage the POC, a Guided POC document or a simplified Lite POC document may be used.
GitLab Solutions Architects should consider a limit of 3 concurrent Guided or Paid POC's as a best practice in order to provide excellent customer service and to enable a target of achieving 24 hour or less response times to inquiries during any POC. If more than 3 concurrent Guided or Paid POC's are required, the SA should assess their ability to support the additional requirements and/or discuss viability with their manager as well as other SA's in their region.
In order to track a POC correctly in Salesforce, the Strategic Account Leader should position the opportunity as Stage 3. The Solutions Architect will create the POC object within SFDC when the prospect or customer has indicated interest in moving forward with a guided or lite POC.
To track a POC, click the Proof of Concepts tab from the top menu bar in Salesforce. Create a new POC using the New button. Alternately, the Solutions Architect may select the relevant Opportunity, scroll down to the related list labeled Proof of Concepts and click on the "New Proof of Concept" button. This will automatically associate the POC with that Opportunity while all other fields need to be manually completed.
Complete the following fields at minimum:
Once the POC begins, the Solutions Architect should change the Status field from New to In Progress. When the POC 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.
Solutions Architects are the owners of the POC, 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 POC. If technical problems arise which are unexpected, after evaluation by the SA and verification with the prospect, the SA may engage support via the email@example.com email address. This should only be used for technical abnormalities, not for integration or implementation assistance.
Many prospects are tempted to include implementation of GitLab high availability as part of a POC. In this case, the implementation components should comprise a separate POC entirely, separating GitLab functionality evaluations from implementation, load and performance components.
Below is best practice guidance for conducting each type of POC. These processes share a similar goal of meeting identified business outcomes for the customer, but they vary based on engagement style, POC duration, location and intensity. The following applies to all POC's:
POC-related calls may be recorded with customer consent. Recordings may be stored in Chrous, 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 approaches to a POC. The POC type chosen should reflect the wishes and best fit for the client. POC types include:
Best practices specific to each type of POC follows.
The On-site POC is typically the shortest and most intense POC. It is critical that before this type of POC begins:
The SA will typically join the client at their chosen location and work directly with the team there to quickly identify the value proposition of GitLab within their environment. The SA will dedicate themselves to the client for 3 to 4 days a week for this POC, collaborating on value drivers, assisting in solving problems, and enabling customer POC owners on required knowledge to obtain identified POC outcomes.
The Guided POC is the most commonly utilized type of POC for Enterprise accounts. These will commonly have a 30 to 60 day duration. These POC's are marked by regular touch points and consistent interaction over time without requiring full time dedication to the GitLab evaluation on behalf of of the customer. It is common to have kickoff meetings, technical support calls, weekly retrospective calls and POC conclusion calls when running a Guided POC. These meetings may be represented by the following suggestions:
GitLab Attendees: Strategic Account Leader, Solutions Architect, Technical Account Manager
The Paid POC is less common than other types of POC's. These will commonly have duration greater than 60 days, and the customer will pay for usage of GitLab for the duration of the POC. Before this type of POC can begin, it requires a GitLab prorated licensing purchase to be completed. These POC'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 POC 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, weekly retrospective calls and POC conclusion calls similar to those identified for a Guided POC.
When a prospect has an internal POC process to follow, or when time is of the essence, a Lite POC is chosen.
For a Lite POC, the SA may utilize the Lite POC document (only accessible to GitLab team-members), which validates POC dates, success criteria and assumptions of both GitLab and the prospect.
In the case of a "Lite" POC, 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.
The template provides a simplified approach to the POC process, but the document requires customization for each POC to be executed.
To use the template, begin by making a copy of the master document for each POC.
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 success criteria, trial location and the client pilot team(s). 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 POC via calendar invites prior to distributing the GitLab Enterprise Edition license for the POC.
Commercial Sales POC's are commonly executed as a variety of the Lite POC, though they may not utilize the Lite POC document. Common customer interactions for Commercial POC's are identified below.
As an alternative (or in addition) to using a collaborative GitLab project, a document is available which helps outline the details of a POC. In the document (only accessible to GitLab team members), provides the framework for a successful POC by addressing current state issues, persistent challenges, business problems, desired state and outcomes.
This document suggests and verifies specific success criteria for any POC, as well as outlining a mutual commitment between GitLab and the identified prospect parties. It also specifies the limited timeframe in which the POC will occur.
The template provides a standardized approach to the POC process, but the document requires customization for each and every POC to be executed.
To use the template, begin by making a copy of the master document for each POC.
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 success criteria, trial location, and the client pilot team(s).
After all the highlighted sections have been completely filled in, collaboratively complete the Date and Owner column fields within the Project Plan and Roles and Responsibilities sections.
Finally, ensure both GitLab and the prospect have a copy of the document. Schedule all meetings associated to the POC via calendar invites prior to distributing the GitLab Enterprise Edition license for the POC.