Why we exist
We take a customer-centric approach to educating Buyers on how GitLab, The One DevOps Platform, solves their problems.
Where we’re going
A future where everyone can contribute, consumers become contributors and we greatly increase the rate of human progress.
What we do
We drive continual improvement to GitLab’s user journeys and conversion funnel.
| Search, Nav, Support Group | Product Marketing Group | Conversion Group | Corporate Marketing Group |
|---|---|---|---|
| Focus Awareness & Consideration - Navigation - Footer - Search Bar & Results - No Search Results - 404 page - Support - Get Help - Sales - Analysts - Update - AB Testing |
Focus Consideration & Evaluation - Features - Solutions - Use Cases - Get Started - DevOps Lifecycle - Customer Case Studies - Blog - Lightning Strikes - AB Testing |
Focus Conversion & Purchase - Homepage - Pricing - Why GitLab - Install - Demo - Ecommerce / No Touch - Path to purchase - User/Buyer Journeys - 3rd Party Marketplace - AB Testing |
Focus Loyalty & Advocacy - Partners - Events - Jobs - Learn - Community - All Remote - Company |
| Metrics Increased engagement - Lower bounce rate - Increased pages/session - Increased time on site |
Metrics Click through from focus pages to: - Pricing Page - Free Trial |
Metrics Conversion rate past key pages: - Pricing Page - Free Trial |
Metrics Increased engagement - Lower bounce rate - Increased pages/session - Increased time on site |
| Product Manager - Filza Qureshi |
Product Manager - Filza Qureshi |
Product Manager - Filza Qureshi |
Product Manager - Filza Qureshi |
| Engineering Manager - Lauren Barker, ReadMe |
Engineering Manager - Justin Vetter |
Engineering Manager - Justin Vetter |
Engineering Manager - Lauren Barker, ReadMe |
| Product Design - Carrie Tsang |
Product Design - Tina Lise Ng |
Product Design - Jess Halloran |
Product Design - Jess Halloran - Tina Lise Ng |
| Engineering - Laura Duggan (Lead), ReadMe - Miracle Banks - Miguel Duque - John Arias |
Engineering - Nathan Dubord (Lead), ReadMe - Javi Garcia - Marg Mañunga - Mateo Penagos |
Engineering - Tyler Williams (Lead), ReadMe - Megan Filo, ReadMe - Gaby Herrera - Alvise Leal |
Engineering - TBH - TBH - TBH - TBH |
| Analyst - Dennis Charukulvanich |
Analyst - Dennis Charukulvanich |
Analyst - Dennis Charukulvanich |
Analyst - Dennis Charukulvanich |
| Director - Michael Preuss, ReadMe |
Director - Michael Preuss, ReadMe |
Director - Michael Preuss, ReadMe |
Director - Michael Preuss, ReadMe |
GitLab's digital marketing platform, or simply the “Marketing Site" refers to https://about.gitlab.com with the exception of the handbook.
We collaboratively define OKRs as a team with cross functional partners in advance of each quarter. Once OKR candidates are complete we review, size/scope them and align on which best help achieve our business objectives.
FY23Q2 Digital Experience Quarterly Plan & OKRs
We release every 2 weeks, always on a Wednesday. We can push MRs at any time but for collaborative work initiatives, we plan a package for delivery to ensure we’re consistently improving our prospective customer’s experience.
| Monday | Tuesday | Wednesday | Thursday | Friday |
|---|---|---|---|---|
| Sprint Begins | ||||
| Sprint Release Async | Sprint Ends |
We use the following boards to plan sprints:
Before a sprint starts, our team reviews potential work for the upcoming sprint. We identify issues that need to be written, write them, wieght them and add the to-do label.
A team member should enter sprint planning with an opinion on what the most important issues to work on are and be ready to make the sprint plan in collaboration with the team.
Weighting
We use issue weight to plan and manage our work. Team members are not held to weights, they’re simply a planning and learning tool. Digital Experience weights are based on the following point scale: 1pt = .5 day. In a full two-week sprint, we plan to deliver 20 points per team member.
We use Geekbot to conduct asynchronous, weekly check-ins on iteration progress.
Each member of the Digital Experience team should be listed as a participant in the weekly check ins, and everyone should have permissions to manage the application for our team. The app can be configured through the Geekbot Dashboard, which you can visit directly, or find by clicking the Geekbot Slack conversation, navigating to the About tab, and clicking App Homepage.
Our team makes every attempt to complete code reviews on Merge Requests as timely as possible.
Team members who create a Merge Request should factor in a suitable amount of time for code and/or design review. If an issue has a due date, the MR creator should try have the work code-complete at least 24 hours prior to the intended release. This gives time for any major fixes that the reviewers may point out, and encourages quick iterations and Minimal Viable Change releases.
When a team member is requested for review, it is good practice for them to post a comment in the Merge Request with an estimated timeline by which they expect to complete the review. For example, it is understandable to take 3 days to do a review, as long as you’ve let the MR creator know it may take that long. This gives the MR creator an opportunity to request a review from another team member.
Digital Experience code request reviews should include the merge request checklist as referenced on the reviewing merge requests handbook page. Merge requests involving a URL redirect should also include the redirect checklist.
Similar to the engineering department, we sometimes temporarily halt production changes to the Buyer Experience repository when team availability is reduced, or we expect atypical user behavior (such as during high-visibility public events).
Risks of making a production environment change during these periods includes immediate customer impact and/or reduced engineering team availability in case an incident occurs. Therefore, we have introduced a mechanism called Production Change Lock (PCL). We are listing the events here so that teams are aware of the PCL periods.
The following dates are currently scheduled PCLs. Times for the dates below begin at 09:00 UTC and end the next day at 09:00 UTC.
| Dates | Reason |
|---|---|
| 2022-04-26 to 2022-04-28 | GitLab brand refresh |
During PCL periods, merge requests and deployments can only be made by senior team members, managers, and levels of management above our team.
From time to time, our team has objectives that require us to collaborate on the GitLab product. Read more about the process for our engineers to onboard
On the second Wednesday of each sprint, we have a calendar reminder for: “Sprint Release Async”, which serves as a reminder for team members to add to our Sprint Release Video Document.
Special cases during release post schedule: we hold off on making changes to the www-gitlab-com repository during release post days. The release post process is handled by a different team, and it can be disruptive to their work when we release changes to dependencies, CI/CD, or other major changes around their monthly release cadence.
Sprint Retros allow us to reflect on what went well and what we can to do continuously improve our process.
This is the agenda we use for Sprint Retros
We release videos for:
All videos are accessible in our Digital Experience playlist on GitLab Unfiltered.
At the end of every sprint cycle, Digital Experience will spend 10% or one day to work on issues related to improving the health of about.gitlab.com, the developer experience, tackle tech debt, or improve our documentation.
The structure of Repository Health Day is as follows: 1. Team members will choose what they wish to work on for this day. 1. Each team member will submit a single merge request to the www-gitlab-com repository by the end of repository health day. 1. This merge request will be related to an issue from any partner or group within GitLab.
By allowing our team members to contribute to the health of our repository for a day, we can contribute low-effort, high-impact solutions that will drive results for our team, partners, and the entire marketing site. This will enable Digital Experience team members to use their strengths to efficiently drive results for the www-gitlab-com repository. We’re all good at different things and come from different backgrounds. Let’s use that to our advantage to build a better repository that is inclusive of the team members that use it everyday.
Digital Experience will dedicate one week or 8.33% per quarter to work on projects that improve the health of the www-gitlab-com repository, the developer experience, or tackle larger tech debt projects. These are projects that can not be completed in a single repository health day and require a higher degree of effort.
The Digital Experience team utilizes Data Studio, a dashboarding tool that visualizes data from Google Analytics, to monitor metrics related to web traffic, engagements, conversions, and site health over time. Team members can interact with the dashboard accordingly by changing the data range, filter by device type or traffic source, or drill-down certain reports with a secondary dimension. A detailed walk-through video of the dashboard is available here.
To make a change request to the dashboard, please submit an issue to the Buyer Experience project with the dex::analytics label.
@digital-experience use this handle in any channel to mention every member of our team.
Our team works from a quarterly plan, for example: FY22Q3 and FY22Q4. Our quarterly plan is developed with the intention to put us 30% beyond our capacity which is GitLab policy.
We do our best to assist team members but do not operate as an internal agency so all requests will be prioritized against commitments in our current quarterly plan.
We love collaborating on work that drives our North Star and supporting metrics. If you have an idea, a strategic initiative, or an OKR that we requires our support here's how you can kick off our collaboration:
