Facilitate The Opportunity

Facilitate the Opportunity

You have qualified a lead and now you need to turn it into a sale. This phase is called Facilitate the Opportunity. The goal of this phase is to achieve a technical commit followed by an economic commit from the customer. A Commit is a verbal acknowledgement from the buyer that they want to proceed with the deal. In this phase there are 4 high level tasks you need to complete to get a technical and economic commit:

• Discovery
• Scoping
• Technical Evaluation/Technical Commit from a Technical Buyer
• Economic Commit from an Economic Buyer

Again the four tasks above are demonstrable outputs of correctly applying MEDDPPICC and Command of the Message (CoM) within each of the tasks. This also supports your transition from appearing as a common software sales person into a trusted consultant that brings business solutions instead of multiple invoices and a smile.

Step 1: Discovery Questioning

Traditional sales typically bypasses understanding the customer. Traditional sales relies heavily on getting a foot in the door with a customer by overwhelming them with product information in the hopes that a buzz word or some random product feature will catch the customer’s attention and build urgency in the customer. GitLab doesn’t operate that way. GitLab uses Discovery Questioning.

Discovery Questions help to uncover existing customer needs, problems, pain points, goals etc. Regardless of the opportunity being handed off from an SDR or qualified by you, you should always create discovery questions based on the following research process and criteria.

1.1 Research

1.1.1 Determine your Buyer Persona

A buyer persona is a fictional representation of your key buyers. This helps you pre-identify obstacles, objections, initiatives, and metrics that are important to your buyer. This step will give you an edge in understanding your customers better than your competition. There are typically 5 buyer personas you may encounter.

• Technology Leader
• Business Application Leader
• Security Leaders
• CXO Leader
• Financial Leader

1.1.2 Reference Buyer Process Maps

Buyer Process Maps (BPMs) highlight and explain the mental pathways buyers’ travel to make decisions and help to guide selling activity based on where the buyer is in their process. Your goals in this step include differentiation, reduction in resistance, avoid wasting cycles, and facilitating better meetings and creating. See a breakdown of the Buyer Process Map and the common buyer actions that indicate what stages of the buyer process the prospect is in.

1.1.3 Research the buyer

This step includes a number of sub-tasks necessary to obtain additional buyer insights:

1. Reference SFDC to see if the lead is a current customer or prospect. Review their digital body language such as recent activities and past contact.
2. Reference LinkedIn and cross reference the contact’s profile to relevant buyer personas and look for overlaps.
3. Reference the company’s website and absorb basics related to strategic goals, industry, business model, their buyer, etc.

1.1.4 Create discovery questions

Leverage MEDDPPICC to gather the information necessary to qualify the opportunity.

• Discovery Questions are designed to identify existing customer needs, problems, pain points, goals etc.
• MEDDPPICC is a qualification framework that will help you determine if the opportunity is worth your time, effort, and company resources. This is an aspect of Pre-Call Planning. The pre-call planning questions will cause you as the seller to further validate and reference the buyer persona you will engage with. It will help you to more quickly determine what stage the buyer falls in the sales process. The framework will also expose problems and clarify next steps. It will help make you more efficient and focused sales representatives by making it easier to sort the good deals from no deals, and quick deals from long term deals.

1.1.5 Develop a persona-based call plan

This step helps to ensure you gather more pertinent information from the buyer. More specifically, it will help you identify information gaps, set specific objectives, and ultimately increase your buyer’s confidence in you. Use the two job aids below to prepare for your discovery calls.

• Use Sales Discovery and Qualification Questions to create questions that are tailored to the specific buyer persona with whom you’ll be engaging.
• Use the Customer Requirements Document to list all of your questions as part of your discovery call meeting preparation.

1.1.6 Conduct discovery call meetings

Discovery doesn’t take place in just one call. It takes place over a series of meetings. It’s important to take the time to get to understand the customer’s organization on an intimate level in order to propose the best product solution possible. Below are the tasks and assets you’ll need to facilitate successful discovery call meetings.

