How the growth section works

Overview

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:

• Activation, Conversion, Expansion, and Adoption connect users to the existing value that GitLab already delivers by rapid experimentation.
• Analytics Instrumentation builds the backbone of data that other groups need to be successful, enabling a data-informed product culture at GitLab.

Growth’s ultimate goal is to connect GitLab’s value as a Single DevOps Platform with our customers. In order to do that, we take a zoom in and zoom out approach. We break down the entire GitLab growth model, and identify the highest ROI lever at this moment to focus on. In the Growth direction page we outline the Growth section’s long term direction and near term focus areas.

How the Growth section works

All the Growth team members are listed here We follow the Product Development Flow.

Growth ideation and prioritization

Anyone is welcome to submit ideas to the experiment idea backlog using the experiment idea template.

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

• Impact - high score for high impact
• Confidence - high score for high confidence
• Ease - high score for ease

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.

5 min: Social questions

5 min: Announcements

30 min: Group updates

• KPI & OKR (Live)
• Highlights & Learnings (Live)
• Activities (Read only)
• Next UP (Read only)

10 min: Discussions

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.

Other regular Growth meetings

In addition to the weekly Growth meeting, Growth team members participate in the following regular meetings:

1. Weekly Growth Engineering
   1. Attendees: Growth team members
   2. Goals: Discuss anything Growth engineering related.
   3. Agenda: link
2. Weekly Analytics Instrumentation and Data Weekly Sync
   1. Attendees: Analytics Instrumentation and Data
   2. Goals: Stay in-sync for work across Analytics Instrumentation, Data Engineering, and Data Analysis.
   3. Agenda: link
3. Weekly Growth & Threat Management EM
   1. Attendees: Growth & Threat Management EMs
   2. Goals: Stay in-sync on growth engineering efforts.
   3. Agenda: link
4. Weekly Growth PM sync
   1. Attendees: Growth PMs
   2. Goals: Stay in sync as a PM team, discuss PM specific issues/ideas
   3. Agenda: link
5. Analytics Instrumentation, Fulfillment, Data, Customer Success, and Sales Weekly Sync
   1. Analytics Instrumentation, Data, Customer Success, and Sales
   2. Goals: Stay in-sync for work across Analytics Instrumentation, Data, Customer Success, and Sales
   3. Agenda: link
6. Monthly sync meeting with the Data team
   1. Attendees: Growth PMs and Data team
   2. Goals: Keep the Data team aware of upcoming changes that may impact them, get proactive feedback on how to set up data and tracking needs
   3. Agenda: link
7. Monthly sync with Growth Marketing
   1. Attendees: Growth PMs and Growth Marketers
   2. Goals: Stay in-sync and work as efficiently as possible together
   3. Agenda: link
8. Monthly sync with Product, Legal, Compliance, Data, and Privacy
   1. Attendees: Product, Legal, Compliance, Data, and Privacy
   2. Goals: Answer any legal, compliance, and privacy concerns
   3. Agenda: link
9. Monthly sync with Growth section and Application Security
   1. Attendees: Product, Engineering, Application security
   2. Goals: Growth / Application Security stable counterparts monthly discussion
   3. Agenda: link

How Growth launches experiments

Since the Growth section is among the first groups to launch product experiments and A/B testing, we summarized the current tooling and process in the list of guides and documentation below to help other teams interested in experimentation to get started faster.

• Experiment guide for Product managers
• Experiment ideation Process
• Engineering guide for how to run experiment
• Growth Engieering Handbook page on running experiments
• A way for GitLab team members to view currently active experiments on GitLab.com

How Growth collaborates with other groups

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:

• Manage is responsible for user registration and management. This stage maintains a long-term vision on how users are created and maintained in GitLab, with a roadmap that includes other categories and priorities.
• Growth may identify user registration as an opportunity to further the group’s priorities. Growth’s engineering team may ship smaller improvements independently of Manage’s direct involvement during implementation (such as soft email confirmation), but may need to partner with Manage on larger efforts like a completely new onboarding experience.
• The group ultimately owning the change - in this case, Manage - would review Growth’s contributions into their area of the product and - like a contribution coming from the wider community - ultimately own the final result.

UX

How UX participates in milestone planning

