The Expansion Team at GitLab focuses on running experiments to increase the expansion of our platform and expanding usage by teams within an organization or by individual users. Additionally we strive to increase the value of Gitlab to existing customers getting them to adopt new features in higher paid tiers. It's easy to look at GitLab and quickly come to a conclusion that our platform is for technical teams only (e.g. developers and engineers) but in fact many other non-technical teams can use GitLab to increase efficiency and integrate their work into a company's development life-cycle. To call out a few Product Managers, Data Analysts, Marketers, Support, UI/UX and Executives use GitLab in their day-to-day. We want to get these teams to that ‘ah-Ha!’ moment so they can also benefit from using the platform. Our experiments are all public and we encourage feedback from the community and internal team.
Product Manager: Tim Hey | Engineering Manager: Phil Calder | UX Manager: Jacki Bauer | Product Designer: Matej Latin | Full Stack Engineer: Doug Stull | Full Stack Engineer: Jackie Fraser
Expansion 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 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.
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:
The user workflows on GitLab.com and our Self-managed instances are very different and should be treated separately. We will be focusing on the 2 described below. note: our sales team outlines the process in point 3. on this page. (Again the sales motion is very different than the self serve experience on GitLab.com).
Add-on purchases - ci minutes (dashboard), seats etc. Note: seat adds for expansion happen outside the renewal process think of opportunities to add more users through projects and groups vs. adding users during renewal.
Tier upgrades - The movement of customers from tier to tier can be found in this dashboard. Keep in mind we're focused on customers who are already paying subscribers no free to paid. Here is the UX Scorecard for upgrading accounts
The external user personas on GitLab.com and our Self-Managed instances are very different and should be treated as such. We will be focusing on the 2 described below.
In addition to the personas, it's also important to understand the permissions available for users (limits and abilities) at each level.
We are constantly running experiments and use the table below to keep the wider GitLab community updated the most interesting experiments we are running. If you are curious to see everthing we are working on please visit our experiment workflow board
|If we prompt users to add pipelines when they have already authored an MR we can increase pipelines which leads to ci minute usage, a potential add on sale and product adoption of the verify stage.||MR with no pipelines, suggest pipeline||6.7||Active Experiment on .com for 100% of users||Winner! Dashboard - Experiment Tracking issue|
|If we increase the places we display an option to buy minutes when a customer is running low we will increase the # of ci minute purchases.||Add a 'buy ci minutes' option in the top right drop down (user settings menu) on GitLab.com||6.0||Active on .com for 100% of users||Winner! Dashboard - Experiment Tracking issue|
|If we display a notification dot over the user's avatar when they are running out of ci minutes they will expand the user settings menu and be shown a buy ci minutes button and this will lead to more ci minute add on purchases.||Add a notification dot when 'buy ci minutes' button is displayed in the user settings on GitLab.com||6.3||Ready to launch||Pending - Dashboard - Experiment Tracking Issue|
|If we add an upgrade button to the user settings menu on gitlab.com we will see more upgrades.||Add an 'upgrade' option in the top right drop down (user settings menu) on GitLab.com||6.3||Active on .com for 30% of users||Experiment Tracking Issue - Dashboard (pending)|
|If we create a modal that can be used in various places in the the app. We can make it easier for users to invite their team members.||Move the "invite members" form into a modal and create a component that can then be consistently used throughout the app||6.7||Active Experiment on .com for 20% of users||Pending - Dashboard - Experiment Tracking Issue|
|If we create a modal to invite team members that can be used in various places in the the app. We can make it easier for users to invite their team members.||Move the "invite members" form into a modal and create a component that can then be consistently used throughout the app||6.7||Active Experiment on .com for 20% of users||Pending - Dashboard|
|If we add a link to the docs page on how to upgrade your account for self-managed instances we will increase self-serv upgrades.||Add a link to "account upgrade documentation" for self-managed users in the UI||6.0||Blocked|
|If we improve the ci minutes checkout process we will increase ci minute purchases and reduce support tickets.||Make the "Buy add-on CI minutes" process simpler and clearer||7.3||Solution Validation|
|If we shift the way users are added to groups only we can reduce the # of nested users and increase the # of users in groups.||Automatically bill for newly added members in personal namespaces||7.0||Problem Validation|
|If we prompt users to add team members to a group we will increase the total # of users per group||Prompt a user to add additional members to a single member group||7.0||Problem Validation|
|If we create an new account overview page for self-managed instance with all the information a customer would need to make an educated decision around upgrading we would increase more self-serv upgrades.||WIP: Create an "account overview" page for self-managed instances||6.7||Problem Validation|
|If we prompt our users to invite their team members to a group we will increase the adoption of groups.||Increase group adoption of GitLab by increasing the motivation and improving triggers for inviting team members||8.3||Validation Backlog|
|If we gave a user and estimate for an upgrade we would increase upgrades.||Give the user an estimate for the upgrade||4.3||Validation Backlog|
|If we introduced an easier way to contact sales about upgrading a self-managed account we would reduce customer stress and increase sales serv opportunities for upgrades.||Introduce an easier way to contact sales about upgrading a self-hosted instance plan||5.0||Validation Backlog|
|If we enabled the ability to update an existing license to a new tier we would increase upgrades and reduce licenses app access.||Add the possibility to update a license to a different plan||6.7||Validation Backlog|
|If we update the documentation on how to upgrade your self-managed plan we will improve our customer experience and increase upgrades||Update the existing documentation for upgrading self-managed subscriptions||4.7||In Production|