1. Prepare a meeting agenda to identify how the buyer wants will match what you will cover. This can be sent ahead to the buyer to ensure alignment. For each agenda item, include some questions from the BPM, prepare statements, industry case studies. Research 1-3 items in the Objectives and Obstacles section of the personas. Finalize your meeting objectives in order to show the buyer you are prepared, listening, and empathic. Structure the meeting so that the prospect is relaxed and is comfortable going deep with their problems and needs.
2. Use the Customer Requirements Document during the meeting to capture the feedback from your discovery questioning.
3. Use the Command Plan to track the progress of a deal. It’s an iterative document within Salesforce that gives you and your team macro and micro level visibility into an opportunity. It is designed to align and guide you through the necessary MEDDPPICC process to quickly capture the information necessary to properly qualify an opportunity. Here is a sample Command Plan.
4. Create a customer deck. The customer deck should be specific to the opportunity and utilize the customers branding when possible. Additionally, the customer deck should be created with input from a primary point of contact or an identified champion.

1.2 Creating the customer deck (Phase 1)

The goal of developing and presenting a good pitch is to obtain a verbal commit from the customer. Again, traditional sales representatives tend to overwhelm customers with a long overview of the company and its product features in the hopes that one of the features will resonate with the customer and create a sense of urgency to buy.

Always avoid making a pitch more about us than the customer. At GitLab the approach is more consultative. This is the reason that insight into the customer based on individual research and discovery calls is so important. It gives you an intimate understanding of what the customer’s problems are and their long term goals. Your responsibility in developing and presenting a GitLab sales pitch is to align the customer’s problem to a particular GitLab product based solution. You have worked with the customer to this point to do the heavy lifting and understand what they need. Now as a consultant you are presenting a solid solution to meet their immediate needs but also providing a solution roadmap of their long term goals and needs.

As a rule, a GitLab Sales Pitch deck should be no more than 10-15 slides. You can use the GitLab Customer Template and reduce it to the recommended number of slides.

For Enterprise Strategic Account Leaders, you can also use this GitLab ENT SAE Proposal Template to give you a headstart on a custom proposal for your customer.

It is also recommended that the presentation be more visual rather than text heavy. A GitLab customer deck should contain the following components:

1. Value Drivers
2. How GitLab can Help

1.2.1 Align customer problems with value drivers

As a GitLab sales representative you should know from your discovery calls and research your customers pain points well enough to match them to one if not all of the GitLab Value Drivers. GitLab has the following three value drivers:

• Increase Operational Efficiencies
• Deliver Better Products Faster
• Reduce Security and Compliance Risk

Your job is to call out the specific key pain points and show the customer how their pain aligns with GitLab’s value drivers.

1.2.2 Show how GitLab can help

The next component of the pitch deck is showing how GitLab can help. This will require you to understand the customer’s specific use case. You discovery calls should have provided much of the data to define the problem, but going further you must do the following:

• Research Customer Use Cases
• Align the customer’s pain point to a typical customer use case
• Explain what GitLab does in relation to the associated customer use case

This part of the customer deck will help orient your customer to what GitLab is and how we can help them.

1.2.3 AE/SAE transition to Solution Architect

The data gathered from the discovery calls is analyzed by AE/SAE to make the determination of whether to qualify the lead in terms of GitLab value to their organization. Upon determination of qualifying, the AE/SAE then should engage a Solution Architect to begin the transition to the scoping phase of the sales process.

1. AE/ SAE performs a Gap Analysis of data captured from discovery questioning and is held in the Customer Requirements document. Align customer requirements on the spreadsheet to the specific GitLab product line and denote if GitLab does or does not meet the requirement. This analysis will also provide you with possible DevOps cycle entry points as customer requirements and goals do vary.
2. AE/SAE introduces and engages the Solution Architect in technical conversations and reviews Customer Requirement Document with Solution Architect.
3. AE/SAE updates relevant SFDC fields with new information for formal handoff to the Solution Architect for Scoping. Utilize the Command Plan to track the progress of a deal. It’s an iterative document within Salesforce that gives you and your team macro and micro level visibility into an opportunity.

Step 2: Scoping

