Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Product Direction - Growth

Growth Section Overview

The Growth section at GitLab was formed as of August 2019 and we are iterating along the way. We are excited by the unique opportunity to apply proven growth approaches and frameworks to a highly technical and popular open core product. Our goal is to accelerate and maximize GitLab user and revenue growth, and while doing that, to become a leading B2B product growth team and share our learnings internally and externally.

Currently, our Growth section consists of 4 product groups (adoption, activation, conversion, expansion) and 1 product analysis group. Each product group consists of a cross-functional team of Growth Product Managers, Developers, and UX/Designers, with shared analytics, QA and user research functions, and the product analysis group is focused on empowering the product and growth team with analysis and insights.

Growth Section's Principles

In essence, we are a cross-functional team of product managers, engineers, designers and data analysts with a unique focus and approach to help GitLab grow. Since GitLab Growth Section is still relatively new, we'd like to share the principles we strive to operate under, which will act as our team vision, and also help the rest of the company understand the best ways to collaborate with us.

Principle 1: The Growth section focuses on connecting our users with our product value

While most traditional product teams focus on creating value for users via shipping useful product features, the Growth section focuses on connecting users with that value. We do so by:

Principle 2: The Growth section sits in the intersection of Sales, Marketing, Customer success & Product

Growth teams are by nature cross-functional as they interact and collaborate closely with many other functional teams, such as Product, Sales, Marketing, Customer success etc. Much of growth team's work helps to complement and maximize these team's work, and ultimately allow customers to get value from our product.

growth team helps

To provide some examples:

Principle 3: The Growth Section uses a data-driven and systematic approach to drive growth

Growth teams use a highly data & experiment driven approach

graph LR A[ARR] --> B[ARR from New Paying Customers] A --> C[ARR from Existing Paying Customers] B --> D[New customers directly sign up for Paid Plan] D --> E[# of Visitors] D --> F[Conversion Rate] D --> G[Average Contract Value] B --> H[New Trial Customers sign up for Paid Plan ARR] H --> I[# of Trials] H --> J[Conversion Rate] H --> K[Average Contract Value] B --> L[New/Existing Free Users sign up for Paid Plan ARR] L --> M[# of Free User Base] L --> N[Conversion Rate] L --> O[Average Contract Value] C --> P[Existing Paid Customer ARR] C --> R[Existing Customer Churned ARR] C --> Q[Existing Customer Expansion ARR] P --> S[Renewal] Q --> T[Seats] Q --> U[Upgrades] T --> V[# of Seats] T --> W[$ per Seat] U --> X[# of Upgrades] U --> Y[Delta ARR $] R --> Z[Cancel] R --> AA[Downgrade] AA --> AB[# of Downgrades] AA --> AC[Delta ARR $] subgraph Retention S Z end subgraph Expansion T U V W X Y AA AB AC end subgraph Acquisition E F G end subgraph Conversion I J K M N O end

Note that the terms used in growth model are broadly defined, for example, "Conversion Rate" here refers to the percentage of various non-paid customers (new, trial, free) converting to paid customers.

graph LR nsm[North Star Metric]--> grm grm[Growth Model] --> fak fak[Focus Area KPI] -- Data --> ide ide[Ideate] --> pri pri[Prioritize] --> bld bld[Build] --> alz alz[Analyze] --> tst tst[Test] --> ide style nsm fill:#6b4fbb style nsm color:#ffffff style grm fill:#6b4fbb style grm color:#ffffff style fak fill:#fba338 style fak color:#ffffff style ide fill:#fa7035 style ide color:#ffffff style pri fill:#fa7035 style pri color:#ffffff style bld fill:#fa7035 style bld color:#ffffff style alz fill:#fa7035 style alz color:#ffffff style tst fill:#fa7035 style tst color:#ffffff

By following this systematic process, we try to make sure that: 1) We know what matters most; 2) Teams can work independently but their efforts will all contribute to overall growth; 3) We always aim to work on the projects with the highest ROI at any given moment. The ultimate goal is that we are not only uncovering all levers to drive growth, but also tackling them as efficiently as possible.

Principle 4: The Growth Section experiments a lot and has a “Win or Learn” mindset

"Experiments do not fail, hypotheses are proven wrong"

