Develop a respectful and privacy focused data collection framework that allows us to make informed product decisions and improve the customers experience, and promote conversion, adoption of key stages, and increase our user base.
The Growth sub-department consists of groups that eliminate barriers between our users and our product value.
Deliver product intelligence data to improve the GitLab product
Product Intelligence Group: Product Intelligence focuses on providing GitLab's team with data-driven product insights to build a better GitLab. To do this, we build data collection and analytics tools within the GitLab product in a privacy-focused manner. Insights generated from Product Intelligence enables us to identify the best places to invest people and resources, what product categories mature faster, where our user experience can be improved, and how product changes impact the business. You can learn more about what we're building next on the Product Intelligence Direction page.
Drive value for the business and our users by improving trial to paid conversion, per-stage adoption, and wider usage of GitLab
We focus on validating ideas with data across the following four Groups:
The Growth groups also provide development input into two Growth product areas of focus:
We work on the issues prioritized by our product teams including running experiments on GitLab.com. More information on priorities can be found on the Growth direction page.
Unlike most other teams in the engineering division the Growth sub-department has Fullstack Engineers. The reason for this is that the Growth sub-department has a need for both Frontend and Backend skill-sets, but as a small team, has optimized for team member efficiency to adopt the Fullstack role.
Some useful links to see how and what we are working on include:
| Person | Role |
|---|---|
| Nicolas Dular | Interim Fullstack Engineering Manager, Product Intelligence |
| Phil Calder | Interim Senior Engineering Manager, Growth |
| Wayne Haber | Director of Engineering, Growth, Fulfillment, and Applied ML |
The following people are permanent members of groups that belong to the Growth sub-department:
| Person | Role |
|---|---|
| Alex Buijs | Senior Fullstack Engineer, Growth:Activation |
| Eugie Limpin | Senior Fullstack Engineer, Growth:Activation |
| Person | Role |
|---|---|
| Jay Swain | Senior Fullstack Engineer, Growth:Adoption |
| Jeremy Jackson | Senior Fullstack Engineer, Growth:Adoption |
| Person | Role |
|---|---|
| Alper Akgun | Staff Fullstack Engineer, Growth:Conversion |
| Dallas Reedy | Fullstack Engineer, Growth:Conversion |
| New Vacancy | Fullstack Engineer, Growth:Conversion |
| Sam Figueroa | Fullstack Engineer, Growth:Conversion |
| Person | Role |
|---|---|
| Doug Stull | Senior Fullstack Engineer, Growth:Expansion |
| Jackie Fraser | Fullstack Engineer, Growth:Expansion |
| Person | Role |
|---|---|
| Alina Mihaila | Senior Backend Engineer, Product Intelligence |
| Alishan 'Ali' Ladhani | Backend Engineer, Product Intelligence |
| Luis Mejia | Backend Engineer, Product Intelligence |
| Mikołaj Wawrzyniak | Senior Backend Engineer |
| Niko Belokolodov | Senior Backend Engineer |
| Piotr Skorupa | Backend Engineer, Product Intelligence |
| Rajendra Kadam | Backend Engineer, Product Intelligence |
| Person | Role |
|---|---|
| Axel García | Frontend Engineer, Product Intelligence |
The following table shows who will provide cover if one or more of the Growth Engineering management team are unable to work for any reason.
| Team Member | Coverered by | Escalation |
|---|---|---|
| Wayne Haber | Christopher Lefelhocz | Eric Johnson |
| Nicolas Dular | Phil Calder | Wayne Haber |
| Phil Calder | Nicolas Dular | Wayne Haber |
If an Engineer is unavailable the Engineering Manager will reassign open issues and merge requests to another engineer, preferably in the same group.
Some people management functions may require escalation or delegation, such as BambooHR and Expensify.
This can be used as the basis for a business continuity plan (BCP), as well as a general guide to Growth Engineering continuity in the event of one or more team members being unavailable for any reason.
We work closely with the Data Team along with our Product Team counterparts to design and implement experiments that measure the impact of changes to our messaging, UX, and overall experience of using GitLab.
The following members of other functional teams are our stable counterparts:
| Person | Role |
|---|---|
| Gayle Doud | Senior Product Manager, Growth:Expansion |
| Jensen Stava | Senior Product Manager, Growth:Activation |
| Michael Karampalas | Principal Product Manager, Growth:Adoption |
| Sam Awezec | Principal Product Manager, Growth:Conversion |
| Emily Bauman | Product Designer, Growth:Activation |
| Kevin Comoli | Product Designer, Growth:Conversion |
| Matej Latin | Senior Product Designer, Growth:Expansion and Adoption |
| Kati Paizee | Senior Technical Writer, Growth, Ecosystem (Integrations) |
| Andrew Kelly | Senior Security Engineer, Application Security, Growth (Activation, Conversion, Expansion, Adoption), Fulfillment (Purchase, License, Utilization), Enablement (Distribution, Geo, Memory, Global Search, Database) |
| Vincy Wilson | Quality Engineering Manager, Enablement, Fulfillment, Growth, ModelOps, and Sec |
| Hila Qu | Director of Product, Growth |
| Jacki Bauer | Product Design Manager, Growth & Fulfillment |
The Growth sub-department uses the ~"devops::growth" label and the following groups for tracking merge request rate and ownership of issues and merge requests.
| Group name | Group label |
|---|---|
| Product Intelligence | ~"group::product intelligence" |
| Activation | ~"group::activation" |
| Adoption | ~"group::adoption" |
| Conversion | ~"group::conversion" |
| Expansion | ~"group::expansion" |
Our team follows the Product Development Flow utilizing all labels from ~workflow::start to ~workflow::verification.
We adhere to the Completion Criteria and Who Transitions Out outlined in the Product Development Flow to progress issues from one stage to the next.
We use workflow boards to track issue progress throughout a milestone. Workflow boards should be viewed at the highest group level for visibility into all nested projects in a group.
There are three GitLab groups we use:
| gitlab-org | gitlab-com | gitlab-services | all groups |
|---|---|---|---|
| Growth Workflow | - | Growth Workflow | - |
| Activation Workflow | - | Activation Workflow | - |
| Conversion Workflow | - | Conversion Workflow | - |
| Expansion Workflow | - | Expansion Workflow | - |
| Adoption Workflow | - | Adoption Workflow | - |
| Product Intelligence Workflow | - | Product Intelligence Workflow | - |
| Experiment tracking | - | - | - |
| Feature flags | - | - | - |
Before work can begin on an issue, we should estimate it first after a preliminary investigation. This is normally done in the monthly planning meeting.
| Weight | Description (Engineering) |
|---|---|
| 1 | The simplest possible change. We are confident there will be no side effects. |
| 2 | A simple change (minimal code changes), where we understand all of the requirements. |
| 3 | A simple change, but the code footprint is bigger (e.g. lots of different files, or tests effected). The requirements are clear. |
| 5 | A more complex change that will impact multiple areas of the codebase, there may also be some refactoring involved. Requirements are understood but you feel there are likely to be some gaps along the way. |
| 8 | A complex change, that will involve much of the codebase or will require lots of input from others to determine the requirements. |
| 13 | A significant change that may have dependencies (other teams or third-parties) and we likely still don't understand all of the requirements. It's unlikely we would commit to this in a milestone, and the preference would be to further clarify requirements and/or break in to smaller Issues. |
In planning and estimation, we value velocity over predictability. The main goal of our planning and estimation is to focus on the MVC, uncover blind spots, and help us achieve a baseline level of predictability without over optimizing. We aim for 70% predictability instead of 90%. We believe that optimizing for velocity (merge request rate) enables our Growth teams to achieve a weekly experimentation cadence.
Our work is planned and delivered on a monthly cycle using milestones. Our team follows the Product Development Timeline utilizing all dates including from M-1, 4th: Draft of the issues to M+1, 4th: Public Retrospective.
We use milestone boards for high level planning and roadmapping across several milestones.
Info on the Growth UX team and how they work can be found on the Product/Growth page.
To help our team be efficient, we explicitly define how our team uses issues.
We aim to create issues in the same project as where the future merge request will live. For example, if an experiment is being run in the GitLab CustomersDot, both the issue and MR should be created in the CustomersDot project.
We emphasize creating the issue in the right project to avoid having to close and move issues later in the development process. If the location of the future merge request cannot be determined, we will create the issue in our catch-all growth team-tasks project.
We use issue templates for common tasks.
To support Iteration Growth engineering:
5 and higher should be reassigned to the Product Manager to make sure they can be split into smaller MVCs.
When this is not possible, the Product Manager will create a spike or research issue so that engineering can break it down and close the original.The DRI (assignee) of an issue is encouraged to add an async issue update, particularly for issues labelled ~Deliverable or ~Growth-Deliverable.
These updates can be added anytime and are useful to highlight when an issue is on track, blocked, or may need to be re-prioritized.
This helps us maintain transparency and our bias towards asynchronous communication.
Async issue update
**YYYY-MM-DD Update**
#### Please provide a quick summary of the current status (one sentence).
#### When do you predict this feature to be ready for maintainer review?
#### Are there any opportunities to further break the issue or merge request into smaller pieces (if applicable)?
#### Were expectations met from a previous update? If not, please explain why.
The Growth groups regularly run experiments to test product hypothesis.
GitLab team members are welcome to attend the Growth Engineering Weekly meetings to connect with growth team members and find out more about running experiments at GitLab.
The Growth sub-department experiment teams track the number of closed "growth deliverable" issues prioritized by our product managers using the Growth-Deliverable definition. This metric acts as a target for deliverables based on number of engineers available to the four Growth experiment teams.
The following view shows the breakdown of closed Growth issues by type. This highlights the percentage of issues that relate to experiments or features.
The Growth sub-department tracks number of experiments per engineer as a development metric. This counts new experiments added to the codebase using experiment feature flags. Current experiments shows the total number of experiments in the codebase (pending, active, or concluded and ready to be removed).
Every week, engineers in the Growth sub-department meet to discuss topics related to growth engineering. Discussion topics include how to track experiments, A/B testing, product intelligence and data concerns, and changes at gitlab affecting engineering. Growth Engineers are encouraged to bring discussion topics to the meeting and add them to the agenda.
To get the most time zone coverage, these meetings alternate fortnightly between:
Team members are encouraged to contribute to the agenda async and attend the meeting that matches their time zone.
On occasion we put together a virtual team day to take a break and participate in fun, social activities across our Product, Development, UX, Data and Quality functions.
#s_growth in Slack (GitLab internal)#g_product_intelligence in Slack (GitLab internal)