Welcome to the GitLab Marketing Handbook

The GitLab Marketing team includes four functional groups: Demand Generation, Developer Relations, Design, & Product Marketing

On this page

Marketing Handbooks

GitLab Marketing Strategy

We GitLab

Marketing Team Purpose

The GitLab Marketing team is here to do the following:

We think GitLab (.com, CE, and EE) can help developers, designers, IT workers, marketers, and everyone in between improve collaboration.

Focus for Q3 and Q4

Goal: Ensure we hit company goals set forth by the board for Q3 and Q4 including MQLs, SQLs, and SQL value.

Goal: Track and increase conversion of CE and .com customers to EE.

Goal: Build a developer relations and community organization that makes it easy to contribute, give feedback, and get education about GitLab.

Goal: Begin to message the product as an end-to-end developer lifecycle solution. This video is a good overview of this product messaging we are moving towards.

For a more granular look at what individuals on the marketing team are focusing on, take a look at the Marketing Team OKR’s below.

To support these goals, we plan to hire the people outlined in our hiring plan during Q3 and Q4 of 2016. Job descriptions are linked from the hiring plan for each role to better understand how each role supports the goals of the marketing team and company.

The focus for each functional group is described below.

How we think about marketing a developer product

A common misconception is that developer marketing is showing up at events and giving out free t-shirts and stickers. While true, developers are humans and people like free t-shirts it is not and cannot be the only method to your developer marketing strategy, it's a whole lot more.

"But how do we market to developers?" is a question I've seen asked multiple times at multiple organizations. Every company that's building tools for developers has at some point struggled on how to properly market to their target audience. I've seen it at large organizations, I've seen it at small organizations, and we've all seen product messaging doesn't quite fit what the product actually does. Often times, that's due to a disconnect between marketing and engineering/product and/or the marketing team not understanding how to message a developer product. While people are quick to assume negative intentions of the marketing team, generally that isn't the case. It comes down to messaging and communication between marketing and your engineering/product team. Developers are awesome. Go talk to them.

Is it hard to market to developers? No, however, there's a big focus on truth in marketing, getting a developer help fast when they need it, developer education, community, and making sure that your marketing doesn't over-promise what the product is capable of doing.

The team has to balance how you market a developer product with the expectations of the developer using that product. For example, most users of a developer tool will not expect an email from a demand generation team or BDR team and they certainly will not expect a phone call.

So what do they expect? Developers will expect education, help getting started, tutorials, partner integrations that make their lives easier, and truth in marketing. Developers want truth in marketing, they want proper education, they want integrations that help them, and they want the marketing team to kind of stay out of the way while quietly sprinkling helpful information around the areas that they are interested in.

Some forums that developers use to get information are StackOverflow, Hacker News, Reddit, Twitter, GitLab Documentation, GitHub, a basic Google search, and all of these channels should be taken into account when thinking about how to market a developer product. Where possible, try to offer community support via these forums. Be responsive.

For an event strategy, you need to not only think "how do I bring people together in a room who are using my product" but also "how do I get feedback from that room" or "how do I make sure that conversations are happening between GitLab team members and GitLab community members?". Use your event presence to talk to people who love your product. Give engaging talks and make it easy to give feedback. "How do I make it clear that feedback is appreciated?". You do that through saying, "Hey, I'd like feedback on this." Sometimes you don't even have to say it and, because the developer community is such an open and honest one in most cases, feedback is easier to get. Make it easy to provide feedback, make it easy to become part of the community, make it easy to contribute and people and developers will. Developer roundtables are awesome. You need a room, some developers using your product and someone to take notes.

For a content strategy, much of the same applies. Education, tutorials, and making it really easy to get started through blog posts, video, screencasts, office hours, webinars, etc.

In addition to the above mentioned tactics, good developer marketing strategy includes a great product. If you have a great product, the job of marketing is much easier. Constant product and feature releases are one of the best marketing tools. We are lucky that GitLab releases on the twenty-second of every month and has since 2011. This show of momentum makes it much easier to market to a developer when it's not stagnant.

In product releases, when your users can see that feedback from the community is taken seriously and put back into the product, it says "we take our community seriously." Listen to the feedback, make it easy to give feedback via issue trackers, Twitter, and/or Support and if it makes sense for the rest of the community to make a requested update to the product, do it.

How we think about marketing an open source product with a paid version

Marketing an open source product makes it so that you have to always think about your contributors and community. The flip-side of marketing an open source product is that we’re also creating a paid product that’s based off the open source product. We have to make sure we are good stewards of the open source project while also making money off of the paid edition, GitLab Enterprise Edition.

The balance can be tricky but if you pay attention to detail, never forget your community, always make it easy to contribute while also marketing your enterprise product to only the people who can use it, then you should be okay.

There’s a unique challenge that comes with marketing an open source product when there is also a paid version. The community is important and you must always make sure that your contributors and community surrounding your open source project do not feel at odds with your paid project. Only include features in your paid product that are tailored for large organizations and save the features that everyone can use for your open source free offering.

Your marketing takes a two-fold approach when you're working with an enterprise version of an open source product. One approach doesn’t exclude the other. If you’re someone at an enterprise company that we are marketing to for a paid product, you’re a part of our community but if you’re a part of our community, you’re not necessarily a part of our enterprise marketing strategy.

For example, a developer using GitLab on an individual project or a small team is part of the community. A contributor who contributes a feature back to GitLab CE is part of the community. If those people also happen to work at a large fortune 500 company, global 2000 company, a company with any large amount of revenue, or a large development team, that’s where we begin to market our paid version of GitLab.

