When a customer / prospect embarks on a transformation, they typically will initiate a specific improvement project, which will address a specific problem or challenge they are facing.
The Customer Use Cases page lists an overview of 8 customer use cases.
As we look at go to market, we've prioritized these usecases and more into two tiers.
These usecases are key to our GTM strategy, often are where we land in an account or are significant expand motions.
These usecases are secondary in our GTM strategy and are a mixture of some landing motions and also expansion in accounts.
GitOps (Adopting DevOps practices in managing infrastructure and operations - XaC + MRs + CI/CD)
These usecases are other situations where GitLab helps address a specific problem in an account.
In product marketing, we focus on GitLab stages and also develop and curate collateral that aligns with a buyer's journey supporting the use cases.
As a prospect is determining that they have a specific problem to solve, they typically go through several stages of a buyer's journey which we hope ultimately leads them to selecting GitLab as their solution of choice.
| Awareness | Consideration | Decision/Purchase |
|---|---|---|
| Collateral and content designed to reach prospects in this stage of their journey should be focused on educating them about the problems they are facing, the business impact of their problems, and the reality that others are successfully solving the same problem | Collateral and content designed to reach prospects in this stage of their journey should be focused on positioning GitLab as a viable and compelling solution to their specific problem. | Collateral and content designed to reach prospects in this stage of their journey should be focused on key information that a buyer needs to justify GitLab as their chosen solution. |
| Typical Awareness Collateral | Typical Consideration Collateral | Typical Decision/Purchase Collateral |
| - White papers describing the problem space - Infographics illustrating the impact of the problem/challenge - Analyst reports describing the problem/domain - Webinars focusing on the problem and how can be solved - Troubleshooting guides to help overcome the problem - Analysis of public cases where the problem impacted an organization (i.e. outage, data loss, etc) |
- White papers describing the innovative solutions to the problem - Infographics illustrating the success and impact of solving the problem - Analyst reports comparing different solutions in the market (MQ, Waves, etc) - Webinars focusing on the success stories and how gitlab helped solve the problem - Customer Case Studies, Videos, Logos, etc - Solution Check Lists / Plans for how to solve the problem - Comparisons between GitLab and other solutions |
- ROI calculators - Use case specific implementation guides - Use Case migration guides (from xyz to GitLab) - Getting Started info - References and case studies |
In addition the buyer's journey, there are also different audiences in an organization with different needs at different times. The general model for the buyer's journey outlines kinds of collateral that is needed at different stages of the buying cycle. It is incredibly important to understand the needs of the audience when creating collateral. Executives, managers, and individual contributors will need different information to support their specific work.
In this view, the journey is started from the executive's perspective.
The Buyer's journey also starts when developers and the team start to look for solutions to their day to day challenges.
In this view, the staff initiates the effort, as they have identified a challenge and are the champion of a change. They then convince their managers and executives of the need to consider an alternative to their current state.
Use cases/solutions are large, cross-functional concepts that enable go to market motions for multiple GitLab stages and categories. Use cases/solutions are rapidly evolving and improving with new content and insight ranging from personas to requirements to discovery questions and more. Due to the speed of delivery and evolution, we need a consistent approach to engage in 2-way feedback and encourage the adoption of use case content.
The activation team will be a stable group of extended stakeholders who will collectively shape, improve, and promote the adoption of use cases to enable us to become more efficient, responsive, and effective in our go-to market motions.
“Messaging without marketing is like a tree falling in the forest - did it make a noise?”
The activation team is an outlet for content validation and refinement, as well as enablers and promoters - who help us adopt use case messaging and content in our campaigns, content, and events.
| Role | CI use case | CD use case | DevSecOps use case | VC&C use case | GitOps use case |
|---|---|---|---|---|---|
| Product Marketing (John) | Parker | @supadhyaya | Cindy | Jordi | @williamchia |
| Technical Marketing (Dan) | Itzik | @iganbaruch | Fern | William A | @csaavedra1 |
| Product Manager | Jason | @ogolowinski | David | James Ramsay | @nagyv-gitlab |
| Content Marketing (Erica) | @cbuchanan | @cbuchanan | Vanessa | Suri | @cbuchanan |
| Developer Evangelism | ? | ? | M.Friedrich | ? | ? |
| Customer Reference (Colin) | Kim, Fiona | @FionaOKeeffe, Kim | Kim, Fiona | Kim, Fiona | @KimLock, Fiona |
| Competitive Intel (Mahesh) | Mahesh, Aleeta | Mahesh, Aleeta | Mahesh, Aleeta | Aleeta | @mskumar, Aleeta |
| Campaign Managers (Jackie Gragnola) | @aoetama | @ikryzeviciene | @ikryzeviciene | @jennyt | @eirinipan |
| Digital Marketing (Matt Nguyen) | @mnguyen | @mnguyen | @mnguyen | @mnguyen | @mnguyen |
| Field Marketing (Leslie Blanchard) | @rachel_hill | @rhancock | @phuynh | @krogel | @lblanchard |
| Solution Architect (Jonathan Fullam) | @jfullam | @jfullam | @DarwinJS | @jfullam | @jfullam |
| Technical Account Manager (Sherrod Patching) | @spatching | @jwoods06 | @kevinchasse | @jwoods06 | @jrreid |
| Field Enablement (David Somers) | @kreykrey | @tparuchuri | @kshirazi | @iabbasi | @jblevins608 |
| Partner Marketing (Tina) | @TinaS | @saraedavila | @saraedavila | @TinaS | @saraedavila |
| Alliances Team | @bjung | @bjung | @abrandenburg | @bjung | @bjung |
| Corp Comm/ PR Team | @cweaver1 | @cweaver1 | @cweaver1 | @cweaver1 | @cweaver1 |
| Analyst Relations | @rragozzine | @rragozzine | TBD | @rragozzine | TBD |
A framework for extended stakeholders who commit to regularly engage, contribute, and promote the most up-to-date, relevant, use case content to deliver business value. Specifically, this will help us:
| CI use case | CD use case | DevSecOps use case | VC&C use case | GitOps use case | Agile use case | |
|---|---|---|---|---|---|---|
| Resource page | CI page | CD page | DevSecOps page | VC&C page | GitOps page | tbd |
| Solution page | URL tbd | URL tbd | URL tbd | Solution page | URL tbd | URL tbd |
| Topic page | URL tbd | URL tbd | URL tbd | Version Control | URL tbd | What is GitOps? |
| Campaign page | CI landing page | Link to epic (URL to be added) | DevSecOps landing page | VC&C landing page | GitOps landing page | tbd |
| Webcast pages | tbd | tbd | tbd | VC&C Webcast | tbd | GitOps Webcast |
| Slack channel | #solution_ci | #solution_cd | #solution_devsecops | #solution_vcc | #gitops | #solution_agile |
| Use case epic | CI epic | CD epic | DevSecOps epic | VC&C epic | GitOps epic | Agile epic |
Use Case "Market Requirements" are the broad capabilities that a solution (product or multiple products) would need to support in order for a practitioner to use it for the use case. Each GitLab Use Case should have roughly 8-12 market requirements defined.
In product terminology, Market Requirements are similar to concept of Jobs to be Done (JTBD). Both represent something the end user or customer wants to accomplish. Like JTBD, Market Requirements are not features but instead a set of higher level capabilities that indicate what's "required" for a given solution to include in order to be successful in the market. For example, specific products do contain features that help to meet Market Requirements but the features themselves don't qualify as Market Requirements. JTBD tend to be very granular and specific. The list of JTBD for a particular stage can be long and is theoretically endless. Market Requirements are intentionally broad in an effort to keep the list of total requirements small and consumable. We expect that a given Market Requirement would consist of many jobs to be done
In Command of the Message terminology (COTM) used by Sales, these are NOT the same thing as "Required Capabilities". COTM "Required Capabilities" are very narrow and focused on a specific value driver aligned with GitLab. "Market Requirements" are intended to be comprehensive for a given use case and defined by the market (analysts, vendors, etc), not GitLab specific features), as well as seen through an 'outside-in' paradigm of the market.
When industry analysts do research, they use a market requirements model to evaluate competing solutions. A typical analyst report may have a set of 40-60 capabilities in their market requirements model used to measure and compare vendors with each other. For the sake of our go-to-market efforts, we bucket capabilities into 8-12 key market requirements per use case.
The downstream impacts of market requirements are
We will use Epics and Milestones to track our overall progress of creating and activating these use cases.