Growth teams view any changes as an “experiment”, and we try our best to measure the impact. With well-structured hypotheses and tests, we can obtain valuable insights that will guide us towards the right direction, even if some of the experiments are not successful in term of driving desired metrics. Refer to section below for a list of experiments

How we launch experiments at GitLab?

Want to launch product experiments too? Check out this slides deck the GitLab growth team put together

Growth Section's Current Focus Area

Starting in FY21 Q4, Growth section will take a more focused approach to work on the highest ROI growth opportunities for the business - and the first focus area we've chosen is the new customer free to paid SaaS conversion rate.

Through analysis of our new customer acquisition funnel, we identified there is reasonable room for improvement in this area. In the past year, Growth section has launched many experiments and improvements in this area, such as new user onboarding issue board experiment, improved check-out experience etc, and we have accumulated insights and learnings to allow us to form high quality hypothesis. One key insight we've learned is that first 90 days is critical to a new customer's onboarding, and if this customer successfully adopts our key features in Create & Verify, invites team members to join, and experiences the GitLab's product value via a trial, the customer's likelihood to convert increases significantly.

Based on this insight, we will have each of the growth groups to focus on one key actions:

This way, we can launch experiments in these 4 areas that can potentially help a new prospect customer see the value of GitLab quickly, and increase their likelihood of conversion. Because there are opportunities to drive 4 actions in some shared new customer flows and touch points, the 4 growth groups will collaborate closely to make sure we have a shared vision for the new customer journey, and won't create a situation that one customer is pulled too many different directions. We will start with our .com product, and migrate applicable learnings and improvements to our self-managed product.

Growth Section's Mid-term Plan

In 2020, Covid-19 has brought uncertainty and disruptions to the market. In tough economic times, all businesses need to focus on efficient growth. GitLab's Growth Section aims to help the company drive growth while improving efficiency in all fronts. Therefore we've aligned our 3-Year Strategy into the the themes below:

Maximize new customers conversion

Theme 1: Improve trial experience to drive new customer growth

In order to grow efficiently, we want to maximize the efficiency of new customer acquisition. For each marketing dollar we spend, we want to bring more dollars back in terms of revenue, and we also need to reduce payback time to generate cash flow that is essential for weathering storms.

As a collaborator to marketing & sales teams, the role the growth team can play here is to aggressively analyze, test and improve the new user flow and in-product experience between,, self-hosted instance, CustomersDot etc., with the goal of converting a prospect who doesn’t know much about GitLab, to a customer who understands the value of GitLab and happily signs up for a paid plan.

In order to achieve this goal, we try to understand what the drivers are leading to new customer conversion and amplify them. For example, we have identified through analysis that the number of users in a team, as well the numbers of stages/features a team tries out, all seem to be correlated with a higher conversion rate to a paid plan.

Again, in order to drive this theme, we will also need to understand the end to end new customer journey, and identify the drivers and barriers via a series of research and analytics projects, such as:

1) Map out GitLab new customers journey and understand any potential experience or data gaps between marketing, sales, growth, product teams

2) Post-purchase survey & Email survey to understand the reasons behind why some customers convert, while others don’t

3) Self-hosted new customer user research

Theme 2: Build out product qualified leads(PQL) programs to become a scalable and effective leads source

The community of free users on GitLab represents an economic moat for our business. However, there is more untapped potential within this community of users. As a free user of GitLab, it can be challenging while using the product to understand if a paid feature exists that could improve their current task. We plan to address this problem via two avenues. First by investing in a unified feature discovery experience in the product where users can learn about paid features and tiers at contextually relevant moments where we will present them with options on how to proceed including things like "upgrade now" "start a trial" and "talk to sales". And second by investing in usage-PQLs where we will look at usage patterns within the product to make recommendations to users to assist in their adoption journey and for qualified users getting them connected with their sales representative.

Current state of PQLs today in the GitLab product

Currently, there are two hand-raise PQL moments in GitLab. The first was introduced at the Cape Town Contribute (called an in-app health check at the time). The way it works is if a free self-managed instance is over a particular user count and has usage ping turned on then we display an option in the top right dropdown to “Get a free instance review” (see screenshot below).

If a user selects this instance review option they are brought to the following form