We try to not market through spammy email or cold-calling people on the phone, but instead in a more thoughtful way. Our marketing strategy also includes field marketing, content marketing, email marketing, public relations, analyst relations, online marketing, and more to get the right developer resources in front of the right enterprise segment of our community.

Top down and bottom up marketing for developer products

When you’re looking at marketing in the enterprise of a developer product, your strategy should be both bottom up and top down.

Bottom up marketing includes independent developers working with a team on a project within a large organization. Make it easy and enjoyable to use GitLab internally. Make it so that GitLab is the obvious choice for their development needs.

Top down marketing includes targeting the decision maker at an enterprise company. Start with buyer persona research to determine who that decision maker role is at each size company. Work to understand the buying process for your product. Provide the resources needed for that decision maker to decide "hey this is the right product" via pricing comparisons, security information, product fit, and any other buyer reasons you identify in your buyer persona research.

For your top down strategy, first answer these two questions:

1) Who is the buyer?

2) Why did this buyer select your product?

You can go deeper into these questions by company size and industry as buyer and reasons change at different scale and function, but these 2 questions should get you started.

The message targeting for the top down strategy will be different from the bottom up messaging. The messaging is still focused on community, creating a great product, and contributing back to the product; however, it will be more focused on increased productivity of your development teams, lower pricing for a better product, security, team management, or any of the reasons you discover for buying in your research.

Top down marketing and bottom up marketing meet in the middle at the product. Your product must be rock solid. Product excellence is a key part of developer marketing strategy in the enterprise.

We are fortunate that our product excellence stands on its own. Through a strong product and engineer team, amazing community feedback, community contributions, and a supportive sales team, our product excellence is our best marketing tool.

Marketing Team Functional Groups

Our Marketing team is split into four key functional groups, which are equally important for the success of GitLab:

Marketing Production

Marketing OKR Overview

Our team and the demands on marketing are growing quickly. In order to align our goals with company goals as well as prioritize what we are working on, OKRs help us to maintain structure. Of course, not everything can be captured in one Google Sheet but this helps us all to know what we consider our goals as a team to be.

Each member of the marketing team is responsible for 3 Objectives and 3 Key Results for each objective.

To find the GitLab Marketing Team's OKRs, search the company Google Drive for "Marketing OKRs - Quarterly".

Team OKRs


Hiring Plan

Meetings and structure

These are just the required meetings for team members and managers. Of course, meetings are encouraged when it expedites a project or problem solving among members, so the team and company. Don't be afraid to say "Hey, can we hangout?" if you need help with something.

Weekly 1:1 (New hire: First month - managers with all direct reports)

Meeting goal: For manager to help new team member onboard quickly.

Run time: 30 minutes

All managers should have a weekly 1:1 with their direct reports in the first month of employment, starting with the first day of employment where possible.

The first meeting should run as follows:

The agenda of the following 1:1s should be the same as the recurring Bi-weekly 1:1s with time set aside to answer any questions about onboarding.

From the second month on, all managers should have twice monthly (bi-weekly) meetings with all of his or her direct reports.

Weekly 1:1 (All directors with CMO)

Meeting goal: For CMO to provide direction, help prioritize and receive feedback from all directors.

Run time: 30 minutes

All directors should have weekly meetings with the CMO.

The meeting should run as follows:

Bi-weekly 1:1 (Managers with all direct reports)

Meeting goal: For manager to remove roadblocks and help prioritize so team member can be effective.

Run time: 30 minutes

All managers should have twice monthly (bi-weekly) meetings with all of his or her direct reports.

The meeting should run as follows:

Quarterly 1:1 (All members of Marketing Team with CMO)

Meeting goal: For CMO to help with any questions and career path discussion.

Run time: 30 minutes

All members of the marketing team who are not direct reports should meet with their executive management (CMO) once every quarter. If questions or concerns arise, please don't hesitate to reach out directly for an impromptu discussion via email or chat.

The meeting should run as follows:

Monthly Marketing Townhall

Meeting goal: For the entire company to gain insight into what the Marketing team is focusing on.

Run time: 45 minutes

The Monthly Marketing Townhall is open to the entire company for questions, ideas, and feedback. If you'd like to be added to this meeting, please contact anyone on the marketing team to be added to the invite.

To find the agenda for the bi-weekly marketing meeting, search the company Google Drive folder for "Monthly Marketing Townhall Agenda"

The meeting should run as follows:

Monday & Wednesday Dinosaur Party

Meeting goal: Dinosaur Party! (and also make sure we're all working together effectively)

Run time: 10-15 minutes

The Monday and Wednesday Dinosaur Party is where the entire team meets for 10-15 minutes immediately following the sales team call to discuss what we're all working on and to get help with any questions. There is an agenda for this meeting, but it also should be an open forum.

The meeting should run as follows:

To find the Dinosaur Sticker leaderboard, search the company Google Drive for "Dinosaurs are awesome."

Quarterly Marketing Summit

Meeting goal: Planning for the upcoming quarter

Run time: Full Day

CMO builds agenda and assigns ownership for each session.

The meeting should run as follows:

Marketing team SLAs (Service Level Agreements)

When working remotely in a fast-paced organization, it is important for a team to agree on a few basic service level agreements on how we would like to work together. With any of these, things can come up that make it not possible to meet the SLAs, but we all agree to use best effort when possible.

Marketing Handbook Updates

Anything that is a process in marketing should be documented in the Marketing Handbook.

How to contact marketing

Chat Marketing channels

We use our chat internally as a communication tool. The marketing channels are as follows:

Marketing email alias list