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: 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
Title: Sr. Content Marketing Manager
Area of focus: GitOps
GitLab handle: @awithers
Slack handle: @ashwithers
Anyone at GitLab can reach out to the content team by tagging @contentteam on Slack.
This is a list of recommended slack channels for the content marketing team.
#content-team-lounge: Where the content team can hang out. This is a public channel.#content: A general discussion channel for all things content, including blog posts, case studies, videos, webcasts, newsletter content, interesting articles, etc#content-updates: A rolling log of new, published content. Once an article, blog post, case study, webinar, video, landing page, etc. is public, add it to this channel with a TL;DR description of the content.#inbound-mktg: The main channel for the Inbound Marketing group that includes content marketing.#marketing: The main channel for the entire marketing group that includes inbound marketing.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.
Content is most effective when it has the right message, to the right audience, at the right time, in the right medium. That's why the content marketing team produces a variety of content types designed to reach different people at different stages of the buyer journey.
At GitLab, everyone can contribute. While the content marketing team produces a large amount of content, they are by no means the only content creators at GitLab. If you would like to contribute content such as blog posts, eBooks, whitepapers, etc, read more about these content types and how to submit them.
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
Blogs can be pitched to the official GitLab blog or published directly on the Unfiltered blog without editorial approval.
Visit the blog handbook to learn more about the blog publishing process.
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
www-gitlab-com project.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.
Any technical GitLab team member is welcome to write a whitepaper and collaborate with the content team. Go to the product stage in the handbook to find the content marketer for your whitepaper topic, or post in the #content slack channel. Whitepapers should be related to specific use cases and support campaigns, when possible.
Examples:
Timeline: 1-4 weeks to plan, research, and draft a whitepaper. Whitepapers created by GitLab team members will follow the internal gated content asset workflow.
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. eBooks should be related to specific use cases and support campaigns, when possible.
Content Marketer workflow
A content team member develops eBook content with input and review from their product marketing counterpart. More technical or instructive eBooks may require more collaboration with product marketing. eBooks follow the internal gated content asset workflow.
Follow the instructions for creating an internal gated asset and start the eBook process by creating an epic using the epic template.
For other GitLab team members: To request an eBook from the content team, feel free to open a content request issue. If you would like to write an eBook, we have an eBook google doc template available for GitLab team members to use with general best practices.
Examples:
Timeline: 1-3 weeks to plan, research, and draft an eBook. 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. Open a design request issue when planning an infographic to 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 continuous integration. 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.
Examples:
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:
## Persona: [Example: Software developer Sacha](https://about.gitlab.com/handbook/marketing/product-marketing/usecase-gtm/ci/#software-developer-sacha)
## Use Case: [Example: Continuous integration](https://about.gitlab.com/handbook/marketing/product-marketing/usecase-gtm/ci/)
## Theme
*Detail the specific angle you are taking on the topic. Why does it matter to this persona and what core messages need to be conveyed?*
## Strategic overview and resources
*Why are we targeting this theme and persona?*
- [Industry analysts](https://about.gitlab.com/handbook/marketing/product-marketing/usecase-gtm/ci/#industry-analyst-resources)
- [Market requirements](https://about.gitlab.com/handbook/marketing/product-marketing/usecase-gtm/ci/#market-requirements)
- [Discovery questions](https://about.gitlab.com/handbook/marketing/product-marketing/usecase-gtm/ci/#discovery-questions)
## Content Audit
1. Link to Path Factory use case track
1. Link to blog topic tag
1. Link to resources page filtered by topic
1. Link to topic page
1. Link to solutions page
1. Link to related /stages-devops-lifecycle/ pages
## PathFactory track
1. What content exists
1. What content needs to be updated?
1. What content is missing?
## SEO
*List the primary and secondary keywords for this content set.*
*Resources*
- [SEO content manual](https://docs.google.com/document/d/1ZPMW2ypTy2RssojVsulEkk1O_mLuM26liUU-Qoj-ACE/edit?usp=sharing)
- [AlsoAsked.com](https://alsoasked.com/)
- [SEMrush](https://www.semrush.com/)
- [Answer The Public](https://answerthepublic.com/)
## Content set
*What content are you planning to create/update and why?*
- Topic maturity assessment -- Following the template of the [DevSecOps maturity assessment](https://about.gitlab.com/resources/devsecops-methodology-assessment/), we'll create a module for each topic. Ideally, this will be interactive for the user and then align with the buyer's journey to provide content according to where they land on the assessment.
- eBook
1. Focus/Title
- Web article
1. Focus/Title
2.
3.
4.
5.
- Topic page
1. Review/update/add - keep your topic page on your radar to continuously iterate.
## Timeline
*List content with phases and due dates*
- Maturity assessment
1. Due date will likely be determined by design planning timeline.
- eBook
1. Due date
- Web articles
1. Due date
2.
3.
4.
5.
- Topic page
1. How often will you update (i.e. 2/month, etc)
**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)