Between this being implemented during the Cape Town Contribute in 2018 and the first half of 2020 it generated a total of 28 leads, 3 became customers for a total of $93K in incremental annual contract value(IACV). In the fall of 2020, the Growth team increased the rollout of this “instance review” link from previously only appearing if a free instance had 100+ users to displaying if the instance has 5+ users. In the first two months of 2021, the instance review option has generated 26 leads.

There are two core reasons that the cape town PQL moment is underperforming as a PQL lead source.

  1. The “Get a free instance review” is not contextually relevant to the instances’ actual usage of GitLab it simply appears if you had over 100 users (now when you have 5+). There’s no clear value to the user as to why they should select this CTA. It’s not clear how this will make them better at their job or why it will improve their experience within GitLab.
  2. The form they have to submit is daunting and again doesn’t provide any context on who they will be speaking with or what value they will get from that conversation.

The second hand-raise PQL point is on the SaaS in-app billing page. In 2020 the Growth team added an MVC PQL point into the SaaS product, whereby if an admin navigates to the in-app billing page they now along with the option to upgrade have an option to “Contact sales”. If a user selects “Contact sales” they are brought to the marketing website form for contact sales.

When the growth team first implemented the “Contact sales” option on the billings page it was run as an A/B test. By including the option to “contact sales” we increased the overall engagement with a primary CTA (upgrade now or contact sales) by x% compared to the control. This validated that there were some users interested in speaking to sales that previously did not take action on the page. To date, we’re consistently seeing a 1% click-through-rate on viewing the in-app billing page to clicking “Contact sales”.

Where the experience can be improved:

  1. The redirect from a user being in-app to the marketing website is a jarring visual shift and the marketing form leaves a lot of exit points open i.e. the main website header.
  2. When we redirect the user to the marketing site we lose access to the information we already know about them causing the form to be longer. If the form was in the product experience we could remove things like first name, last name, email address reducing the form length and increasing the submission rate.
  3. We can provide more context in the in-app experience on the value of the particular tier and why it’s worthwhile to connect with a salesperson
The future vision for hand-raise PQLs

Hand-raise PQLs, trials, and upgrades scale linearly with increased awareness and value in the paid tiers. The keyword here is awareness, currently, our free users are mostly unaware of the additional value they could get from the paid tiers as it’s on the user to navigate to our marketing site or support docs to see if we have a paid feature and what tier it’s in.

We recently conducted a survey of Bronze and Premium SaaS customers asking them what features they were aware of, what features they had used, what features they are interested in. By looking at the features users indicated they are very or somewhat interested in divided by the users that have indicated they’ve never used these features we can identify areas of the product that users would find valuable but they haven’t yet discovered them (raw data).


By seeing that paid users on these tiers are unaware of these features they’re interested in we know that we need to increase the visibility for free users so they can perceive the value of the paid tiers. We need to bring this contextually relevant information to the users at the right moment through a consistent product experience and provide them with the opportunity to self-select on how they’d like to proceed “Start a trial” “Upgrade now” “Talk to sales”.

The growth team has built one of these feature discovery moments (seen below) which in the past three months has generated 1,700 “upgrade now” clicks and 650 “start a trial” clicks when combined with close rates and ASPs the estimated ARR is $38K from this one feature discovery moment (source).


The vision is to turn this one feature discovery moment into a universal modal that any product team can easily deploy into their area of the product. This allows us to increase awareness of our paid tiers, provide the needed context to the users at the right moments, and reduces the development time for individual teams to implement the experience. This is how we scale from feature discovery moment today to many dozens while still ensuring we’re providing the best possible user experience.

As we scale this feature discovery moment experience throughout the product it’s going to be imperative that the Growth team partner with the data, marketing, and sales teams to monitor all feature discovery moment views, what CTAs (‘start a trial’, ‘upgrade now’, ‘talk to sales’) were selected and their associated close rates and ASPs. This is how we can ensure that we understand what sources are driving the most value for the business while also watching out for underperforming sources that may be able to be removed which ensures we don’t clutter the UI. By looking at the volume of these CTA clicks multiplied by their trialing 90-day close rates and ASPs will allow the product team to report on in-month product-driven revenue.

