The Global Content team is responsible for strategic and resourceful content creation. The goal of the content marketing team is to drive inbound and organic traffic with SEO by optimizing webpages using keyword clusters, gap analysis research, target keyword updates, and aligning with reader intent. The team provides readers with end-to-end content experiences in order to garner trust, create source credibility, and generate customer engagement.
The content team is using SEO-infused data to create quality definitions, web articles, and topic know-how in order to enhance the existing webpages, add more pages, and drive more traffic to the site. Working closely with the inbound marketing team, the content team has created a content strategy to ensure that people searching for topics like open source, version control, code management, CI/CD, and DevSecOps will find the best possible resources on GitLab’s website.
The content team is specifically addressing the developer audience and those who are committed to learning more about a particular software workflow, application, standard, or methodology. Our content is created to be a trusted source for Sasha, the software developer who is looking to advance their career by learning new skills.
The content marketer’s goal is to steer readers through the buyer’s journey – capture organic traffic through awareness level content and engage readers by providing links to solutions-based knowledge. The content team relies heavily on user personas and use cases, developed by the product marketing team, in order to understand who our readers are and how best to support them in their software development journey. Personas, along with SEO research, help us to navigate content strategies.
We use content pillars and topic clusters to organize and plan our work. Pillars are definied within epics on a quarterly basis and work is broken out into milestones and issues. We use content pillars to plan our work so we can provide great digital experiences to audiences. The content team aligns to themes to ensure we are executing strategically and meeting business goals. Pillars allow us to narrow in on a specific topic and audience, while topic clusters help to inform us of what search terms people are using within that subject. Each content marketer focuses on a specific part of the software development lifecycle, then creates content clusters to support the topic.
Topic clusters are pieces of content that share a common subject or subtopic and are used to enhance organic search engine results. A topic cluster begins with a pillar page, consisting of the prominent subject matter. The content team, along with detailed input from inbound marketing, works to design insightful topic clusters. Our Topics pages act as pillar pages. Web articles, also called cluster pages, will support and enhance the topics pages, using primary keyword placement, search volume research, and semantic and secondary keywords. Our topic clusters are listed below.
Existing topic clusters:
A content pillar is a go to market content strategy that is aligned to a high-level theme executed via content sets. Often, content pillars are defined based on value drivers and customer use cases in order to support go to market strategy. For example, "Just commit to application modernization" is a content pillar about improving application infrastructure in order to deploy faster. Within this pillar, many topics can be explored (CI/CD, cloud native, DevOps automation, etc.) and the story can be adapted to target different personas or verticals. Each set created should produce an end-to-end content experience (awareness to decision) for our audience.
A content set is the collection of work that is be created each quarter. It covers all three stages of the buyers journey. The content marketers are responsible for awareness level and some consideration level content, and the product marketers cover the purchase and some consideration content.
Here's an example of what's included in a content set:
| Stage | Content Type | DRI |
|---|---|---|
| Awareness | Thought leadership blog post | Content marketing |
| Awareness | Topic page | Content marketing |
| Awareness | Web article | Content marketing |
| Awareness | Resource | Content marketing |
| Consideration | Case study | Content marketing |
| Consideration | Technical blog post | Content marketing |
| Consideration | Whitepaper | Product & technical marketing |
| Consideration | Solution page | Content & product marketing |
| Consideration | Webcast | Product & technical marketing |
| Purchase | Demo | Technical marketing |
| Purchase | Data sheet | Product marketing |
Sources:
Title: Sr. Manager, Global Content
GitLab handle: @erica
Slack handle: @erica
Title: Manager, Content Marketing
GitLab handle: @bmatturro
Slack handle: @Brein
Title: Sr. Content Marketing Manager
Area of focus: Dev, Version control and collaboration
GitLab handle: @suripatel
Slack handle: @suri
Title: Sr. Content Marketing Manager
Area of focus: Sec, DevSecOps
GitLab handle: @vsilverthorne
Slack handle: @ValSilver
Title: Content Marketing Manager
Area of focus: Ops, CI/CD
GitLab handle: @cbuchanan
Slack handle: @chrissie
Pillar strategy is planned annually and reviewed quarterly. Content sets are planned quarterly and reviewed monthly. When planning, we follow the 80/20 rule: 80% of capacity is planned leaving 20% unplanned to react to last minute opportunities.
Gated assets are created and written by the content team. The process will vary, however the content strategy and timeline should be consistent. Several other teams are involved in the planning process for whitepapers and eBooks. To learn more about the campaign and marketing strategy, the Marketing Programs Management section) of the handbook has an overview.
All gated assets should have an epic. There are many teams involved in creating the final product and an epic helps keep al realted issues together. The epic is the single source of truth for workflow deadlines. Gated assets include eBooks, whitepapers, demos, and webcasts. All gated assets can be found on the Resources page.
Visit the Gated Content page for detailed instructions on how to structure your epic, issues, and timeline.
A post on the GitLab blog is used during the Awareness or Consideration stage of the buyer's journey. A blog post can educate, entertain, tell a story, take an opinionated stance, etc. (See: Attributes of a successful blog post.) A blog post is dated, so it only reflects thoughts, ideas, and processes from a specific period of time. For communicating long-term/evergreen ideas or processes, consider using a topic page or web article instead.
Content Marketer workflow
A blog can and should be repurposed as a web article/cluster page if the content is evergreen and awareness stage. The blog should also be older than six months and not GitLab-centric.
Blog repurpose workflow
A whitepaper is a technical and focused topic study intended to educate a prospective buyer during the Consideration or Purchase stages of a campaign. The whitepaper offers a problem and solution instance in a granular, technical tone. The content team member should collaborate closely with their product marketing counterpart when researching and writing the asset so that the content reaches appropriate technical standards for the intended audience.
Examples:
Timeline: 1-4 weeks to plan, research, and draft a whitepaper. Use the content resource request template for planning with team members and to define a specific deadline. All whitepapers should have a launch date on the editorial calendar.
Deliverables:
An eBook tends to be broader in scope than a whitepaper and provides a clear definition of the topic, along with various industry standard best practices. eBooks typically provide awareness-level content, but can dive deeper into GitLab if it's intended for late-stage consumption. These are identified in the design template as Beginner, Intermediate, or Advanced ebooks.
The content team member takes the lead on developing eBook content, with input and review from their product marketing counterpart. More technical or instructive eBooks might require more collaboration with product marketing. Use this content template to write the eBook. Use this content request template for the eBook content issue.
Examples:
Timeline: 1-3 weeks to plan, research, and draft an eBook. Use the design resource request template for planning with team members and to define a specific deadline. All eBooks should have a launch date on the editorial calendar.
Deliverables:
An infographic is an illustrated overview of a topic or process, and is typically an ungated asset. Infographics should tell a story using data, diagrams, and text. It can be used to discuss industry trends, relate insights, or explain different stages of a project. When planning an infographic, it's important to meet with the design DRI before writing the content for the asset. Together, figure out a structure for the graphic, and ask the design DRI for recommended copy lengths.
Example:
A topic page is a high-level explanatory "pillar" page dedicated to a specific topic, such as version control, application security, or cloud native. Topic pages should explain what the subject is, why it is important, and explain the basic concepts of the subject. Topic pages should include links to additional related resources, such as blogs, web articles, videos, and case studies, as well as at least one CTA to a gated asset.
Web articles are educational, informational content, designed to support topic pages using keywords and search terms. They are similar to blogs in length, but differ in that they are not dated and the content is evergreen (see more about blog posts). Web articles should be linked on one or more topic pages, and should serve as a deep-dive into a specific sub-topic. Web articles are created in accordance with SEO research and campaign goals that are listed in the topics clusters spreadsheets. Complete the SEO web article template when creating a new piece of content.
Case studies are in-depth customer stories that provide insight as to how GitLab has resolved significant software workflow problems for a company. The case study tells the story using quotes from customer interviews and straightforward metrics that broadly show the impact of adopting GitLab.
Case studies are created in partnership with the customer reference team. The customer reference team has a process in place for how they add new references and provide a list of customer value drivers. The content team is responsible for writing the case study asset using this template, publishing the case study to the website, adding the customer logo to the customer logo grid, and ensuring that the case study goes through proper social media and newsletter steps.
Examples:
**Epic title:** [asset type] Working Title - Launch date
## Launch date: TBD
* Content DRI:
* MPM DRI:
### Deadlines
* [ ] 2020-XX-XX Open copy issue and complete asset brief (-27 business days from launch)
* [ ] 2020-XX-XX Landing page copy due (-27 business days from launch)
* [ ] 2020-XX-XX Final copy due (-15 business days from launch)
* [ ] 2020-XX-XX Final design due (-5 business days from launch)
* [ ] 2020-XX-XX MR ready to launch (-3 business days from launch)
* [ ] 2020-XX-XX Asset added to pathfactory (-3 business days from launch)
