Inbound Marketing Handbook

Inbound Marketing Overview

Inbound Marketing exists to build, grow, and protect the business value created at the top of GitLab’s marketing funnel. Through organic engagement with our content, both on the GitLab website and through other channels, we work to establish mindshare and relationships with existing and potential GitLab customers.

Measuring Progress

Website Pageviews

Cumulatively increase pageviews on the GitLab Marketing Website by 20% year-over-year.

GitLab team members can view the internal dashboard

Inbound Inquiries

SSoT: GitLab team members can view the live internal dashboard for inquiries and trials

Definition

An inquiry is defined as:

• a unique email address
• submitted within the past 180 days
• From one of the following Sisense sources:
  • Trial - Enterprise
  • Trial - GitLab.com
  • Inbound

Planning

Inbound Marketing planning activities are organized in this epic. We currently plan on an annual and quarterly cadence, and are moving toward planning two quarters in advance for H2 FY22.

Objectives & Key Results

Inbound Marketing sets quarterly OKRs, and also maintains a backlog of future OKR candidates for consideration.

Q2 FY22 Inbound Marketing OKRs

Past OKRs

• Q1FY22 OKRs
• CANDIDATES Q2FY22

Brand and Design Issue Templates

The brand and design team is now the Brand Activation team under Corporate Marketing. Please see their Handbook page for requesting support.

Inbound Marketing Issue Templates

• Request a redirect
• Request keyword research

Video Issue Templates

• Requesting a new video
  • Use this template only for requesting new videos that haven’t been produced yet
  • If you are looking for edits to existing content that has been filmed, use the video editing request
  • Process documentation link placeholder
• Requesting a video edit
  • Use this template for editing existing content that has been filmed
  • DO NOT use this template for new videos
  • Process documentation link placeholder
• Requesting a video upload
  • Process documetation link placeholder

How we use GitLab

Boards

Overarching Inbound Marketing Boards

Triage Board

Triage Board

• GOAL: Weed out issues that superfluous or don’t contain extra information
• ACTIONS: Move to either
  • Move to either mktg-status:PLAN which puts into the Sprint cycle or;
  • [mktg-status: blocked] and comment why it is being blocked

Sprint Board

Sprint Board

• GOAL: Assign issues to milestones to be worked on then based on due dates, weights, priorities, resources
• ACTIONS:

HANDOFF: This is where the handoff to Inbound Marketing Teams takes place to run their processes

• Move to a specific week taking into consideration the above
  • Backlog if:
    • It doesn’t fit into current goals or priorities
    • We don’t have the time or resources currently
    • It is just a cool idea (some of these may be labeled for future review for upcoming strategies & tactics)
  • Comment why it is backlogged
  • Never backlog PR issues without prior discussion

Inbound Marketing Leads Overview

Inbound Marketing Leads Overview

• GOAL: An overview of the work on each of the Inbound Marketing Teams during the current Milestone Sprint
• ACTIONS:
  • Review and help prioritize

Labels

Labels are important because they help populate the boards and make them work. The minimum viable usage is using mktg-inbound and using a  scoped mktg-status label as shown below.

Meanings and usage

Team Labels

• mktg-inbound
  • Means it is for the Inbound Marketing Team
  • Used to help pull in boards
  • Is not a label to denote the status of an issue
  • [Team Labels within Inbound Marketing] mktg-search, mktg-content
    • Denotes it could be part of a Inbound Marketing Group scope
    • Is not a label to denote the status of an issue
    • [Sub-team Labels] content marketing, editorial, digital-production, UX-Design, Web-Dev
      • The sub-teams within Inbound Marketing Teams
      • Is not a label to denote the status of an issue

Status Labels

• mktg-status::triage
  • Triage is for requests that come from outside Inbound Marketing
  • Is used to denote the status of an issue as being reviewed to go into the working pipeline
  • Does not denote the timeline it will be worked on
• mktg-status::plan
  • Is used to denote the status of an issue as having being reviewed for all details needed
  • No milestone nor assignee attached to the issue
  • Does not denote the timeline it will be worked on
• mktg-status::WIP
  • Is used to donate that an issue has been assigned to a sprint and assignee and will be worked on
    • Minimum Viable Usage includes using the following:
      • Milestone Fri: MONTH DAY
      • Weight
        • A weight of one is half a day
        • As weights start to get bigger than 4, we recommend chunking it down further
      • One Asignee
        • We actively encourage only assigning one person to an issue. You may tag other affected parties within the issue itself by using @username within the issue thread.
• mktg-status::blocked
  • Is used to denote the status of an issue as not having enough information to proceed
  • Does not denote the timeline it will be worked on
  • This should ONLY be used in the Triage process or if an issue becomes so blocked it needs to be re-scheduled.
    • If an issue is blocked it goes back into the Triage process and is scheduled from there
