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

Product Vision - Growth

On this page


The Growth stage is responsible for scaling GitLab's business value. To accomplish this, Growth analyzes the entire customer journey from acquisition of a customer to the flow across multiple GitLab features - and even reactivation of lost users. Several groups help with this mission:

Growth is commonly asking and finding solutions for these types of questions:

Why Invest in a Growth Section in 2019?

We believe we have found product-market fit by providing a single application for the entire DevOps lifecycle, highlighting the value created when teams don’t have to spend time integrating disparate tools. Now that product-market fit has been achieved, we must do a better job of connecting our value to our customers. Therefore, a Growth focus is required. Additionally, we are beginning to put more strategic focus on the growth of, which is a different user signup and activation process than self-managed instances, which typically involves direct sales.

Acquisition, Conversion, Expansion , and Retention groups

While the Growth function is becoming more common in late stage, well funded software companies, it is still a relatively nascent discipline. At GitLab, we seek to derive best practices from the industry and adapting them to work with our culture. Here are a few articles we’ve found helpful as we are formulating a Growth strategy and vision:

The Acquisition, Conversion, Expansion and Retention groups are GitLab's approach to a dedicated, experiment-driven Growth team. These groups are expected to always start with a hypothesis. The hypothesis should be fully defined prior to execution in order to safeguard from "bad science," namely data that may correlate but not have any causal relationship. After a hypothesis has been defined, Growth relies on two primary constructs to make decisions: analysis of data, or what people do in the application, and qualitative research, in essence the “why” behind the data.

Growth should focus on metrics that are important at the company level, while also considering company strategy. Each group will own a north star KPI which are linked here.

Acquisition, Conversion, Expansion and Retention will consist of a product manager, engineering manager, some full-stack engineers, a (shared) data analyst, and a (shared) Product Designer. Each group member will have a functional reporting structure, in order to report to a leader that understands their job function.

Weekly Growth meeting

The Growth Product Management Director should run a weekly growth meeting to review, prioritize, and plan experiments. The meeting should take place on Tuesdays for 50 min and should cover the following agenda. 15 min: metrics review 10 min: last week’s testing activity review (update on live experiments) 15 min: lessons learned 15 min: select this week’s tests 5 min: check on idea backlog

To prepare for the meeting, the Growth PM's and the Growth Director should check in on experiments to identify which can be concluded, and to collect data for review.

Growth ideation and prioritization

Anyone is welcome to submit ideas offline to idea backlog as issues (name, description, hypothesis, metrics to measure, and ICE score).

To prioritize, the growth groups will use the ICE framework, which consists of the following elements, scored on a scale of 1-10:

Working across stages

The hypotheses explored by Growth will span across groups and stages. How do other groups interact with Growth?

Growth does not own areas of the product, but finds ways to help users discover and unlock value throughout the GitLab application. They will do a combination of shipping low-hanging fruit themselves, but will partner with other stages on larger initiatives that need specialized knowledge or ongoing focus.

It is the responsibility of other stages to maintain and expand core value in their respective product areas; it's Growth's mission to streamline delivery of that value to users. For example:

Presenting the relationship in a RACI matrix:

Task Growth Product/Engineering Data Team Product Leadership Stage Product/Engineering
Hypothesis Generation R I A C
Experiment Design R C A I
Experiment Implementation R I A C
Contribution Review A     R
Experiment Ramp R C A I
Post-Experiment Analysis C R I I
Post-Experiment Decision R C C C
Maintenance C     R

Fulfillment group

Responsible for licensing & billing workflows, which have a huge impact on renewal rates, upgrade rates, and customer satisfaction, and represent important levers for the Growth team.

Please see the Fulfillment direction page for more information about Fulfillment's mission, vision, and priorities.

Telemetry group

Responsible for product usage data, including proper instrumentation, working with BizOps and Engineering to ensure product usage data is stored correctly, and working across the Product team to ensure product usage data is analyzed and visualized in a way that can drive product and growth decisions.

Please see the Telemetry direction page for more information about Telemetry's mission, vision, and priorities.