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:
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 GitLab.com, which is a different user signup and activation process than self-managed instances, which typically involves direct sales.
ARRR stands for Acquisition, Activation, Retention, Revenue, and Referral which is often referred to as "Pirate Metrics". These five words represent the customer journey and the various means a product manager may apply a North Star metric to drive a desired behavior in the funnel.
Add AARRR funnels for your stage or group's North Star Metrics directly with mermaid markdown. It's easy if you use this live editor.
Product managers can use these various state to prioritize features that drive a desired action. This could mean focusing on the Activation metric to drive awareness and generate more
top of funnel leads. As an example, in the Release stage the Release Management group tracks actions on the Release Page in GitLab. Users that view a Release Page have been
acquired and those that create a release on a Release Page are
activated users. The Product Manger can choose to target features that drive users to view the Release Page more, resulting in a greater interest in the number of users that become activated and create their own Releases.
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. At the same time, we strive to be informed by data and driven by empathy towards our users. This guideline will help us make informed decisions that align with our strategy and bring value to our users, avoiding the usage of dark patterns to move a KPI in the right direction.
Acquisition, Conversion, Expansion and Retention will consist of a product manager, engineering manager, UX manager, some full-stack engineers, a (shared) data analyst, and four Product Designers. Each group member will have a functional reporting structure, in order to report to a leader that understands their job function. More information about the Growth UX Team.
The foundational user journey is from Create -> Verify. This is the most common combination of stages, and we believe when users experience these two stages they begin to understand the broader power of a single application for the entire DevOps lifecycle. We are working on several projects to increase the number of users enjoying Create and Verify together. Examples:
Note: There are numerous potential variants to this adoption journey, but it's important to keep this representation simple and consistent. Please check with Scott Williamson first before making any changes to the adoption journey image.
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.
In addition to the weekly Growth meeting, Growth team members participate in the following regular meetings:
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:
The Fulfillment Group is responsible for the maintenance and technical strategy of the customer portal application, the license application, and the billing and licensing experience for both internal and external customers. Fulfillment is also concerned with e-commerce compliance, add-on products, and internal tools for GitLabbers to work more efficiently when helping customers.
Key areas of focus for the Fulfillment Group are:
The Acquisition, Conversion, Expansion, Retention, and Fulfillment Product Teams will collaborate on longer-term strategic initiatives that involve the customers and license applications to ensure that the underlying technical architecture implemented by the Fulfillment engineering team supports the longer-term roadmap of each of the below areas.
Acquisition is measured by the New Signup ARR KPI and this team is responsible for optimizing the UX workflow for new user sign-ups, both self-hosted and on GitLab.com. This team will also be involved in sign up messaging (in conjunction with the marketing team), first-run experiences, initial purchase, and multi-channel engagement for users that have not progressed into active product use.
Conversion is measured by the Free to Paid Trial ARR growth KPI and owns the experience of new customers choosing to trial GitLab (both self hosted and on GitLab.com). This team will manage processes related to trial lengths, restrictions and internal touch points, and optimize both in product and external messaging for customers trialing GitLab.
Expansion is measured by the Net Retention KPI and owns the experience of customers upgrading to higher tiers, and adopting more users. Upgrades can be influenced by messaging, navigation changes, empty state UX, and other forms throughout other sections of the product.
Retention is measured by the Gross Retention KPI and works holistically to prevent customer churn by improving the customer journey and internal processes of renewing accounts (including true-ups), soliciting and acting on feedback from customers who have chosen not to renew, and owning multi-channel messaging such as email and in-app messaging to drive renewals.
Ownership of an experience or workflow includes the priorization and delivery of related bugs, security fixes and other technical priorities by that team.
A growth deliverable should be a released feature or a launched effort that is expected to directly impact KPIs, improve external & internal customer experiences
We will use the label
~Growth-Deliverable to differentiate this from a typical product deliverable. A "Growth-Deliverable" should be:
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:
In alignment with Gitlab's RADCIE approach, the DRIs for the following tasks would be:
|Hypothesis Generation||Growth Product/Engineering|
|Experiment Design||Growth Product/Engineering|
|Experiment Implementation||Growth Product/Engineering|
|Contribution Review||Stage Product/Engineering|
|Experiment Ramp||Growth Product/Engineering|
|Post-Experiment Analysis||Data Team|
|Post-Experiment Decision||Growth Product/Engineering|
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.
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.