Over time the growth team will focus on monitoring and improving volume while also working to increase the view to action rate for these feature discovery moment CTAs. How can we make it easier to start a trial from these experiences as close to one-click as possible? How can we reduce the required fields the user needs to fill out to connect with a salesperson? How can we reduce the time to connect with their salesperson, can we embed their assigned sales reps calendar directly within the product? Do we see lower work/close rates for hand-raise PQLs under a certain team size, should those teams only see self-service options? Should larger teams only see hand raise PQL options? By continuing to optimize this experience we can ensure we’re maximizing the value from our free user community while also ensuring they have the best possible product experience.

The future vision for usage based PQLs

The ultimate vision is to establish a smart customer interaction system that will trigger the right interaction based on user ‘s product usage behavior to move users to next stage of lifecycle. We are still in the early stages of these efforts.

What is a usage PQL? When we detect that certain GitLab users take certain actions or show lack of certain actions while using the product, we can use different interactions to guide them to take an action to move forward in the user lifecycle.

To start we are defining three sub-types of usage PQLs, education, in-app recommendations, and sales alerts. We will balance the internal effort (cost) and the potential return to determine the type of information we provide and the method we trigger.


To assist in user adoption and education we will start with usage based product onboarding where if the namespace has not taken important setup actions we'll recommend those actions to them, for example, setup Create, setup Verify, run your first security scan.

As we discover important actions overtime that warrants further investment we will make recommendations to users and teams within the product. For example, if a single user or a small team is running SAST scanning we may recommend to them in-app to start a trial to test out more advanced scanning features.

For high-value actions taken by larger accounts, for example, a large company with many users is actively running SAST scanning we should alert their assigned sales representative about this usage and the more advanced features available in Ultimate.

The first usage-PQL email series has launched to support free user onboarding whereby we're sending users content recommending the next feature and/or stage they should adopt. The product team has also started brainstorming different potential usage PQLS across the three types in this issue. This area will be a continued focus for Growth working across departments with Marketing, Sales, and Customer Success as more teams implement usage-based outreach.

Drive feature adoption and usage

Theme 3: Onboard new users/customers effectively to support their use case

Registration Flow Vision

A user's first interaction with GitLab is often through the creation of their account. This is our chance to make a good first impression and get them down the right path for them to have longer-term success. We have users of various types that have different goals depending on their role, if they're a solo user vs. a team, if they are setting up the account for a team vs. joining an existng one, and where they are in their adoption of DevOps. We currently have a one-size fits all approach though, and it assumes the user wants to set up a team along with a new group and project.

Our vision is to direct users down the right path for them based on a few pieces of data that we'll collect in the registration flow. Those key data points include:

The flows will end up branching down a few distinct paths:

graph LR A[Sign up] -->|Email Verification| B{Setting up vs. joining an existing team/project} B -->|Setting Up| C{Company or Personal? JTBD? Role?} B -->|Joining Existing Team| D[JTBD? Role?] C -->|Company| E[Group and project creation, skip not allowed] C -->|Personal| F{Group and project creation, skip allowed} C -->|JTBD = import from somewhere| G[Direct to import flow] E --> H[Trial, can be skipped] H --> I[Project Overview Page] F -->|Skipped| J[Homepage] F -->|Not Skipped| I G -->L[Create Group] L -->M[Import project] D -->N[Homepage] N -->O[Guide to help find team]

Over time we'll continue to experiment with the steps and options in the flow, with the goal being to get users through it as quickly as possible while balancing that with getting them started off correctly in order for them to be successful. Some additional data points we want to utilize to customize the flow and onboarding include:

In addition to flow changes, we also want to improve the overall look and feel of the flow and the ways that we collect the data we need to keep it engaging and a delightful first impression for new users.

Onboarding vision

Currently, we have the "Learn GitLab" project which is a dedicated onboarding project with issues assigned to the user that signs up, the main challenge with this experience is users have to understand our group > project architecture to navigate between the learn GitLab project and their own project as well as remembering to navigate to this specific project for their remaining onboarding tasks. We've actively running an experiment that we hope we're hoping to wrap up in 14.2 where we provide users with Learn GitLab in the left nav and dynamically update their percent completed based on the actions the namespace has completed (screenshot below). Our next experiment here will be to determine if it's better to send users to onboarding issues or directly to the action in-app, we believe the latter is a better long-term user experience but we want to validate that through a test.

