GitLab Commit Virtual is here. Register Now for our 24 hour immersive DevOps experience.
Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Product Direction - Conversion

Overview

The Growth:Conversion Team at GitLab focuses on running experiments to increase the rate at which free accounts upgrade to become paying customers. Today, it can be challenging for a free user to understand the features that are available within each tier of GitLab when navigating within the app. We want to make it as easy as possible for teams to collaborate together on the features that are best for them and to explore purchasing on their own terms whether that's starting a trial, speaking with someone at GitLab, or upgrading on their own.

Mission

Team

Product Manager: Sam Awezec | Engineering Manager: Jerome Ng | UX Manager: Jacki Bauer | Product Designer: Kevin Comoli | Fullstack Engineer: Alper Akgun | Fullstack Engineer: Dallas Reedy

Conversion KPI

Supporting performance indicators

Other reports we’re going to be monitoring

In-app "upgrade now" buttons

Started trial after GitLab.com signup

GitLab.com influenced revenue – User

GitLab self-hosted cross-over revenue – User

Problems to solve

Have you experienced an issue with a free user attempting to upgrade or do you have ideas on how we can improve the experience? We'd love to hear from you!

To effectively impact our KPI we'll focus on three core moments

Once a user has signed up for the free product, we have three core moments to convince them to become a customer. By getting them to initially activate and see value in the free product, exposing them to ah-ha moments with paid features, and ensuring they see value in the trial experience.

  1. Initial product activation

    By focusing experiments on activation and increasing the activation rate, we will impact downstream efforts in points 2 and 3. Note, this still needs to be validated once we have user tracking in place. How we'll get there:

    • Qualitative data collection – Understand what jobs GitLab is being hired to complete along with user-specific information so we can assist in making their adoption of GitLab as successful as possible
    • Quantitative experiments – We will use discoveries in the data collected in the bullet above to support onboarding experiments. For example, if we find common themes include an engineer signing up planning to migrate a single project over, then we bring them directly into the project migration process and walk them through it. If someone indicates they plan to bring multiple dev ops teams over, we can start by having them create a group and then projects, walking them through the process
  2. Ah-ha moments with paid features and/or limits

    When users are actively using a tier of the product, they should be aware of when GitLab has the capability to make their job easier. We can do this by displaying premium features at key moments in the use of the product. How we'll get there:

    • Qualitative data collection – Survey existing free users to understand why they haven’t upgraded and ask what feature GitLab needs for them to upgrade. If users list features that we already have, then we know what features have discoverability issues
    • Quantitative experiments – We will run experiments where we increase the discoverability of paid features and the associated value. We will use both the qualitative and quantitative data collected over time to generate future experiment ideas
  3. Trial and upgrade experience/value

    When an account starts a trial, they are making a conscious decision to test out paid features; this represents an opportune time for us to ensure we display the value of the paid features. We need to ensure that trial users experience the value of the paid features and decide to hire GitLab to improve their existing workflows. This same philosophy applies to users who are choosing to upgrade. How we'll get there:

    • Qualitative data collection – Survey users as they start a trial asking what jobs they’re looking to complete within the trial
    • Quantitative experiments – We will focus experiments on how to ensure users are getting value out of trials as well as ensuring they are able to see the value in the paid tiers if they're debating upgrading. Our goal is to make it as easy as possible for the user to decide to hire GitLab

Our approach

We will utilize the ICE framework (impact, confidence, ease) to ensure we're best utilizing our time and resources. The following table displays the top issues we're currently prioritizing.

ICE Score Description Why/Hypothesis
7 Test new upgrade module for feature weights We believe users may not actually see the value in some locked features, we want to set up a testing framework where we can easily test and iterate on these paywall states, this is the first test in this area.
7 Expose Security nav item to a cohort of new signups We believe some users may not be aware that GitLab offers some of our premium features due to the navigation items being hidden from free users. This test will be the first test in a series where we expose the value of the premium features within the free navigation.
8.33 Expose an upgrade or trial option in the top right account dropdown We believe that some users may not know where to go to start a trial or upgrade. This test will help us understand if discoverability is an issue for users when it comes to starting a trial or upgrading.
TBD Walk new signups through group/project creation process We believe that given how central a group/project is to the successful adoption of GitLab, we'd like to test walking new users through this process.
TBD Onboard new users through an onboarding issue board We believe onboarding to a platform as large as GitLab is a task that will likely take more than one session to complete and the order will be dependant on the job GitLab has been hired to complete. This test will allow us to experiment with onboarding users to the issues feature while also giving them a home for their onboarding with issues already created for core actions they should be completing.

See also our full backlog of work.

Maturity

The team is brand new as of August 2019, our goal is to build out an experimentation framework and the backlog of experiment ideas so we can become a well-oiled machine in the months to come.

GitLab Growth project

KPIs & Performance Indicators

Reports & Dashboards (these will be linked once they are created)

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