Scoping represents an opportunity to discuss customer requirements in more detail. This step is the primary responsibility of a Solution Architect (SA). The SA will do a deep-dive technical requirements review based on the documents provided by the AE/SAE. The SAs main goal in scoping is to understand all the necessary elements that need to be brought into the project scope and identify the pieces that need to be brought together in order to produce a successful outcome for all stakeholders. The tasks necessary to accomplish proper scoping are the following:

1. Review the Customer Requirements document and any associated meeting notes to identify gaps and create more indepth discovery questions related to technical capabilities.
2. Perform high-level technical discovery calls with the customer and work together to review the Customer Requirements Document and gather more context and insight into the customer’s requirements.
3. Analyze the updated requirements against GitLab products to determine a fit assessment. If a fit is determined, initiate a Technical Evaluation.
4. Identify Opportunities to Sell Professional Services. The SAE/ISR can find the general services the PS team offers on the services page or for more details specific SKU offerings, on the full catalog. The SAE/ISR can pull the SA in for help selecting services needed based on customer requirements.

Step 3: Technical Evaluation

Technical evaluation is where the prospective customer evaluates the fit of GitLab to their organization and their specific business outcomes. This may be driven by a Lite POV, a free trial, real time or asynchronous Q&A, a workshop and/or other approach requiring technical guidance from an SA. If Discovery did not include the SA, the AE should follow the triage process to engage an SA for the opportunity, filling out the issue template and providing MEDDPPICC information as well as the known required capabilities in Salesforce. The following are tasks the SA must review and manage during technical evaluation.

1. Update Customer Requirements documents and review Google Docs and Salesforce for running meeting notes with customer environment and technical specifications.
2. Setup a free trial of GitLab based on the following Technical Evaluation Criteria.
3. Create a solution design blueprint from requirements gathering, tech discovery, and customer meta-records.
4. Create a Proof of Value when necessary which focuses on specific customer business outcomes that cannot be achieved through other technical and/or business interactions.
5. Submit a Proof of Value (PoV/PoC) plan to stakeholders for approval.

Hold a strategy meeting: Once the SA has completed the solution design blueprint and/or the Proof of Value, the sales representative will need to hold a strategy meeting with the SA to discuss the highpoints of the solution in order to prepare and present a pitch deck to the customer. If the sales representative does not have deep technical product depth, it will be even more important to debrief the solution blueprint with the SA.

Command of the Message is defined as “being audible ready to define solutions to customers’ problems in a way that differentiates you from your competitors & allows you to charge a premium for your products & services.” This means you must in many ways understand the customers pain points and goals better than they do and speak to real solutions. The solution is presented to the customer through a pitch deck.

At this point, it may also be beneficial to egage the Risk and Field Security Team to provide security assurance support. Prior to making a financial commit, many customers will require security due diligence. The AE, SAE or SA may utilize the Customer Assurance Package for self-service resources or request assistance through the Customer Assurance Activities Procedure.

3.1 When to present the GitLab Demonstration

Should you include the demonstration within the same meeting as the sales pitch? Typically 50% of the time the demonstration is presented in the same meeting with the pitch deck being delivered first.

However, this is an audible-ready moment where the AE/SAE and SA need to meet as a team and discuss if the customer is ready for the demonstration. This should be an agenda item at the regular account management meetings and each team needs to set the criteria of whether to combine a pitch deck meeting with a demonstration on a customer by customer basis. The demonstration should be tailored to the customers specific pain points and business goals. Again, traditional sales representatives tend to overwhelm customers with a long overview of the company and its product features in the hopes that one of the features will resonate with the customer and create a sense of urgency to buy.

• (SAE/AE) Conduct 30-day Trial POV. During this trial the sales representative and technical buyer should have established metrics for success. These metrics will help measure how involved GitLab will be in the trial. The sales representative should have weekly touch points to see how GitLab is performing against Metrics within the POV trial.
• (SAE/AE) Perform Paper Process Discovery during the end trial POV. Obtain information on who needs to sign off from the technical buyer. Document the paper process and determine the economic buyer(s) and work to get access to the economic buyer through the technical champion. The goal is to integrate the economic buyer into the process at this point.

