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.
|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|
In general each of the five self-hosted tiers match the features in the GitLab.com tiers. They have different names for two reasons:
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 GitLab.com tier features.
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.
GitLab.com 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.
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 (GitLab.com) 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 GitLab.com. We'll call this a pilot to make sure you can tell the delivery mechanism from the tier.
The GitLab.com 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 GitLab.com.
Enterprise Edition Starter,
Enterprise Edition Premium,
Enterprise Edition Ultimate,
EEU. These have all been deprecated.
Enterprise Edition, or
EEto refer to tiers.
Premium Edition- Starter, Premium, and Ultimate are tiers, not "editions" of the software.
Don't use "enterprise" as a modifier for tiers such as
Enterprise Premium, or
EEto refer to our software distributions. Encourage customers to use the EE distribution since it provides the least painful upgrade path if/when users discover they need commercial features.
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
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.
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.
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.
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
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.
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:
Refer to the guide available here.
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.
For a list of Strategic Partners, search for "Partnerships" on the Google Drive.
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.
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.
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.