Product Direction - Acquisition

概要

The Acquisition Team at GitLab focuses on running experiments to increase the paid adoption of our platform at the point of signup, we strive to promote the value of GitLab and accelerate site visitors transition to happy valued users of our product. Acquisition sits at the beginning of the journey for individual users and organizations as they get their first introduction to the value proposition of GitLab. Our goal is to ensure that users understand the unique value that GitLab provides and thereby ensure that prospects seamlessly transition into healthy, valued users of GitLab. We will gain a deep understanding of the value that our users realize from the different Stages of GitLab, and ensure that value is susinctly communicated to our site visitors in order to efficently transition them from prospects to active, valued users.

Acquisition Team

Acquisition Team Mission

To promote the value of GitLab and accelerate site visitors transition to happy valued users of our product.

Acquisition KPI

Direct signup ARR growth rate
Definition: (Direct signup ARR in the current period - direct signup revenue in the prior period)/direct signup revenue in the prior period
The Analysis can be found in the Product KPIs Dashboard in Periscope
Calculation:
- For SaaS, Direct signup ARR includes all namespaces that start a subscription for the first time, during the first 24 hours after the namespace creation.
- For Self-Managed, we link all subscriptions to their Salesforce accounts and leads. We include in Direct Signup ARR all subscriptions which have a lead or an account created up to 24 hours before the subscription start date.

Supporting performance indicators:

Time to sign up
- Definition: Time of account signup completion - Time of first visit
Percent of paid conversion
- Definition: Total number of unique site visitors / Total number of paid signups
Percent of conversion
- Definition: Total number of unique site visitors / Total number of signups
Free to paid conversion
- Definition: Free to paid conversion rate (free user upgrades / free user signups in period)
Time to upgrade
- Time of account signup completion - Time of upgrade to paid package

Problems to solve

Do you have issues… We’d love to hear about them, how can we help GitLab contributors find that ah-Ha! Moment.

Here are few problems we are trying to solve:

Clarity - Whose problems do you solve?
- Your product does A LOT, the feature set is expansive, but I can't tell if it will work for me.
Call to Action - I want to signup! What is the best way to do that?
- I can't tell which offering of GitLab I should signup for?
- What package should I signup for?
Usability - Signing up for a paid package is a cumbersome process…
- As a dev-ops lead, how do I buy this product for my team?
- How do I signup for a paid package from my self hosted instance?

Our approach

Acquisiton runs a standard growth process. We gather feedback, analyze the information, ideate then create experiments and test. As you can imagine the amount of ideas we can come up with is enormous so we use the ICE framework (impact, confidence, effort) to ensure we are focusing on the experiments that will provide the most value. The team is dedicated to improving GitLab’s ability to convert visitors from about.gitlab.com into healthy, valued users of the product. Given GitLab’s commitment to iteration and the Growth Groups test and learn strategy, the Acquisition Team will break down each incremental improvement in two distinct and important ways:

Each item in our roadmap will be broken into an MVC
Each item in our roadmap will be rolled out incrementally and measured against a control

Though this framework is not new to GitLab, it is especially important to note for this roadmap. Many of the items listed below have the potential to create negative downstream impacts to revenue and potentially a users experience with our product. While we obviously seek to avoid those cases, we believe that we should take controlled risks to quickly learn from our users behavior rather than increasing the scope of these tests to avoid all negative edge cases. That said, we will document any possible negative after effects resulting from each test, as well as a plan to monitor and potentially mitigate those negative effects. Moreover, we will call out an appropriate test rollout plan given the risk associated with running each test. That said, our prioritization will take those potential negative effects into account, and will reflect what we believe to be the highest potential impact to our growth KPI as possible given an ICE score. Happy learning!

🚀 Current Priorities

ICE Score	Focus	Why?
7.0	SAAS Paid Sign Up Experience	As a user, when I sign up for a paid package, the process is convoluted, complex and confusing. I don't understand why I have to create 2 accounts in order to signup and pay. I would rather try to figure out how to use the product for free rather than invest my time trying to figure out how to pay.
6.7	SAAS Trial Sign Up Experience	As a user, when I sign up for a trial, the process is convoluted, complex and confusing. I don't understand why I have to create 2 accounts in order to sign up. I would rather try to figure out how to use the product for free rather than invest my time trying to figure out how to pay.
6.0	Self-Hosted Paid Sign Up Experience	As a user, when I sign up for a paid package, the process is convoluted, complex and confusing. I don't understand why I have to create 2 accounts in order to sign up. I would rather try to figure out how to use the product for free rather than invest my time trying to figure out how to pay.

Maturity

The growth team at GitLab is new and we are iterating along the way. As of August 2019 we have just formed the expansion group and are planning to become a more mature, organized and well oiled machine by January 2020.

Helpful Links

GitLab Growth project

KPIs & Performance Indicators

Reports & Dashboards