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
Relevant solutions will differ by audience.
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 |
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:
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.
| Persona / Primary initiative | Security & Compliance | Cloud Transformation | App Modernization |
|---|---|---|---|
| CIO, CTO, CISO | Software Compliance | Platform | Platform |
| Dev/LOB | DevSecOps | Automated Software Delivery | Automated Software Delivery, DevSecOps |
| Security | DevSecOps | Software compliance | DevSecOps, Software compliance |
| Ops | Software compliance | Platform | Automated Software Delivery |
| Risk/legal/CFO | Software compliance | Software compliance | Software compliance |
| Automated Software Delivery | Security/DevSecOps | Compliance | Platform | |
|---|---|---|---|---|
| PMM | TBH Saumya Upadhyaya as placeholder | Brian Mason | Brian Mason | Saumya Upadhyaya |
| TMM | Itzik | Fern | Fern | William Arias |
| PM | Jackie Porter | Hillary Benson | Hillary Benson | Mike Flouton / Justin Farris |
| Resource page | Automated Software Delivery | DevSecOps page | Compliance | Platform |
| Solution page | Automated Software Delivery solution | DevSecOps solution | Compliance solution | GitLab home page |
| Highspot page | Automated Software Delivery | Software Security | Software Compliance | DevSecOps Platform |
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.
| Usecase | PMM | PM | Handbook | Adoption guide | Highspot page |
|---|---|---|---|---|---|
| SCM | Aathira Nair | Derek Ferguson | link | link | Part of Automated Software Delivery play |
| CI | Daniel Hom / Saumya Upadhyaya (placeholder) | Jackie Porter | link | link | Part of Automated Software Delivery play |
| CD | Daniel Hom | Viktor Nagy | link | link | Part of Automated Software Delivery play |
| Security | Brian Mason | Sarah Waldner | link | link | Security and Governance play |
| Compliance | Brian Mason | Sam White | link | link | Security and Governance play |
| Artifact Mgmt | Daniel Home / Saumya Upadhyaya (Placeholder) | Tim Rizzi | link | link | Part of Automated Software Delivery play |
| Agile Planning | Aathira Nair | Melissa Ushakov | link | link | |
| Analytics & Insights | Aathira Nair | Justin Farris | link | link | |
| Platform Engineering | Saumya Upadhyaya | Justin Farris | link | link |
For optimal impact, sales and marketing efforts must align across the entire sales and marketing life cycle.
Internally, solutions GTM should drive:
Externally, solutions GTM should drive:
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 |
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.
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.
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.
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