3.1.1 Getting the Technical Commit

A Technical Commit takes place within the Technical Evaluation POV through a series of working sessions where GitLab capabilities are mapped to business and technical requirements within the Customer Requirements Document. When the technical champion has socialized within the organization that GitLab’s capabilities meet or exceed their technical needs in dealing with their business drivers and want to move forward, this is a verbal Technical Commit.

3.1.2 Finding your champions

A Champion is the person within your client’s organization that will sell on your behalf when you’re not there. They will guide you through the decision making process, introduce you to key players and decision makers, and alert you when things go wrong. For medium to high engagement deals, try to obtain a minimum both a technical champion and a business champion. The technical champion can guide you through the Technical Evaluation steps and hopefully help get the Technical Commit. The business champion if they are not one in the same as the technical champion will provide you with insight into the paper process, decision makers, and internal organizations that have influence on whether the opportunity moves forward or not. The criteria for a champion are as follows:

• Someone that has influence and be at least Manager/Director level or above
• Demonstrate that they have sway on the decision making process
• Can remove barriers to the deal
• Will put their value currency on the line to push the initiative

If the person does not meet the above criteria, they should be deemed an advocate. An advocate speaks well on your behalf, socializes your solutions, and helps you understand the landscape within the organization. However,they cannot remove barriers to a deal.

As you facilitate the deal, you must constantly test your points of contact as possible champions or advocates. For this reason, it is best to have multiple advocates and multiple champions to create a point of contact safety net for changing positions and changing initiatives.

Step 4: Getting the commit from the Economic Buyer

To get an economic commitment you have to help a customer organization understand their common pain points and goals and assist them to plan to address those pain points and goals without being overtly involved in the decision making process. It creates urgency by showing the customer that the pain associated with not partnering with GitLab is greater than any pain associated with moving forward (3 Whys: Why GitLab, Why Now, Why Do Anything At All).

When you can do this properly, you will have made a consultative based case that compels the customer to make a decision to buy. This is done on the same side of the table with your identified champions/advocates. Below are the steps that need to be taken to engage and get a commitment from an economic buyer.

4.1 Update the Customer Deck (Phase 2)

To engage the economic buyer you need a customer focused deck that aligns high level business needs with GitLabs Value Drivers. The customer deck should be created with the idea that your champion can present it to the economic buyer. To do this you will need to work side-by-side with your advocates and champions to update the customer deck you created earlier to provide the following components to an economic buyer:

1. Case Study that aligns with the customer
2. Justification
3. Preliminary Pricing Proposal
4. Ask for the Commit/Next Steps

4.1.1 Align Customer Problems with Value Drivers

Align the customer needs to an existing GitLab case study. To locate a good case study go to Customer Reference Documents. You’ll need to build a few slides that distill the main points of the case study to align it to the customer you are pitching.

4.1.2 Business Justification

A justification is defined as the action of showing something to be right or reasonable. You’ll need to work with your champion be clearly show the business justification for choosing GitLab by creating a graphic representation of one or all of the following points:

1. Highlight the efficiencies you’ll get versus your current toolset
2. Return on Investment
3. Metrics of how much more productive you’ll be with GitLab versus the next best alternative

4.1.3 Preliminary Pricing Proposal

Preliminary pricing is usually based on the Proof of Value designed by the Solution Architect. Work with your champion(s) to further align preliminary pricing with the justification and ROI that you should have already created in the customer deck.

Additionally, test your champion during the late stage of the Technical Evaluation process to get an idea of the pricing and budget implications that may present themselves and incorporate that information into the preliminary pricing proposal.

4.1.4 Ask for the Business & Next Steps

1. Set next steps and dates with the customer to move into the Deal Closure phase. Engage with the champions and economic buyer to create a mutually agreed upon action plan to deployment. This is called a Mutual Close Plan and should be documented in the Command Plan.
2. Update the opportunity stage and status in Salesforce from Proposal to Negotiating
3. Update Clari with the latest forecasting projections based on your most recent sales motions.

At this point the opportunity now moves the Deal Closure phase, phase three of the GitLab sales cycle.