Our longer term vision is this becomes more of a "home page" for the project where we display onboarding tasks along with other elements we know increase adoption/conversion rate, for example, an invite colleague, setup integrations modules along with helpful users specific modules like recent comments, MRs and/or To-dos. Over time we hope to become more intelligent and recommend PQL actions like "talk to sales" for users/namespace that reach specific thresholds. Example potential future component within the page are shown below:

The part of this vision that has yet to be fully defined is when a user selects an action how can we best walk them through that task. In previous user testing, we've found our users are not generally interested in multi-step tooltip tutorials they have to walk through in order to complete a task, they generally gloss over the steps eventually just closing them out. The other issue with multi-step tooltip tutorials is they're not easily scalable to multiple stages and have a tendency to break as the user experience is updated over time. What we'd like to explore is develop a universal experience that all stages can apply to assist in their onboarding. An example of this in the product today is a fly-out that the Verify team is testing, in the future we could potentially with some sort of visual element so it's easily recognizable to open/close and eventually dismiss this type of fly-out in the product. If you have feedback on our vision in this area please don't hesitate to reach out as we'd love to collaborate, you can find us on on slack at #s_growth or by creating an issue and mentioning @gitlab-org/growth/product-managers.

Personalized stage onboarding

Because GitLab is a complete DevOps platform, prospect users and customers start to use the product for different reasons. Based on our marketing team's research, there are several use cases which are key to our GTM strategy and often are where we land in an account or are significant expand motions.

  1. Usecase: Version Control and Collaboration (all project intellectual property - code, design, and more)
  2. Usecase: Continuous Integration (how teams automate and streamline build and test to improve quality and velocity)
  3. Usecase: DevSecOps (how teams shift security left and make it relevant throughout the delivery lifecycle)
  4. Usecase: DevOps Platform (making adoption of DevOps practices easier and streamlined, eliminating waste)

The data analysis also shows that new namespaces adopts different GitLab stages at different speed, which highglights the opportunity to provide personalized onboarding experience to our new users/customers, with potential different focus on Create, Verify, Secure adoptions.

Switcher experience

The other factor that impacts GitLab's new user experience significantly is whether they come from an incumbent or start from a clean slate. From user interviews, we understand that if a prospect comes from an existing solution, they often need to overcome more hurdles and their "onboarding" experience is quite different from others. They sometimes need to maintain 2 solutions at the same time, have to reconfigure many integrations, and encounter errors or issues that are not very well covered in typical "new user onboarding". This is a potential direction the growth team can explore.

User onboarding vs. Team onboarding

GitLab is most valuable when used as a team collaboration tool, therefore not only each individual new user needs to learn how to use GitLab and find value, for teams we need to help the entire group to get settled and get to the team "aha moments" too. This will involve identifying a team use case early on, make the team invitation flow smooth and intuitive, and showcase the features most valuable to teams.

Paid customer onboarding

For paid customers who subscribe to premium or ultimate, we also need to make sure they are guided properly to use the relevant paid features and reach the ideal seat utilization rate early on. Our Customer Success team has a strong focus in this area, but growth can supplement that effort by building onboarding and nudge into the product flows.

Driving early Stage Adoption (SpO)

We’ve built a comprehensive DevOps Platform, and users are more succesfull and more likely to convert to paying customers with each additional stage that they use. If we can increase organization stage usage (SpO) in the first 30 days, we’ll see a large positive impact to free to paid conversion and revenue.

Theme 4: Drive more stage adoption post onboarding

Post initial onboarding, we still want to guide customers to use multiple features and stages. One hypothesis is that if a customer uses multiple stages and features of GitLab, they are more likely to get value from a single DevOps platform, thus they are more likely to become a long term customer.

Therefore, one of the Growth Section's focus areas will be on helping GitLab customers adopt more stages, and we'll observe if that leads to better retention to confirm the causation. ALong with this, we will need to conduct both quantitative data analysis and qualitative research to describe the baseline and understand the drivers and barriers behind stage adoption.

graph LR Create --> Plan Verify --> Secure Create --> Manage Create --> Verify Verify --> Release Verify --> Package Verify --> Configure Release --> Monitor Release --> Protect

Theme 5: Improve customer retention to build a solid foundation for growth

