Solutions Go-to-market
Solutions and Value Plays
Solutions are a product or suite or products and services that business purchase to solve business problems. They are typically categorized into 3 buckets that address
- Market segment requirements (e.g. DevOps platform solution). Ours are outlined below with more details here
- Industries/verticals requirements (e.g. Pub Sec, High Tech, Retail)
- Business segment requirements (e.g. enterprise vs SMB)
Relevant solutions will differ by audience.
- C-level executives care about broad business solutions, often characterized by well-funded strategic business initiatives - things that help them improve productivity, reduce cost, or deliver value faster - things that align with Command of the Message Customer Value Drivers. The C-level audience are important influencers who set an organizations agendas, strategic objectives, and fund major IT initiatives.
- DevOps buyers are tasked with determining HOW to meet the transformational business objectives backed by their C suite. They likely have a budget to buy or replace specific DevOps capabilities (like CI) and the more Directors and VPs often look at the bigger picture of how to simplify a complex DevOps environment.
- DevOps users are tasked with using the tools to make the transformation happen. They care about how a given tool makes their job easier, their time more productive, and their code more secure.
A picture may help convey the Solution Framework.
One of the most common of these sweeping initiatives is Digital Transformation. The Enterprise Project provides a useful definition of Digital Transformation: “Digital transformation is the integration of digital technology into all areas of a business, fundamentally changing how you operate and deliver value to customers.”.
A Digital Transformation initiative is typically executed through a set of strategic business solutions. Research in November 2021, showed that C-level executives are concerned most with these Digital Transformation Solutions:
| Strategic Solution |
primary objective |
exec sponsor |
characteristics |
| 1. Security and compliance |
understand and manage risk |
CISO or CTO |
requires technology and process transformations |
| 1. Cloud transformation |
gain business agility |
line-of-business VP (LOB) or CTO |
often technology-focused with adoption of cloud, containers, Kubernetes, IaC |
| 1. Application modernization |
improve software time-to-market |
CTO |
often process-focused with DevOps, Agile, velocity, VSM |
Connecting solutions to value plays
These transformative solutions must get connected to DevOps initiatives where GitLab is established. It’s important to guide prospects from broad ideas down to specific actions, budgets, and sales opportunities. We do this via core DevOps GTM solutions where we articulate a message of how we help customers achieve positive business outcomes, and where we align sales efforts (Value plays and revenue programs) and marketing campaigns (such as digital ads, email campaigns, nurture, events), to focus on opportunities where we have the greatest likelihood of success. By providing a solutions framework and capturing steps in value plays, we expect to achieve repeatable, predictable sales outcomes with metrics that help us optimize marketing spend for greatest impact.
GitLab customers can purchase these solutions by working directly with our sales teams or by working with our Channel Partners and Technology Alliance Partners. Partners support GitLab customers by offering services that deliver DevOps solutions. The core DevOps solutions and the value plays each supports include:
Which solution to use for which persona
The core DevOps solutions are communicated to sales via Solutions Selling in HighSpot.
Understanding which solution to apply where requires consideration of the persona/audience. The matrix below suggests which conversation is best for which persona as a recommended starting point.
DevOps Solution DRIs and key links
Use cases
Within the core DevOps solutions, are use cases. These topics may be hot in the market (like Security), or associated use cases with GitLab (like SCM). They may attract interest for a conversation with a prospect. Conversations about these capabilities may open the door (as a wedge) to broader conversations that align to value plays - typically leading to either the platform solution or Automated Software Delivery solution.
Examples include:
The Customer Success Managers (CSMs) are goaled on expanding an existing customer’s adoption of GitLab use cases, as measured by use case adoption. Mapping use cases to stages helps the CSMs know which use case material to apply.
Use cases DRIs and key links
Future Use cases
- Test automation (UI test automation, mobile app testing, performance tests, load tests .. )
- GitOps
- Ecosystem - extensibility, plugins, content
- Observability
- AI (currently AI workflows will be captured as part of the usecases they are part of. Future decision to be made to track as a separate usecase)
Last mile alignment
For optimal impact, sales and marketing efforts must align across the entire sales and marketing life cycle.
Internally, solutions GTM should drive:
- Value plays which align with revenue programs
- campaigns which support value plays
- Highspot and Path Factory topics/spaces
- metrics fields in SFDC Command Plan for proper reporting and assessment
Externally, solutions GTM should drive:
- Solutions pages (from Home page drop-down)
Buyer’s journey and typical collateral
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. Use cases can address unique concerns and may help overcome perceived barriers. |
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 |
Buyer’s Journey - Audience
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.
- Executives will need information about business value, risk, cost, and impact to support strategic objectives
- Managers will need more detailed information to drive planning, justification, and migration details.
- Contributors need technical details about how it works, how it’s better, and how it’s going to help them in the future.
The Buyer’s journey can also start when developers and the team start to look for solutions to their day to day challenges. 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.
Solution GTM Bill of Materials
To this model, we need to add ideal customer profiles to better inform marketing on types of companies to target for campaigns and to help sales qualify opportunities.
Market Requirements
Solution “Market Requirements” are the broad capabilities that a solution (product or multiple products) would need to support. Each GitLab DevOps solution 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 (internal-only) 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
- Technical Demos are based on showcasing specific market requirements
- Comparisons across the market (multiple vendors, multiple products) can be driven from market requirements
- ROI models can be built highlighting the value of specific market requirements.
| PMM |
TMM |
| Aathira Nair (@anair5) |
|
The Market Viewpoint
Agile Planning and Management
By empowering teams, embracing change, and focusing on delivering value, Agile methodologies have transformed software development. Agile teams create more relevant, valuable, customer-centric products, more quickly than ever.
Development teams accelerate the delivery of value with iterative, incremental, and lean project methodologies including Scrum, Kanban, Extreme Programming (XP), and more. Large enterprises have adopted Agile at enterprise scale through a variety of frameworks, including Scaled Agile Framework (SAFe), Spotify, Large Scale Scrum (LeSS), and others. GitLab enables teams to apply Agile practices and principles to organize and manage their work, whatever their chosen methodology. These new methodologies bring new challenges.
| Product Marketing |
Developer Advocate |
| Daniel Hom (@danielhom) |
Cesar Saavedra ( @csaavedra1 ) |
The Market Viewpoint
Continuous Delivery
“Deployment is manual”
“Functional tests are manual”
“Time consuming or lack of rollback on performance degradation or production errors”
“Hard to maintain environment configurations and hard to operate”
“No consistency in deployment process”
“Manual / hard coded configurations”
“No standardized software artifact”
“No release management in place”
“Too dependent on other teams to get any release done”
| Product Marketing |
Developer Advocate |
| Daniel Hom (@danielhom) |
@csaavedra1 |
The Market Viewpoint
The need for GitOps
Modern applications are developed with rapid iteration and run at highly dynamic scale. In an organization with a mature DevOps culture code can be deployed to production hundreds of times per day. Applications can then run under highly dynamic loads from a few users to millions. Modern infrastructure needs to be elastic. Capacity that can be dynamically provisioned and de-provisioned is able to keep pace with load maintaining optimal performance and minimal cost. With the demands made on today’s infrastructure it’s becoming increasingly crucial manage infrastructure automation with a robust and cohesive methodology.
Looking for a customer-facing overview of GitLab’s Continuous Integration (CI) capabilities? See the CI Solution
The page below is intended to align GitLab sales and marketing efforts with a single source of truth for our go-to-market efforts around DevSecOps.
| Product Marketing |
Developer Advocate |
| Daniel Hom (@danielhom) |
Itzik Gan-Baruch ( @iganbaruch ) |
The Market Viewpoint
Continuous Integration
The Continuous Integration (CI) use case is a staple of modern software development in the digital age. It’s unlikely that you hear the word “DevOps” without a reference to “Continuous Integration and Continuous Delivery” (CI/CD) soon after. In the most basic sense, the CI part of the equation enables development teams to automate building and testing their code.
Looking for a customer-facing overview of GitLab’s DevOps Platform? See the DevOps Platform Solution
GitLab field teams refer to this DevSecOps Platform highspot page for latest information
The page below is intended to align GitLab’s sales and marketing efforts with a single source of truth for our go-to-market efforts around the benefits of a single DevOps Platform.
NOTE: If you are looking for messaging guidelines regarding The DevOps Platform, please visit The DevOps Platform Message House.
How GitLab approaches the DevSecOps solution including messaging and key resources to help marketing and sales.
How GitLab approaches the software compliance solution including messaging and key resources to help marketing and sales.
How GitLab approaches the Automated Software Delivery solution including messaging and key resources to help marketing and sales.
Downtime is expensive and you can lower MTTR with GitLab Incident Management.
The Market Viewpoint
Data Science — AKA DataOps, MLOps, etc
Common challenges
Common challenges in data science are described on the Data Science with GitLab use case page and generally include being cross-functional, agile, and iterative while unlocking the value in an organization’s data. To do this, data teams need to:
- Collaborate both inside and outside their teams, and often inside and outside their organization
- Plan and manage projects and sprints, with tools flexible enough to support scrum, kanban, and more
- Version control everything: manage and track different versions of files, models, test cases, data sets
- Automate key workflow steps, that are otherwise slow and subject to manual errors
- Streamline testing and validation of work, making it much faster and more repeatable
- Simplify infrastructure management and often across multiple cloud providers
To be fleshed out as with other use cases.
What’s on this page?
This page lists the details of the Technical Marketing Bill of Material deliverables
Use case demo video
Description: Problem to solve and how we solve it) (<=10 mins)
Quantity: 1
Buyer’s Journey: Awareness
Priority: 1
Use case demo click-through/sim demo
Description: Interactive version of demo video
Quantity: 1
Buyer’s Journey: Awareness
Priority: 1
How to get started videos
Description: For GitLab Learn. (<= 5 mins each)
Quantity: 3
Buyer’s Journey: Awareness
Priority: 1
The Market Viewpoint
The landscape of software development is changing. Today’s users expect to interact with software applications that are always-on and accessible from every device. To keep up, businesses of all sizes that have traditionally built and managed centralized, monolithic applications are shifting to distributed cloud services. And these services are being built and run by distributed teams located all around the world. Modernizing the business through IT is a cultural and technological shift.
| Product Marketing |
Developer Advocate |
Product Management |
| Daniel Hom (@danielhom) |
Itzik Gan-Baruch ( @iganbaruch ) |
Tim Rizzi (@trizzi) |
The Market Viewpoint
Artifact management
As an Admin at a large, enterprise organization you need to enable your developers to point their tools like Maven, npm,or pip at a local proxy server for all of the dependencies that they need. The server must be able to fetch dependencies from remote repositories, cache the artifacts, and be able to export its database of them to an air-gapped system at a regular interval. You need the ability to easily apply policies when dependencies are initially downloaded—either scanning them for security vulnerabilities or applying some other selection criteria (allowable license, allowable package author, etc.).
<!--
-->
#### Who to contact
| PMM | TMM |
| ---- | --- |
| xyz | abc |
# The Market Viewpoint
## UseCase Name
Define and describe the use case in customer terms. Reference the [customer use case page](/handbook/marketing/use-cases/)
- [Keywords and SEO Terms](keywords/)
## Personas
### User Persona
Who are the users (a few remarks and link to the persona page)
### Buyer Personas
Who are the buyers
## Industry Analyst Resources
List key analyst coverage of this use case
## Market Requirements
| Requirement | Description | Typical features | Value |
|---------- |------------- |---------------- | -------|
| abc | def | ghi | jkl |
# The GitLab Solution
## How GitLab Meets the Market Requirements
| Market Requirements | How GitLab Delivers | GitLab Category | Demos |
| ------ | ------ | ------ | ------ |
| REQMT | HOW | CATS | DEMO |
## Top 3 Differentiators and Key Features
| Differentiator | Value | Proof Point |
|-----------------|-------------|---------------|
| abc | def | ghi |
## Message House
The message house for the use case provides a structure to describe and discuss the value and differentiators for the use case.
## Customer Facing Slides
### Discovery Questions
- list key discovery questions
## Competitive Comparison
TBD - will be a comparison grid leveraging the capabilities
### Industry Analyst Relations (IAR) Plan (UPDATE AS NEEDED FOR THIS USECASE)
- The IAR Handbook page has been updated to reflect our plans for [incorporating Use Cases into our analyst conversations](/handbook/marketing/brand-and-product-marketing/product-and-solution-marketing/analyst-relations/#how-we-incorporate-use-cases-into-our-industry-analyst-interactions).
- For details specific to each use case, and in respect of our contractual confidentiality agreements with Industry Analyst firms, our engagement plans are available to GitLab team members in the following protected document: [IAR Use Case Profile and Engagement Plan](https://docs.google.com/spreadsheets/d/14UthNcgQNlnNfTUGJadHQRNZ-IrAe6T7_o9zXnbu_bk/edit#gid=1124037301).
For a list of analysts with a current understanding of GitLab's capabilities for this use case, please reach out to Analyst Relations via Slack (#analyst-relations) or by submitting an [issue](https://gitlab.com/gitlab-com/marketing/strategic-marketing/product-marketing/-/issues/new?issuable_template=AR-Analyst-Validation).
## Proof Points - customers
### Quotes and reviews
- List of customer quotes/reviews from public sites
### Case Studies
- List of case studies
### References to help you close
- Link to SFDC list of use case specific references
## Adoption Guide
### Playbook Steps
- To be added...
### Adoption Recommendation
This table shows the recommended use cases to adopt, links to product documentation, the respective subscription tier for the use case, and product metrics.
| Feature / Use Case | F/C | Basic | S/P | G/U | Notes | Telemetry |
| ------------------- | :-------: | :-------: | :-------: | :--: | :----- | :-------: |
| `example` | `example` | `example` | `example` | `example` | `example` | `example` |
### Enablement and Training
### Professional Service Offers
## Partners
- Describe how key partners help enable this use case
## Key Value (at tiers)
### Premium
- Describe the value proposition of why Premium for this UseCase
### Ultimate
- Describe the value proposition of why Ultimate for this UseCase
## Direction
- Describe a vision for compelling future improvements
## Resources
### Presentations
- LINK
### Whitepapers and infographics
- LINK
### Videos (including basic demo videos)
- LINK
### Integrations Demo Videos
- LINK
### Clickthrough & Live Demos
- Link
## Buyer's Journey
Inventory of key pages in the buyer's Journey
| **Awareness** <br> learning about the problem | **Consideration** <br> looking for solution ideas | **Decision** <br> is this the right solution|
| ------ | -------- |-------- |
| topic page? | solution page | proof points |
| landing pages? | ?comparisons? | comparisons |
| -etc? | | - product page x <br> - product page y <br> - product page z |
Looking for an overview of GitLab’s Source Code Management(SCM) capabilities?
See the SCM Solution.
The page below is intended to align GitLab sales and marketing efforts with a single source of truth for our go-to-market efforts around Source Code Management.
Software Delivery Automation
Software Delivery Automation allows organizations to automate manual, repetitive tasks from their SDLC to improve the overall velocity of the software factory and increase collaboration across dev and ops. This includes both application and infrastructure automation.
