Product Marketing

On this page


What is PMM working on?

Release vs Launch

A product release, and a marketing launch are two separate activities. The canonical example of this is Apple. They launch the iPhone at their yearly event and then releases it months later. At GitLab we do it the other way: Release features as soon as they are ready letting customers use them right away, and then, do a marketing launch later when we have market validation.

Release Launch
PM Led PMM Led
New features can ship with or without marketing support Launch timing need not be tied to the proximity of when a feature was released



Tier Delivery License Fee Time
Libre Self-hosted Open Source Gratis Unlimited
Trial Self-hosted Proprietary Gratis Limited
Starter Self-hosted Proprietary Paid Unlimited
Premium Self-hosted Proprietary Paid Unlimited
Ultimate Self-hosted Proprietary Paid Unlimited
Free Open Source Gratis Unlimited
Pilot Proprietary Gratis Limited
Bronze Proprietary Paid Unlimited
Silver Proprietary Paid Unlimited
Gold Proprietary Paid Unlimited


  1. Users: anyone who uses GitLab regarless of tier.
  2. Customers: users on a paid tier.
  3. Plans: the paid tiers only.
  4. Time-limited tiers: pilots ( and trials (self-hosted).
  5. Subscription: a combination of the paid tiers and the time-limited tiers, for example the trial tier is a subscription but not a plan.
  6. License: open source vs. proprietary, for example moving a feature from a proprietary tier to the open-source tier.
  7. Tier: a combination of the subscription tiers and the open source licensed tiers.
  8. Distribution: self-hosted CE vs. EE, for example you can have a EE distribution but in the Libre tier.
  9. Version: the release of GitLab, for example asking what version a user is on.


In general each of the five self-hosted tiers match the features in the tiers. They have different names for two reasons:

  1. There is not complete feature parity between self-hosted and plans. For example, Starter, Premium, and Ultimate include LDAP Group Sync but Bronze, Silver and Gold do not.
  2. We want to know if a user is using self-hosted or based on a just the tier name to prevent internal and external confusion.

When we need to say what tier a feature is in (for example in our documentation and release post) we use the self-hosted tiers because they tend to contain a superset of the tier features.

Libre, Gratis, and Free

Libre, Gratis, and Free are terms used in the open source community. "Free" is an ambiguous term that can means either free as in "no cost" (e.g. $0 "free as in beer"), free as in "with few or no restrictions" (e.g. "free as in free speech"), or both. "Gratis" is an unambiguous term to mean "no cost" while "Libre" is an unambiguous term to mean "with few no restrictions." Open source software is "libre" in that it is free to inspect, modify, and redistribute. Open source software may or may not be "gratis." Our time-limited tiers are gratis but not open source. Our Free and Libre tiers refer to our open source software that is both free as in speech and as in beer. For more info see the wikipedia article.

Personal vs Group subscriptions subscriptions are added to either a personal namespace or a group namespace. Personal subscriptions apply to a single user while Group subscriptions apply to all users in the Group.


Libre users can use either one of two distributions: Community Edition (CE) and Enterprise Edition (EE). Enterprise Edition can be downloaded, installed, and run without a commercial subscription. In this case it runs using the open source license and only has access to the open source features. In effect, EE without a subscription, and CE have the exact same functionality. The advantage of using EE is that it is much easier to upgrade to a commercial subscription later on. All that's needed is to install a license key to access more features vs needing to re-install a different distribution.

Note: The terms CE & EE refer solely to the software distribution, not to the subscription plan. Never use CE vs. EE as a substitute for versions. Instead, talk about open source users vs. proprietary.

GitLab Trial

Today, we only offer a free trial for self-hosted GitLab. The trial offers all of the features of Gitlab Premium. In the furutre the trial will offer all the features of Ultimate. Users on the Libre (self-hosted) and Free ( plans get access for an unlimited amount of time to a limited set of features. Trial users get access to a full set of features for a limited amount of time (30-days).

License type Features Time Period
Libre & Free Limited (Open source features only) unlimited
Trial Unlimited (access to al Premium features) limited (30 days)

In the future we might introduce a similar concept for We'll call this a pilot to make sure you can tell the delivery mechanism from the tier.

Open source projects on get all Gold features.

The Free plan offers unlimited public and private repos and unlimited contrbutores but has limted features for private repos. Private repos only get access to the open source features. Public projects get access to all the features of Gold free of charge. This is show our appreciation for Open Source projects hosted on

Messaging dos and don'ts

One deck to rule them all


There is one canonical slide deck, known as "The Production Deck" that contains the GitLab narrative and pitch. The prod deck should always be in a state that is ready to present. This is a deck everyone should present from and/or fork from when there is a need to create new content tailored to a specific audience (analysts, events, specific customers, etc.). As such there should never be comments or WIP slides in the Prod deck. Only the pitch deck production engineer (William Chia) has write access to the production environment. Changes, comments, and additions should be made in the staging deck.


To update the Staging deck, create a copy of the slide you want to modify, or add the new slide you want to suggest. Create an issue in the Marketing Issue tracker and label with 'Product Marketing' including a link to your slide and the title. The changes can the be discussed and revised until the slide is ready to be deployed to production.


Slides should go through QA first. This includes

How to deploy a staging slide to production

When a slide has passed QA the slide deck production engineer should copy and paste it into the production deck. The change should be communicated in the #sales slack channel. Additionll enablement should be added to the weekly sales call if necessary.

Competitive Intelligence

Customer Stories

A formal case study produces a polished, finished document. A "customer story" is a shorter, informal story about how a customer solved a particular problem or received a specific benefit. Case studies are usually made up of multiple customer stories for a single customer. Customer stories can also be anonymous. e.g. "A large international financial services company used Gitlab CI/CD to reduce build times from 1 hour to 10 mins."

Today, we don't have a central repository for customer service, but this is a Q1 goal to start building one. For now we are capturing customer stories in an issue. If you have a customer story or anecdote leave a comment on issue 1834.

Customer Case Study Creation


Creating the Customer Case Study:

Kicking off a new case study

To start a new case study process, create a new issue in the Marketing issue tracker and use the "Customer_Story_Kickoff" template.

Explaining the Case Study process to a Customer & Creating the Case Study:

Below is an example email that PMM may send customers to after the AE has introduced them to the customer. The email below will help the customer to get a better sense of what we are asking of them.

Hi X,

It's nice to e-meet you, we'd love to hear more about your journey to GitLab and potentially write a customer story on COMPANY NAME.

Here are the steps that we'd work with you on.

  • 20-30 minute phone call to hear more about your industry, business, and team. (In the call, we would also like to hear more about your decision making process to first choose GitLab and then eventually purchase EE.)
  • Review of the draft customer story
  • Final review of the customer story Then once the customer story is agreed upon by you or someone on your team we will publish it on GitLab's channels.

Please let me know if you're open to kicking off the customer story process on X date

Collecting Metrics:

Possible quantitative metrics that the customer can be asked to share with GitLab include:

The customer case study should then be written by Product Marketing team, and the draft sent to the customer for their input, and approval.

Other sections in the case study can be found on the customer's website or by searching the web - Sidebar summary, The Customer.

Following approval from the customer, the Design team should be sent a doc of the case study to include in the case study design template. The case study can then be published on our website.

Case Study Format:

Headline: The name of the customer and the benefit they gained from implementing our solution

Sidebar Summary: Summarize key points

The Customer: A brief introduction of the customer, not the solution.

The Challenge: What was the customer trying to change or improve. What regulations or market conditions drove the customer to search for a new solution. Share the steps the customer took to solve the problem, including other products and services they investigated.

The Solution: Detail the solution and how it aligns to the customers requirements. Also detail other solutions that GitLab interfaces with. Also include customer quote.

The Results: Detail how GitLab supported the customer to solve their problems. This is where the use of benchmarking metrics such as such as time saved, reduced costs, increased performance etc. are required.

About GitLab: Short paragraph on GitLab - about, solutions etc. Call to action of solutions offered.

Possible Additional Supporting Documents:

Creating Case Study Blog Post:

Refer to the guide available here.

Analyst product categorizations

GitLab is a single application that spans many product categories. Forrester and Gartner define several of these categories and their definition of a space can be useful to determine what important competing products are. Below some relevant categories that GitLab is or will be competing in.

Forrester: Continuous Integration Tools

Forrester: Configuration Management Software For Infrastructure Automation

Gartner: Software Change and Configuration Management Software

Gartner: Continuous Configuration Automation Tools

Gartner: Software Test Automation

Forrester: Modern Application Functional Test Automation Tools

Gartner: Performance Testing

Gartner: Application Release Automation

Forrester: Continuous Delivery and Release Automation

Gartner: Application Performance Monitoring Suites

Gartner: Application Security Testing

Forrester: Application Security Testing

Gartner: Project Portfolio Management

Forrester: Strategic Portfolio Management Tools

Forrester: Portfolio Management For The Tech Management Agenda

Gartner: Enterprise Agile Planning Tools

Forrester: Enterprise Collaborative Work Management

Forrester: Application Life-Cycle Management, Q4 2012

Gartner: Container Management Software

Gartner: Enterprise Application Platform as a Service

Gartner: Data Science Platforms

Partner Marketing

Partner Marketing Objectives

For a list of Strategic Partners, search for "Partnerships" on the Google Drive.

Partner Marketing Activation

Our partner activation framework consists of a series of action items within a high-level issue. When a strategic partnership is signed, Product Marketing will choose the issue template called partner-activation which will trigger notification for all involved in partner activation activities.

For each action item within this issue, a separate issue should be created by the assignee who is responsible for that action item within the allocated timeframe.

The partner should be included on the high level issue so they can see the planned activities and can contribute.

Partner Newsletter Feature

In line with the objective of: Promote existing partnerships to be at top-of-mind for developers, a regular feature in our fortnightly (8th & 22nd) newsletter will promote our partners to our target audience. This feature should be co-authored by the partner.

Possible content:

Suggested Format:


Email potential partner with case for creating content/blog post which will feature in our newsletter. Also request that they include the content in their own newsletter.

Create separate issue for blog post in www-gitlab-com project with blog post label and assign to Content Marketing with the following information:

After Publication: Send to partner a summary of the click-throughs to their website, registration for webinar etc.

Channel Marketing

Channel Marketing Objectives

Reseller Funds Allocation Determination