Existing customer retention is our life blood, especially in tough marco-economic environments, it is critical to serve our current customers well and minimize churn. By staying laser focused on retention, we can build a strong foundation to weather the storm and drive growth sustainability, and can be right there when customers are ready to expand again.

To improve retention, the Growth Section has identified and will be working on the areas such as:

1) Continue to make the customer purchasing flows such as renewal and billing process robust, efficient, transparent and smooth, as these are critical customer moments.
We have done projects such as:

And we are also working on quarterly co-term billing for self-hosted customers, continuous improvement of CustomersDot user experience, as well as supporting critical pricing and packaging related projects.

To make sure what we do will benefit customer, we have a weekly cross-functional sync with sales, biz ops, support, finance and closely monitor Customer Success Score (billing related) as our OKR.

2) Deep dive into the customer behavior and identify leading indicators for churn. This will include projects such as:

Drive growth with insights from data and research

Theme 6: Build out infrastructures and processes to unlock data-driven growth

Data is key to a growth team’s success. Growth team uses data & analytics daily to: define success metrics, build growth models, identify opportunities, and measure progress. So part of our focus for FY21 will be working closely with GitLab data analytics team to build out that foundation, which include:

1) Provide knowledge & documentation of currently available data sources to understand customer behaviors . Also, establish a framework and best practices to enable consistent and compliant data collection

2) Build out a Product usage metrics framework to evaluate how customers engage with certain features. For example, we successfully finished SMAU data collection and dashbaording project for all GitLab product stages in Q1, and will move on to a similar North Star Metric project for all GitLab product features in Q2.

3) Build out Customer journey metrics framework to understand how customers flow the GitLab through funnel, including end to end cross-functional reporting spanning marketing, sales and growth.

Along the way, we also aim to share our learnings and insights with the broader GitLab team and community, as we firmly believe growth is a whole company mission, and that success ultimately comes from constant learning & iteration & testing & sharing, as well as breaking the silos of functional teams to drive towards the same goal.

Growth Insights Knowledge Base


Below is a list of the dashboards we build and use daily. Many of these dashboards are used not only by us, but also by executives, broader product team, sales and customer success teams.

Area Dashboard/Report Description Date
Overall Product Product Adoption Dashboard Product KPIs FY22 Q1
Overall Growth New namespace conversion dashboard Leading indicators of how new namespaces convert to paid customers FY21 Q4
Overall Product SMAU dashboard Stage Monthly Active User trend for both .com and self managed FY21
Overall Product Stage Retention and Adoption Dashboard How popular are the stages among GitLab customers, and how well are they retaining customers FY21
Activation New Customer Acquisition Dashboard Trend of acquisition of new customers FY21
Conversion New group namespace trial to paid conversion rate How are new new groups that start trials converting to becoming paid customers FY21
Adoption Renewal Dashboard Trend on renewal and cancellation of susbscriptions FY21
Adoption Retention Dashboard Retention metrics and trend FY21
Adoption What's New Dashboard Information on engagement with What's New posts FY21
Expansion New groups with at least 2 members in their first seven days At what rate do new groups have at least 2 members and how can we increase the team adoption rate FY21
Expansion SPAN Deep Dive Report How to understand SPAN (Stage Per Average Namespace) and ideas to improve SPAN FY21
Overall Product EoA Monitoring Metrics - Bronze Impact on Group Namespaces How did the removal of the Bronze plan impact free-to-paid conversion as well as group namespace stage adoption FY22 Q1
Overall Product Stages per Organization What are the most common stage adoption paths for new group namespaces? How does the adoption of certain stages correlate with long-term engagement, expansion, and conversion? FY22
Expansion Invite Acceptance Analysis Analysis of the time from namespace creation to creating invites, users accepting invites, and adopting stages. FY22
Adoption Cross-Stage Adoption Dashboard Analyze how organizations engage with different combinations of stages. FY22
Adoption Retention (non-subscription based) of Users and Namespaces What does namespace and user retention look like based on event actions instead of logins? FY22
Adoption SSO Deep Dive How do users signing up with SSO differ with respect to engagement and purchase? FY22
Adoption Trial Adoption by Day What does the distribution of trial adoption look like over the first week as namespace? FY22
Retention SpO Retention What usage patterns at the end of a paid plan inform the likelihood of plan retention? FY 22
Adoption Golden Journey Pathways How effectively are namespaces and instances funneling from one stage to another? FY 22 Q3