• mktg-status::review
  • Is used to denote the status of an issue as in the peer-review process.
  • Does not denote the timeline it will be worked on

Projects

Additional Labels

• IM-Support
  • Denotes if this is support provided to another team outside of Inbound Marketing
  • Will be used to help quickly view how many issues Inbound Marketing supported each year to provide as references for budget and resources requests.
• IM-Review-Future
  • Will be reviewed by InboundMarketing for potential future strategy

Milestones

Meanings and usage

• Fri: MONTH DAY
  • Denotes which week an issue will be worked on
  • Worked on = will be broken down into smaller Issues or Issue will be completed and closed
• Inbound Marketing Backlog
  • Denotes that this not fit into current goals, time, or resources - can be reviewed later for informing future goals
  • Does NOT mean the issue request is cancelled
• Case Study
  • ONLY for Case Studies
  • Created because they span multiple months and teams and timelines cannot be accurately assessed until towards the end
  • New issues with sprint milestones will be made for publishing the case study
• INFORMATION GATHERING
  • Denotes issues used to gather information, but do not have set deliverables

Epics

This is how we use Epics to organize our projects. We aim to include the highest level information at the top level and specific information in lower-level epics. This is to keep a SSoT and avoid duplicative placement of information that would need to be updated in multiple places

• Top Level Epic
  • Quarterly OKRs
    • OKR structure iteration
  • Links to the yearly strategy that contains themes
• Second Tier Epic
  • Stores the team or channel strategy/improvements broken into phases
  • Includes
    • Current state
    • Stakeholders
    • Metrics - Baseline and Target
    • Desired state - Key audience + Intent and Key company goals
    • Improvement Roadmap - broken out by quarter if it will cross multiple
    • Phases - per quarter and includes:
      • The Problem
      • The Solution
      • Why this Effort
• Third Tier Epics
  • Epic per phase - one epic per phase
  • Contains:
  • Scope of project
  • Roles & Responsibilities Chart if different than the parent epic
  • Relevant Documents
  • High-level epic production only - All production for individual issues should be placed in those issues to avoid redundancy
• Fourth Tier Epics
  • MVCs for project - one epic per MVC
  • Contains:
    • Scope of MVC
    • Relevant Documents
    • High-level epic production only - All production for individual issues should be placed in those issues to avoid redundanc
• Fifth Tier Epics
  • Production issues

Issues

Issue Types

This is how we work with Issues and their scope

External

(outside of Inbound Marketing) REQUEST ONLY ISSUE

• This is for complicated projects (example: campaign).
• This type of Issue is submitted by a team OUTSIDE of Inbound Marketing.
• This serves as a brief to us.
• For each type of request we have a corresponding Request [Type] Issue Template that should be filled out to begin the process.
  • Requesting Support
• Actions taken on issue:
  • Reviewed for all information and label changed to mktg-status::PLAN if all there or mktg-status::blocked if not all info is there
  • Assigned to a team member to execute on
  • Assigned to a Sprint week to be worked on (worked on= broken down into Production Issues)
  • Issue is added to a child Epic and execution issues are made for creating
  • Assignee will comment and close the Request Issue and deliver the work in the Child Epic

REQUEST AND PRODUCTION ISSUE

• This is for a simple ask (example: single asset)
• This type of Issue is submitted by a team outside of Inbound Marketing and will contain relevant information for the project AND;
• Execution Items/Production Checklists for the Inbound Marketing Teams.
• For each type of request we have a corresponding Request [Type] Issue Template that should be filled out to begin the process.
• Actions taken on issue:
  • Reviewed for all information and label changed to mktg-status::PLAN if all there or mktg-status::blocked if not all info is there
  • Assigned to a team member to execute on
  • Assigned to a Sprint week to be worked on (worked on = deliverables created)
  • Assignee will follow the production checklist and deliver work within the original Issue

Internal

(inside of Inbound Marketing)

PRODUCTION ISSUE

• This is an Issue we use internally to create and execute on the request/brief.
• These are only used by people inside of Inbound Marketing
• For each type of request we have a corresponding Production [Type] Issue Template that should be filled out to begin the process.
• The teams will deliver the individual pieces to these Issues, but not the completed ask. That should be delivered into the Child Epic created

Issue Templates

External

(outside of Inbound Marketing):

Issue Author

• Pick template based on Handbook directions
  • Template tags will be automatically added:
    • mktg-inbound
    • mktg-status::triage
    • The relevant Group Label: design, content marketing, or mktg-analytics
    • IM-Support
  • Template contains specific information to help fill out including directions for picking a due date
  • Template has auto-assignees
  • Links to Handbook page for additional information