When the planning issue is created the Product Designer should follow these steps:

• Review the issue boards and the prioritization dashboard (issues should be ordered by priority)
• Determine whether they agree with the prioritized issues or want to suggest a change. For example, are there any SUS impacting issues we’ve been neglecting?
• Comment in the planning issue to discuss proposed changes.
• Re-order the board once priority is decided.
• Ensure that issues have weights.

A note about capacity management

Every milestone will have more work than we can commit to. Product designers know the approximate number of issue weights they can take on in order to do the work to our high standards. Never take on more issue weights than you can, and don’t compromise other important tasks such as professional development and UX department initiatives. This leads to burnout. Follow the escalation instructions to make your wider team aware of the issues you can’t take on so that they can explore additional options or tradeoffs.

How UX Works

We follow the Product Designer workflows and UX Researcher workflows described in the Product Design section of the handbook. As Growth designers, we relentlessly measure the impact of our design changes following the experimentation workflow. In addition:

• we have issue boards so we can see what everyone is up to. Refer to issue boards in our planning issues. For example, this is the template for Acquisition Planning issues.
• we label our issues with UX, devops::growth and group::.
• we will label experiments with UX problem validation and UX solution validation according to the UX Research Workflow definitions to indicate the type of learning the experiment achieves. The purpose of these labels is to track this UX KPI related to research velocity.
• we use the workflow labels for regular issues and experiment workflow labels for experiment issues.
• we use milestones to aid in planning and prioritizing the four growth groups of Acquisition, Conversion, Expansion and Retention.
  • PMs provide an ICE score for experiments and by using priority labels for other issues.
  • The Product Designer applies the milestone in which they plan to deliver the work (1-2 milestones in advance, or backlog for items that are several months out. For example, if an issue is not doable for a designer in the current milestone, they can add the next milestone to the issue, which will communicate to the PM when the work will be delivered.
  • If the PM has any concern about the planned milestone, they will discuss trade-offs with the Product Designer and other Growth PMs.
• we use UX issue weights in order to better estimate capacity, realistically break down our work, and give PMs a little insight into how much work we can take on in a milestone.
  • Label the issue for UX work with UX and assess the issue weight. Issues larger than an 8 should be broken down further.
  • Use the scoped labels starting with design weight to add the UX weight to an issue.
  • When the UX work is ready to be transitioned into Engineering, apply the workflow lable workflow::planning breakdown.
• We have a Figma template for designing experiments. You should title your Figma designs to be consistent with the experiment name, and link the experiment issue to the Figma file. When the variants are ready, add the control and variants to the “All the variants” page and provide context as needed. If you are conducting multiple experiments in the same area, consider using the same Figma file but include different pages per experiment design.

UX Definition of Done (DoD)

Together with the Product Manager, the Product Designer applies the DoD to epics in order to better break down design work and give counterparts better insight into which steps in the design workflow need to be completed before the MVC can move to the development phase.

In addition to the Validation Phase Outcomes listed in the Product Development Flow, we also make sure that:

• For an experiment, experiment issues have been created with a hypothesis and experiment plan, and experiment labels have been applied
• Cross-team dependencies have been identified and those teams notified and their feedback received
• Prototypes or mocks for the selected solution have been completed and and it is clear through the documentation and content of issues that they are Ready for Development
• Previous versions and discussions of the solution(s) are labeled as ‘Draft’, and should not appear in the Epic description
• If changes involve copy, ~“Technical Writing” and ~“UI text” labels have been added
• Design spec has been added to the designs. Try to link to relevant components in gitlab-ui
• For design patterns that aren’t in Pajamas (done sparingly), detailed implementation annotations are included engineering has reviewed
• Follow up issues have been created in the design system project for any new design patterns or documentation updates
• UX issues are closed and the SSOT (epic) is updated with a link to the completed design, along with design rationale for key decisions.
• The MVC engineering issue has been updated and labeled ~“workflow::planning breakdown”

Visual Reviews of MRs

The engineering team applies the UX label to any MR that introduces a visual, interaction or flow change. These MRs can be related to new issues, bugs, followups, or any type of MR. If the engineer isn’t sure whether the MR needs UX, they should consult the designer who worked on the related issue, and/or the designer assigned to that stage group, or the Product Design Manager.

Visual reviews are required for any MR with the UX label. When the MR is in workflow::In review, the engineer assigns the MR to the designer for a visual review using the reviewer functionality in the sidebar. This can happen in parallel with the maintainer review, but designers should prioritize these reviews to complete them as quickly as possible.

There are times when it isn’t possible or practical for a designer to complete their visual review via Review Apps or GDK. At these times the designer and engineer could coordinate a demo or the engineer could record a video of themselves going through the new functionality and add it to the MR. Creating a video is a way to speed up the review process, however it is optional and not always an appropriate stand in for a full review.

UX Scorecards

All of the planned, in progress and completed UX Scorecards for Growth can be found in this epic. For more information, read about UX Scorecards.

UX Scorecards can be used to evaluate onboarding experiences and we also include onboarding criteria in our UX Heuristics.

UX Themes and Labels

We use labels to track UX improvements across a few themes. This allows us to track our work more holistically against big areas we’ve identified for UX improvement.

For now, these themes/labels are:

• Easy to Trial GitLab
• Feature Discoverability
• Onboarding New Users
• Easy Upgrade Flows

Collaboration process with other Product teams

We use this process to make sure growth and product teams are maximizing business impact while ensuring close collaboration.

Proposed Growth-Feature Product Owner collaboration process

1. Growth identifies a focus area that may potentially touch the areas owned by another product team. For example, growth will be focusing on new user adoption of Create & Verify features starting in FY21 Q4.

2. Growth reaches out to have a sync or async kickoff conversation with the product team (ideally including PM, EM, UX). The goal of the kickoff is to:

   • Inform the Product feature owner that growth is planning to experiment in this area;
   • Share growth’s high level plans and ideas to avoid conflicting roadmap and duplicate efforts;
   • Form a plan how the 2 teams can keep each other updated async, for example, ping the PMs on the relevant issues async or sync meetings etc.
   • Ideally, establish understanding of both teams’ KPIs and objectives

3. Growth will post regular updates on what we are working on, what has been shipped, what’s up & next, and the results & learnings from analyzed experiments to channels such as Key Reviews, GC, and potentially a monthly summary video.

4. Most growth experiments will be focused on UX/copy flow changes initially, and these will follow the typical GitLab code review process.

5. We don’t expect to have many new “features” developed from growth experiments, but in the rare case that this happens or if we feel like the UX flow we developed needs to have a permanent owner, the Growth team will work to identify an appropriate product owner, and hand it off to the owner following the typical community contribution process.

6. For UX Collaboration, Product Designers will do the following

   • The Growth Product Designer will mention the stage group Product Designer when starting work on a design issue for awareness and to gather background information such as existing constraints, usability problems and existing research. (Growth PMs will communicate in a similar way to Stage PMs)
   • The Growth Product Designer will add the stage group Product Designer to design reviews to get feedback and ensure consistency. Design reviews can be sync or async, for example:
     • Scheduling a recurring monthly sync call.
     • Creating a document for async catching up (template) and a calendar event to remind everyone involved to share what they’re working on.
   • UX Researchers should share research results with stage groups whenever that research is relevant cross-stage.

Contributing to the Learn GitLab project

The Learn GitLab project is utilized to onboard new users to GitLab and contains self-paced issues the user can complete to help set them and their team up for success within the GitLab platform. There are currently two separate Learn GitLab projects, one for new free SaaS signups and one for new SaaS trial signups. The growth team is still actively experimenting with improvements to this experience. If you’d like to contribute an improvement to one of the Learn GitLab projects, you can do so by following the steps outlined in this issue.

Growth RADCIE and DRIs

In alignment with GitLab’s RADCIE approach, the DRIs for the following tasks would be:

It is in the Growth teams purview to run any experiment in any area of the application. Growth’s ability to experiment in this manner is designed to further learning potential for the larger GitLab team and support business priorities. When an experiment impacts the area of another product owner/team, Growth informs them following the collaboration model above. Product owners/teams are encouraged to raise concerns and provide further context. Ultimately, Growth determines whether the experiment is deemed a success using data and input from relevant teams. The product owner/team is made aware of the result and next steps.

View page source - Edit this page - please contribute.