Link Type Description Date
Why prospects come to GitLab Survey It shows top reasons propsects come to GitLab and % of win/loss by reasons FY21 Q1
Feature Discovery Survey Survey Among our paid customers, which features are they aware, interested in and used? FY21 Q1
Increase Stages per Organization Analysis How many stages does an average GitLab customer adopt and how to drive adoption FY21 Q1
What drives free to paid adoption Analysis What are the drivers that can lead to higher free to paid conversion rate FY20 Q4
SaaS products new user onboarding research Research How best-in-class SaaS products are designing their registration flow and continious onboarding experience FY21 Q1
Why are prospects coming to GitLab (utilizing Command Plan info) Analysis What is the distribution of primary use cases across various sales segment and closed/won vs. closed/lost. 2021-03-01
Which What's New items are users most intersted in? Dashboard Dashboard that shows engagement with What's New items ongoing
Why are Saas users cancelling? Dashboard Dashboard that shows the self-reported reasons and verbatims that Saas customers are cancelling in CustomersDot ongoing
Free to paid conversion rates by integration usage Dashboard See the correlation between integration usage and conversion from free to paid ongoing
Stage Adoption Patterns: SCM <> Code Review <> CI Analysis How do organizations go from using SCM to Verify, and is Code Review used between or after these stages? FY22 Q1
Secure Free-to-Paid Funnel and Feature Adoption Analysis Analysis Which Secure features are the most adopted during trials and which features have the highest correlation with Ultimate plan paid conversion? FY22 Q2
Paid SpO Trends among Retained and Churned Namespaces Analysis What stage adoption trends are present when looking at churning namespaces vs.retained namespaces? FY22

Growth Experiments Knowledge Base

Here is a list of our currently running and concluded experiments.

Growth Product Managers reguarily update this knowledge base with upcoming, live and concluded experiments. Please lable product area for upcoming and live experiments for planning purpose.

Growth Experiments Knowledge Base - Upcoming Experiments

