Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Tiering Guidance for Features

On this page

How to make pricing tier decisions

Product Managers are responsible for helping determine and maintain the optimal tier for their features. To accomplish this, Product Managers should leverage the supporting resources below to understand and implement the strategy, philosophy and various components of GitLab's pricing model.

Pricing Tiers

The CEO is the DRI for pricing and tiers. This includes any changes that directly impact how we charge customers under our licensing model, such as a change to how we handle active users. GitLab leverages a buyer-based open core pricing model. Please review the entirety of the stewardship and pricing model pages before making any determinations as to which tier a given feature should go in.

Have a laddered tiering strategy that leverages all three tiers

Ideally each product area has a laddered tiering strategy, where incremental value is contained in each tier. This enables us to drive broad usage in Free, and then drive uptiers to Premium and Ultimate as customers increase in their sophistication of using the given product area. When considering what offer in open source always review what additional features can be monetized later. Open source drives popularity of the main feature, but it's important to understand up front how we intend to leverage that usage and exposure to drive incremental ARR later in higher tiers.

What goes in what paid tier

Our stewardship principles determine whether something belongs in a paid tier. The likely buyer determines which tier.

Determining the tier of a new feature

When making a decision on the tier for a new feature, please refer to the pricing page for guidance. Be sure to consider documenting your rationale for the decision in the issue description, including a reference to our stewardship page when appropriate.

Please indicate the applicable tier for an issue by applying the label associated with the tier (e.g. GitLab Ultimate). Ensure this is defined before feature development begins.

Moving features between tiers or other pricing changes

To propose changing a feature tier or making any other change that impacts how we charge customers, please follow the process and template on the pricing page. This ensures collaboration and alignment with key GitLab stakeholders and maintenance of features.yml as SSOT.

All Premium, and Ultimate features must:

Should product managers have any questions when making tier decisions, they should collaborate with their manager, product leadership, or the CEO for clarification. The most up to date reference for pricing DRIs can be found in the feature tier or pricing change template.

Relevant personas

It can be challenging to find a the balance between users' needs and buyers' decision drivers. Product Managers should frequently engage with the walk through of GitLab's tiers and personas to remain knowledgable on which buyer personas are most relevant to each tier and why. It's important to focus on only the buyer persona when making tiering decisions.

Reasons for upgrade

Multiple considerations go into customers' purchase decisions. Here are some various resources product managers can visit to reference various data points for analysis:

How to consider impact to revenue

Driving revenue

Product managers should be familiar with and leverage strategies and tactics for their own stage as well as across GitLab's other stages in accordance with GitLab's pricing model. Here are some helpful examples:

Understanding Investment

GitLab currently has three ways of allocating investment across product as detailed in investment types.

Learning opportunities

Pricing adjustments within a buyer-based model can be difficult and sometimes feel counterintuitive. Below are some examples of strategies/tactics that have succeeded and failed that we can learn from:

👍

👎

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license