Internal

(inside of Inbound Marketing):

Assignees of Issues:

• Pick template for breakout of brief
• Template tags:
  • Keep existing above EXCEPT if we start the project then we remove MG-Support
  • Add your team’s process tags
• If the ask (External brief Issue) requires one ask:
  • Re-assign as need, make sure it is in a sprint week and follow documented processes
• If the ask (External brief Issue) requires more than one ask:
  • Create an Epic to hold project
  • Copy and paste markdown into Epic Description and use header: “External Brief”
  • Associate Issue with Epic
  • Comment Close Issue that the project epic has been created
  • Build out necessary Issues in project, Associate with Epic, assign Issues and update Epic Description as needed with additional brief information

Process

Video Playlists

In an effort to make async communication and collaboration as effective as possible, below are relevant playlists created by the Inbound Marketing teams. We welcome suggestions for additional playlists and videos that would help your team. Please request in our slack channel

• Weekly Inbound Marketing Recap and Demo
• SEO Update
• Marketing Metrics
• Digital Experience Playlist
• Global Content Updates

Budget

Budget Management

• Allocadia is our SSoT for the budget
• The budget is quarterized per team

Vendor Management

Vendor recruitment

If you know of a brand or digital vendor, whether “an agency of one” (aka freelancer) or agency, please share the contact with your manager for further consideration.

Vendor on-boarding

1. Manager creates Access Request issue for relevant GitLab projects and Slack channels
2. Manager creates Intro to GitLab issue
3. Intro call with Manager, Vendor, and Vendor Buddy to set expectations, outline workflow, share relevant handbook links, and introduce first project(s).
4. Vendor completes Intro to GitLab issue, including standard and design and or dev on-boarding tasks (depending on vendor type).
5. Help any developer vendors if they have trouble setting up their code environment and please familiarize them with our codebase.
6. Questions about on-boarding, please see handbook, your manager, and or thge #marketing_brand_contractor_onboarding channel.

Vendor project management

Team

• Assigning Issues to Vendors
  • Assign the vendor and team member who will be the vendor’s buddy.
  • Ensure following labels are on the issue:
    • vendor
  • Assign the issue to a milestone, as appropriate.
  • Confirm the issue appears on the vendor board.
  • Capture opportunities to improve vendor management in the vendor management epic.

Vendor buddy

• Managing Vendor Work
  • Ensure you and vendor are assigned to the issue.
  • Check-in regularly to ensure progress and clear blockers.
  • Ensure projects to which you’re assigned are maintained on the vendor board, just as you maintain your own projects.
  • Communicate with vendor in issues and or the vendor-contract slack channel, #brand-contractors, per GitLab’s async communication best practices. Also be aware GitLab’s async model may be new to contractors. Be open to synchronous meetings as vendors acclimate to async work.
  • Meet standard GitLab and Brand and Digital work practices, including open and inclusive design and weekly status updates.
  • Review vendor deliverables for quality assurance.
• Addressing Concerns
  • Should issues arise, provide vendors feedback in private. Be specific on the concern, how it can be resolved, and set a date for when it will be resolved.
  • Share critical concerns or patterns of issues with your manager.
  • Immediately report urgent concerns to your manager, such as significant project delays or poor quality of work.

Vendor invoicing, payment and reporting

Vendor buddy

• Ensure you know enough about the invoicing process to assist when directing invoicing questions from the vendor to the appropriate party.
  • Please don’t drop the ball, we want vendors to be happy and get paid.
  • Please follow any questions from start to finish to keep things moving along.
    • Ex: “I’m having trouble with Coupa, who can help me?” (Accounts Payable Team)
    • Ex: “Do I need a purchase order number for my invoice?”

Managers

• Vendor contracts - Negotiate and execute vendor contracts, with Director’s approval. Goals are to maximize value delivered within our allocated vendor budget.
• Invoicing - Ensure vendors:
  • Successfully onboards themselves in Coupa
  • Adhere to GitLab’s invoicing standards
  • Invoice all remaining hours by the end of month
• Monthly vendor work report
  • Provide director with end of month report of vendor projects, including projects in progress and those completed within the past month.

Director

• Approve invoices
  • Approve invoices in Coupa throughout the month and at end of month.
  • Validate vendor invoices and deliverables with Brand and Digital managers.
  • Ensure projects are billed to the appropriate budgets.
• Approve contracts
  • Engage vendors in alignment with brand and business objectives.
  • Manage overall budget spend.
• Monthly vendor work report
  • Add spend to Monthly Vendor Work Report and distribute to stakeholders for awareness. Stakeholders include Inbound leadership, Finance, and Marketing team leads working with vendors.

Return to the main Marketing Handbook.

View page source - Edit this page - please contribute.