Experiment Name Group Estimated Go-live Timeframe Product Area
Introduce users to verify via code quality template walkthrough Activation scheduled for 14.0 TBD
Create empty state for the security MR widget to drive secure adoption Adoption scheduled for 14.5 MR page
Improve the information presented after creating a new project Adoption scheduled for 14.6 Project page
Drive Create Usage on Empty Projects via the MR Page Empty State Adoption scheduled for 14.6 MR empty state page
Improve the layout and appearance of the Registration Flow Adoption scheduled for 14.7 Registration flow
Trial form: display known information Conversion Scheduled for 14.3 TBD
Add reassurance (social validation) to the SaaS trial signup page Conversion scheduled for 14.3 TBD
Follow Up Experiment- iterate on known fields within trial signup form Conversion scheduled for 14.3 TBD
Remind user of trial status when 14 & 3 days remain Conversion scheduled for 14.3 TBD
For single user namespaces add invite to left nav Conversion Q3 TBD
Move Billing to top-level navigation item Conversion 14.6 Navigation
Add high-conversion trial feature tasks to Learn GitLab Conversion 14.7 Continuous Onboarding
[Promote pricing tier on /billing page] ( Conversion Q4 SaaS Purchase flow
With no additional users add "invite" to nav for all free namespaces Expansion Q4 Navigation

Growth Experiments Knowledge Base - Active Experiments

Experiment Name Group Go-live Date Estimated Conclusion Date Product Area
Display invite modal post signup and group/project creation utilizing peak end rules Expansion 2021-11-22 Active Registration flow
Highlight paid feature during active trial Conversion 2021-05-17 TBD TBD
In Product Email Campaigns Activation Active TBD TBD
Template zero state page VS Simple template Activation Active TBD TBD
Simplify Group Creation in Registration Flow Adoption 2021-11-30   Registration flow
Add option to enable SAST at project creation to the new project flow SAST Adoption 2021-10-26 2021-11-30 Project creation
Split Registration Flow based on if the user is joining an existing team or setting up a new one Adoption 2021-11-03 2021-12-15 Registration flow
Change invite email to be from inviter Expansion Active Invitation acceptance flow  

Growth Experiments Knowledge Base - Concluded Experiments

Experiment Name Group Experiment Result Go-live and Conclusion Date
Change invite email to be from inviter Expansion Invalidated 2021-11-01 - 2021-11-23  
Member Area of Focus Expansion Validated 2021-08-18 - 2021-09-27
SaaS continuous onboarding Conversion Inconclusive 2021-05-15 - 2021-08-10
SaaS trial onboarding Conversion Validated 2021-02-10 - 2021-07-21
Invited user email - permission info vs activity Expansion Inconclusive 2021-06-28 - 2021-08-16
increase invite acceptance by removing exit CTAs Expansion Invalidated 2021-05-17 - 2021-06-08
SaaS trial active trial status countdown Conversion    
Optional trial during free SaaS signup Conversion Concluded  
Empty versatile template for CI Activation Concluded  
Empty versatile template for CI for <90 days> Activation Concluded  
Update .com paid sign up flow Activation Concluded  
Pricing page tier presentation test Activation Concluded  
Clarify Auto renew toggle vs. Cancel Adoption Concluded  
Invited user email iteration 2 Expansion Validated 2021-03-02 - 2021-03-24
Add optional ‘invite colleagues’ to the registration flow (initial required onboarding steps) Expansion Validated 2021-03-08 - 2021-05-20
Add invite option to comment area to drive more invite Expansion Invalidated 2021-03-22 - 20201-07-07
MVC of What's New Adoption Concluded  
Make Upload Options Accessible from Project Details Page Adoption Concluded  
Add CTA for Project Integrations to Drive Deeper Adoption Adoption Concluded  
Display security navigation to upsell new .com signups Conversion Concluded  
New user onboarding flow Conversion Concluded  
Required group trials Conversion Concluded  
.com Trial flow improvements Conversion Concluded  
MR with no pipeline Prompt Expansion Concluded  
Buy CI minutes option on top right dropdown Expansion Concluded  
Remove known fields from trial sign up form Conversion Concluded  
Add Ease Score and Interview Recruitment Track to Onboarding Email Series Activation Concluded  
Add "New Repo" CTA Adoption Concluded  
Check "Initialize repository with a README" by default Adoption Concluded  
Collect JTBD info in Registration Flow Adoption Concluded  
Default Namespaces that are Setup for Company to Trial Flow by Auto Checking the Toggle Adoption Concluded 2021-07-28 - 2021-11-10
Provide guidance and a template in the default README Adoption Concluded 2021-08-06 - 2021-11-19

We rollout experiments using feature flags. These are tracked through experiment rollout issues.

Growth Coffee & Learn Sessions

Growth requires constant learning, and many compaines face similar challenges or go through similar journeys. At GitLab, we believe hearing from growth experts and practioners with diverse background is the best way to learn, and we want to share that with the community as much as possible. Therefore, we started a growth Coffee & Learn series since 2020. Below is a list of exerperts we invited to share their wisdom with us. We appreciate their time and insights, note that some videos/notes are viewable by internal team only.

Expert Background Topic Video Notes
Chris More VP Growth @ Fusebit & Former Head of Growt@ Mozilla AMA on Open source & growth NA AMA Notes
Holly Chen Growth advisor, former head of global marketing @ Slack Growth Loop & Journey of Slack Video Summary
Linsha Chen Head of Growth Data Science, Airbnb How Airbnb does experimentation Video AMA Notes
Jike Chong Author, How to lead in Data Science, former data science exectutive@ Linkedin, Acorns How to Lead in Data Science Video AMA Notes
Anuj Adhiya Author, Growthhacking for Dummies, VP Growth High Performing Growth Teams Video AMA Notes
Robert Neal Director of experimentation @ LaunchDarkly Experimentation system AMA Video AMA Notes
Carl Gold Former Chief Data Scientist, Zuora Fighting Churn with data Video AMA Notes

Growth Section Areas of Focus

1. Apps & Services we focus on:

2. Growth Group Directions

3. What's next: Growth Group Issue Boards

Growth Definitions

It can be confusing to know what we're all talking about when we use different names for the same things. This is where we can clarify and discuss common terms to make communication easier.

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license