Three Year Strategy
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 the leading complete DevSecOps Platform. We 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:
1) Customer Results
Ensure that GitLab is the default when customers buy DevSecOps software.
- Even easier to buy
- Prove value
- Advocate Training
- Advocate Certification
- Standardize customer value data
- Value Streams Dashboard for Executive
2) Mature the Platform
Build upon our current platform to meet current and future user needs.
- Be recognized as the leader in the DevSecOps Platform Category
- Curated experience
More detail on our product strategy can be found on our direction page.
3) Grow Careers
Support GitLab team members in excelling within GitLab and beyond. Be a company to externally emulate and have a training impact that extends beyond the wider-community.
- Increase team diversity
- Great training
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.
- Fast follower: we don’t have to be first to market and we don’t suffer from Not Invented Here (NIH)
- Values: make decisions based on our values, even if it is inconvenient.
- Reach: go for a broad reach, no focus on business verticals or certain programming languages.
- Seed then nurture: plant seeds and nurture the product to build out depth.
- Speed: ship every change in the next release to maximize responsiveness and learning.
- Life balance: we want people to stay with us for a long time, so it is important to take time off and work on life balance; being all-remote is a large part of the solution.
- Open Source Stewardship: be a good steward of GitLab and collaborate with the wider community to improve the product together.
Seed then nurture
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 want to be efficient with capital, we want 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.
- Open source user benefits: significant advantages over proprietary software because of its faster innovation, higher quality, freedom from vendor lock-in, greater security, and lower total cost of ownership.
- Open Source stewardship: the wider community comes first, we play well with others and share the pie with other organizations commercializing GitLab.
- Innersourcing is needed and companies will choose one solution top-down.
- A single application where interdependence creates exceptional value is superior to a collection of tools or a network of tools. Even so, good integrations are important for network effects and making it possible to integrate GitLab into an organization.
- To be sustainable we need an open core model that includes a proprietary GitLab EE.
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.
graph BT; id1(More Users)-->id2(More Revenue); id2(More Revenue)-->id3(More Features); id3(More Features)-.->id1(MoreUsers); id1(More Users)-.->id4(More Contributions); id3(More Features)-->id1(More Users); id4(More Contributions)-.->id3(More Features);
KPIs and Responsible departments
| Part of flywheel | Key Performance Indicator (KPI) | Department | |————– —|———————————|————| | More Users | Stage Monthly Active Users | Product | | More Contributions | Unique Wider Community Contributors per month | Developer Relations and Engineering | | More Contributions | MRARR | Developer Relations and Engineering | | More Contributions | Wider community contributions per release | Developer 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 |
Flywheel with two turbos
Compared to other DevOps platforms, GitLab leverages one or two unique turbos that boost the company:
- Advantages of a single application, leading to more Stages per Organization
- Open Source stewardship, leading to Wider community contributions
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.
graph TB id2(R&D Wider MR Rate) --> id1 id1(Wider community contributions Turbo) --> id3 style id1 color:#ffffff, fill:#9B51E0 id3(Stage maturity increase) --> id4 id3 --> id9 id4(MAU increase) --> id5 id5(More Licensed users) --> id6 id6(Net ARR) --> id12 id12(ARR) --> id8 id7(R&D spend ratio) --> id8 id8(R&D investment) --> id11 id11(Development Department Narrow MR Rate) --> id2 id9(SpO increase Turbo)--> id5 style id9 color:#ffffff, fill:#9B51E0 id9 --> id10 id10(Higher Revenue per licensed user) --> id6 id6 --> id7
Legend with links to the relevant metrics:
- Wider community contributions Turbo
- R&D Overall MR Rate
- Stage maturity increase
- MAU increase
- SpO increase Turbo which is only possible in a single application with multiple stages
- More Licensed users is due to an increase in unlicensed users (MAU) and the increase in SpO leading to a higher conversion from free to paid and a higher gross retention.
- Higher Revenue per licensed user due to the Advantages of a single application
- Net ARR stands for Annual Recurring Revenue is our most important KPI
- ARR stands for Annual Recurring Revenue and IACV increases it.
- R&D spend ratio becomes higher if the growth rate is higher due to the Hypergrowth Rule
- R&D investment is the amount of money spend on Product Management and Engineering excluding Support
- Development Department Narrow MR Rate
Publicly viewable OKRs and KPIs
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.
North Star KPI
Our North Star KPI is revenue vs. plan. While our revenue data is limited access given that it is material nonpublic information (MNPI), revenue 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.
How will the three year strategy process work
- The first phase of the strategy process is the Market Vision, SWOT and Positioning Strategy.
- Market Vision is our shared view of the market over the next ~3 years. Where is the market headed? What factors are influencing the market direction? Where are the points of change, as these will be the points of control?
- SWOT stands for Strengths, Weaknesses, Opportunities and Threats.
- Positioning strategy will highlight the way we want to position the company over the next three years. This will drive key decisions and tradeoffs we need to make in the strategy.
- The second phase of the strategy process is taking the SWOT, positioning strategy and define the GTM, Product and Operations strategy. The output of these three strategies will be the strategic priorities for each, capabilities needed that we have and that we need to develop and the things we will explicitly not do. In addition we will define 3-5 big bets the company will take - this will fold in under the strategic themes. Once we have these 3 to 5 themes we will synthesize them into a corporate strategy that ensures alignment among GTM, Product and Operations strategy.
- Third phase will be the Long Range Plan process.
- Fourth phase will be defining yearlies and the annual operating plan.
Big Bet Process
Positioning and SWOT published in internal handbook with description of strategy process two weeks post offsite
- May 15th eGroup review (Complete)
eGroup capability gap exercise at eGroup offsite (prework)
- Complete: Jun 28th
Complete capability gap exercise at VP level to bring more input into the group
- Directs Group
- Drafts: July 12th
- Final: July 19th
Pull together comprehensive view of capabilities from eGroup and VP sessions Craig/Dave
- July 24th
eGroup June Virtual Offsite Sessions:
- Decide on GTM, Ops and Product strategies
- Decide on top capabilities for investment (feed into LRO)
- Aug 1-3rd
Kickoff LRO with inputs from this process
Why is this page public?
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.”