Feedback from Sales, BDR, and Customer Interviews

Suggested Actions ● Buyer persona research ● Sales Training a. GLU content calendar, template, and presentations ● Sales Enablement a. Existing content audit b. Sales process content mapping c. Updated pitch deck (with pivots for different audiences) [Dependent on research] d. EE feature highlight slides e. GitLab product breakdown sheet f. Objection handling ● Initial to move CE to EE a. CE and EE customer survey b. CE to EE sales tear sheet (value, message, trap-setting questions, proof points) c. CE to EE sales collateral d. CE to EE programmatic approaches (i.e. quarterly upgrade email, etc.) ● Site: a. Site audit and content update to most visited pages b. Site directory (internal to support sales and BDRs) c. CI/CD updates to the site d. Update to GitLab homepage and pricing page (to support the re-design) e. Comparison pages (note that this page sees low pageviews) i. GitLab vs. GitLab ii. GitLab v. competitors

Appendix - Recap of Interview Insights

Approach Interview sales and BDR team Same set of questions around landscape, challenges, areas of opportunity and their wishlist Spoke with a couple customers with Phil Missing: ● More customer interviews ● SalesForce data analysis ● Support team interviews

Market Landscape Company realities ● Shrinking or more stringent IT budgets ● New generation of developers who want new tools ● IT-admins need the following answered when evaluating tools: is it secure, does it scale, can it integrate, what is the migration, what about updating systems ● Most admins do the research themselves Git solution ● Big migration to Git based tools ○ Companies have a lot of investment in the old tools but they are pressured to get the new tools in ● Biggest opportunity for GitLab: Migrating off a legacy system (not even on Git). There is a lot of traction with being evaluated ○ Still 40% of the market is still in SVN (Clearcase or subversion) ○ They want to move to work more efficiently and get the latest software for their development team ● Second: Moving CE customers to EE ● Last: Some people coming from GitHub or Bitbucket but this is rare GitLab reality ● Strongly product offering in the market but we don’t have the same brand awareness as Jira and GitHub

Sales Landscape External ● We usually do not talk to the budget owners at first (most often devs are using the tool for a while before procurement gets involved) ● More of a bottom up sale but not the top down ● When we get one team in they do not really want to do a company wide adoption. There is a benefit to keeping the solution within their team. It is currently hard to get introduced to people who will grow the accounts across the company. Internal ● Today, we do not capture the type of people who are trying EE (so we do not know who to target in the future) a. Collect more information in the trial EE process [Name, email address, title, and size of team] ● The company is too focused on the community we need to get to the economic buyer ● Pricing can be confusing ● We usually get CE to move to EE after they have been using CE for a year. a. Certain EE features are considered a nice to have not budget-inducing (we need to research what would get budget and see about building there) ● Difficult to sell the support package bc next day biz support is fine for them

Areas of Opportunity Sales ● Move people from free to paid when the free offering is so good ● Finding the SVN customers and run campaigns against these people (on why you would move to Git) ● GitLab CI and Deploy are big competitive advantages to us and we should feature this more ● Make the site web content more visible (for sales and customers) ● To move people from CE to EE, highlight the new EE only feature as a follow up or nurturing (perhaps a quarterly email campaign for CE to EE [highlight new EE features and the benefits of EE]) BDR ● Update BDR email copy to preemptively answer common questions (this could help remove support questions from their inboxes) ● FAQs for BDRs to help the answer questions more quickly ● BDR collected intel on what customers use https://docs.google. com/document/d/1PNKJA6FDdc_ZFo1b_m9se2ikpsPgSjfpCWdq6xw11uQ/edit

Wishlist External Marketing ● Strong comparison page (e.g. CFS/MS Visual Studio) a. Most people do all the research on their own. This is for people who have not reached out to us at all. It is a self selection process. b. Will also be good for the sales team Shoot a link to the main differences and then have a call to say more ● Outbound prospecting messaging (to people who are not on CE and are on a legacy system) ● Customer stories and case studies (vertical ones would be good) ● Research to answer who are our audiences and why do they buy one thing over another ● 1-pager that makes it easy to understand the offering of GitLab enterprise (nice infographic and something easy to send over) ● Then 1-pagers that are specific to unique features ● Slides for level setting: this is gitlab, what we do, what git is, how we are different than github, and who our customers are and why ● Slides and elevator pitch for a variety of different audience and interest in GitLab a. Elevator pitch for GitLab for different audiences (make sure screen the audience to focus on the write messaging points) ● Product brief as a PDF [See Perforce marketing materials] (Chad’s preference are to make these site landing pages vs. PDF) ● Breakdown sheet of our own products as well as our competitors ● Focus on 3-5 specific EE features and create slides about this ● More on CI/CD bc it is a hot topic and customers need to educated on this topic as well. Internal Sales ● Training for sales team ● Objection handling ● GTM process for bigger features/experiences

Content Ideas ● Series of competitive content [GitLab vs. GitHub, Bitbucket, SVN etc.) ● Series of content related to our integration (GitLab and Jira, Jenkins, etc.) ● More content around moving from SVN (explain advantages of Git, Git solution selection criteria, migration process, etc.) ● Highlight specific EE features ● Securing budget for EE (budgeting cycles, how to evaluate if you should ask for budget, how to make an argument, tools) ● FAQs ● POV and features for CI/CD ● Keeping your workforce on the latest tools (culture/perception of tools in the development community) ● Power/Necessity of choice (i.e. on prem and cloud) ● Migration process/change management within an organization ● Answer IT admins questions: is it secure, does it scale, can it integrate, what is the migration, what about updating systems