Our strategy is looking 3 years out and fits into our cadences. It also maps to and reflects GitLab's mission, vision and values. It is a living strategy, so we will revisit on a regular basis and iterate when there is reason to do so.
Along the road to realizing our mission of everyone can contribute, our strategic goal is to be known as the leading complete DevOps Platform (or, what Gartner calls the DevOps Value Stream Delivery platform) delivered as a single application. We will help our customers build better software faster including developing cloud native applications, building mobile applications, and incorporating machine learning and artificial intelligence into their products and solutions. We believe that our dual flywheels (single application + open-core model) will propel us to efficiently be the default choice in the Enterprise market.
To achieve this, we will endeavor to:
Ensure that when customers buy DevOps software the single application approach is the default.
More detail on our product strategy can be found on our direction page.
We will strive to increase the contributions of the wider community.
The customer will be the center of our operations including how we develop, market, and support our products. While we ship fast every month, we are committed to a seamless change management experience for our customers so they can get the best of GitLab in a predictable way. We have a goal that over one thousand of our customers become references.
Developing our team members is a core operating principle at GitLab. We offer a competitive, performance-based total rewards package, in addition to robust learning & career advancement opportunities. GitLab is considered a best place to work for our high performing team members as measured by its talent brand and internal team member satisfaction ( >90%).
As we execute on our strategy, it is important to use our financial targets as guide rails and mature our internal processes for building a durable business for the long-term.
Our GitLab product vision is to deliver a single application for the entire DevOps lifecycle. This is a very expansive product vision that requires us to build an enormous amount of product surface area. Because we are capital constrained, we need to build GitLab as a community. When we are early in a particular area of the product, we will plant seeds by shipping a small MVC. Shipping functionality that is incomplete to expand the scope sometimes goes against our instincts. However, planting those seeds even in an incomplete state allows others to see our path and contribute. With others contributing, we'll iterate faster and will accelerate the maturity of our offering faster than GitLab could on its own. We can have a long tail of categories that are at a minimal maturity that don't get investment until they show traction. While these come with a low level of shame they allow the wider community to contribute and people to express interest. It is much more common for people to contribute to categories that already exist and express interest in categories already shipping in the product. A minimal category is the placeholder to channel energy, and it is our responsibility to till the earth with minimal iterations.
GitLab the product should eventually have depth in every category it offers. To build out real depth requires a shift in focus, from planting seeds to nurturing the product area to maturity. We should concentrate our nurture investments in the categories that have demonstrated monthly active usage, revenue contribution, and demonstrated customer demand. As a product team, we'll be particularly focused on driving monthly active usage at the stage and group level. This should lead to more Stages per Organization, which is important as each stage added triples paid conversion! We'll also be heavily focused on driving usability, by measuring our system usability score, which is a measure of the user perception of GitLab's usability.
If we effectively seed and then nurture, we can fully activate GitLab's two growth turbos, by creating wider community contributions and driving more stages per user.
Please see our pricing model for details
GitLab has two flywheel strategies that reinforce each other: our open core flywheel and our development spend flywheel. A flywheel strategy is defined as one that has positive feedback loops that build momentum, increasing the payoff of incremental effort. You can visualize how the flywheels work in congruence via the diagram below. The KPI and responsibilities table lists the relevant indicator and department for every part of the flywheel.
In the open core flywheel, more features drive more users which in turn drive more revenue and more contributions which lead to more users.
The driving force behind the flywheel is that by using a DevOps platform to replace multiple point solutions, GitLab customers can achieve cost saving and efficiency gain. Therefore, when GitLab develops more features to improve the product maturity, it becomes easier to replace point solutions and GitLab will attract more users.
| Part of flywheel | Key Performance Indicator (KPI) | Department |
|---|---|---|
| More Users | Stage Monthly Active Users | Product |
| More Contributions | Unique Wider Community Contributors per month | Community Relations and Engineering |
| More Contributions | MRARR | Community Relations and Engineering |
| More Contributions | Wider community contributions per release | Community Relations and Engineering |
| More Features | Merge Requests per release per engineer in product development | Engineering and Product Management |
| More Revenue | IACV vs. plan | Sales and Marketing |
GitLab is a complete DevOps platform, delivered as a single application, with contributions from the wider community.
Compared to other DevOps platforms, GitLab leverages one or two unique turbos that boost the company:
The advantage of a single application manifests itself if people start using more stages of the application. In the graph below this is visualized with Stages per Organization (SpO), knowing that an organization using an extra stage triples conversion. Increasing SpO drives both more seats and higher revenue per seat.
In the development spend flywheel, we capture the relationship between merge requests (MRs), changes in ARR from one period to the next (Delta ARR), hyper growth R&D spend and the resulting impact on MRs. We see that more MRs increase stage maturity which drives more monthly active users and stages per user which in turn drives more seats and more revenue which funds R&D spend and leads to more MRs.
Legend with links to the relevant metrics:
To make sure our goals are clearly defined and aligned throughout the organization, we make use of Objectives and Key Results (OKRs) and Key Performance Indicators (KPIs) which are both publicly viewable.
Our North Star KPI is Net ARR vs. plan. While our ARR data is limited access given that it is material nonpublic information (MNPI), ARR versus plan is a leading indicator of our likelihood of success in achieving revenue targets. Predictable revenue attainment is critical for continued business success.
Our yearly plans are linked from the relevant cadence section.
Our strategy is completely public because transparency is one of our values. We're not afraid of sharing our strategy because, as Peter Drucker said, "Strategy is a commodity, execution is an art."