index.html.md 11.3 KB
Newer Older
John Jeremiah's avatar
John Jeremiah committed
1
---
2
layout: handbook-page-toc
3
title: Solutions Go-to-market
John Jeremiah's avatar
John Jeremiah committed
4 5
---
## On this page
6
{:.no_toc .hidden-md .hidden-lg}
John Jeremiah's avatar
John Jeremiah committed
7

8 9
- TOC
{:toc .hidden-md .hidden-lg}
John Jeremiah's avatar
John Jeremiah committed
10

11
## What are solutions?
John Jeremiah's avatar
John Jeremiah committed
12

13
Solutions are a product or suite or products and services that business purchase to solve business problems. They are typically categorized into 3 buckets
John Jeremiah's avatar
John Jeremiah committed
14

15 16 17
1. Use Cases
1. Industries/verticals
1. Business type/market segment
John Jeremiah's avatar
Edits  
John Jeremiah committed
18

19
### Use Case Solutions
John Jeremiah's avatar
John Jeremiah committed
20

21
The [Customer Use Cases](/handbook/use-cases/) page lists an overview of our use cases.
John Jeremiah's avatar
John Jeremiah committed
22

23
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.
John Jeremiah's avatar
John Jeremiah committed
24 25 26

## Buyer's journey and typical collateral

shanerice's avatar
shanerice committed
27
As a prospect is determining that they have a specific problem to solve, they typically go through several stages of a [buyer's journey](/handbook/marketing/inbound-marketing/content/#content-stage--buyers-journey-definitions) which we hope ultimately leads them to selecting GitLab as their solution of choice.
John Jeremiah's avatar
John Jeremiah committed
28

John Jeremiah's avatar
John Jeremiah committed
29
| **Awareness** | **Consideration** | **Decision/Purchase** |
30
| --------- | ------------- | ----------------- |
John Jeremiah's avatar
John Jeremiah committed
31 32
| 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 |
33
| **-** White papers describing the problem space<br>**-** Infographics illustrating the impact of the problem/challenge<br>**-** Analyst reports describing the problem/domain<br>**-** Webinars focusing on the problem and how can be solved<br>**-** Troubleshooting guides to help overcome the problem<br>**-** 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<br>**-** Infographics illustrating the success and impact of solving the problem<br>**-** Analyst reports comparing different solutions in the market (MQ, Waves, etc)<br>**-** Webinars focusing on the success stories and how gitlab helped solve the problem<br>**-** Customer Case Studies, Videos, Logos, etc<br>**-** Solution Check Lists / Plans for how to solve the problem<br>**-** Comparisons between GitLab and other solutions | **-** ROI calculators<br>**-** Use case specific implementation guides<br>**-** Use Case migration guides (from xyz to GitLab)<br>**-** Getting Started info<br>**-** References and case studies |
John Jeremiah's avatar
John Jeremiah committed
34 35 36

## Buyer's Journey - Audience

John Jeremiah's avatar
Edits  
John Jeremiah committed
37
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.
John Jeremiah's avatar
John Jeremiah committed
38

39 40
In this view, the journey is started from the executive's perspective.

John Jeremiah's avatar
John Jeremiah committed
41 42
![Buyer's Journey](./buyers-cycle-journey.png)

John Jeremiah's avatar
John Jeremiah committed
43
- **Executives** will need information about business value, risk, cost, and impact to support strategic objectives
John Jeremiah's avatar
John Jeremiah committed
44
- **Managers** will need more detailed information to drive planning, justification, and migration details.
John Jeremiah's avatar
John Jeremiah committed
45
- **Contributors** need technical details about how it works, how it's better, and how it's going to help them in the future.
46

47
The Buyer's journey also starts when developers and the team start to look for solutions to their day to day challenges.
John Jeremiah's avatar
John Jeremiah committed
48

49 50
![Buyer's Journey-Staff Led](./buyingcycle-staff-started.png)

51
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.
52

53 54 55 56 57 58 59 60 61 62 63 64 65
### Solution DRIs

Solutions have DRIs defined at the top of each GTM Strategy page. The chart below shows these people in 1 place.

For solutions that have a GTM Motion build around them, DRIs for the motion are based on the [GTM Motion Core team](https://about.gitlab.com/handbook/marketing/plan-fy22/#core-teams).

| Solution | PMM | TMM | PM |
| - | - | - | - |
| Agile Planning | Cormac Foster | Tye Davis | Gabe Weaver |
| SCM | Brian Glanz | William Arias |  Daniel Gruesso |
| CI | Parker | Itzik | Jackie Porter |
| DevSecOps | Cindy Blake | Fern | David DeSanto |
| GitOps | Saumya | Cesar Saavedra | Viktor Nagy |
John Jeremiah's avatar
John Jeremiah committed
66

John Jeremiah's avatar
John Jeremiah committed
67
#### Key Links
Parker Ennis's avatar
Parker Ennis committed
68

69 70
|  | **CI use case** | **CD use case** | **DevSecOps use case** | **VC&C use case** | **GitOps use case** | **Agile use case** |
| --- | ----------- | ----------- | ------------------ | ------------- | --------------- | -------------- |
71
| **Resource page** | [CI page](/handbook/marketing/strategic-marketing/usecase-gtm/ci/) | [CD page](/handbook/marketing/strategic-marketing/usecase-gtm/cd/) | [DevSecOps page](/handbook/marketing/strategic-marketing/usecase-gtm/devsecops/) | [VC&C page](/handbook/marketing/strategic-marketing/usecase-gtm/version-control-collaboration/) | [GitOps page](/handbook/marketing/strategic-marketing/usecase-gtm/gitops/) | tbd |
72
| **Solution page** | URL tbd | URL tbd | URL tbd | [Solution page](https://about.gitlab.com/solutions/version-control/) | URL tbd | URL tbd |
73
| **Topic page** | URL tbd | URL tbd | URL tbd | [Version Control](https://about.gitlab.com/version-control/) | URL tbd | [What is GitOps?](/topics/gitops/) |
74 75 76 77
| **Campaign page** | [CI landing page](https://about.gitlab.com/why/use-continuous-integration-to-build-and-test-faster/) | Link to [epic](https://gitlab.com/groups/gitlab-com/marketing/-/epics/748) (URL to be added) | [DevSecOps landing page](https://about.gitlab.com/why/shift-your-security-scanning-left/) | [VC&C landing page](https://about.gitlab.com/why/simplify-collaboration-with-version-control/) | [GitOps landing page](/why/gitops-infrastructure-automation/) | tbd |
| **Webcast pages** | tbd | tbd | tbd | [VC&C Webcast](https://about.gitlab.com/webcast/collaboration-without-boundaries/) | tbd | [GitOps Webcast](/why/gitops-infrastructure-automation/) |
| **Slack channel** | #solution_ci | #solution_cd | #solution_devsecops | [#solution_vcc](https://join.slack.com/share/zt-fmu0oq6b-GiliYD2NPpBZYIP5MPQTTA) | [#gitops](https://gitlab.slack.com/archives/C01576AQV18) | #solution_agile |
| [**Use case epic**](https://gitlab.com/groups/gitlab-com/marketing/strategic-marketing/-/epics/71) | [CI epic](https://gitlab.com/groups/gitlab-com/marketing/strategic-marketing/-/epics/70) | [CD epic](https://gitlab.com/groups/gitlab-com/marketing/strategic-marketing/-/epics/171) | [DevSecOps epic](https://gitlab.com/groups/gitlab-com/marketing/strategic-marketing/-/epics/56) | [VC&C epic](https://gitlab.com/groups/gitlab-com/marketing/strategic-marketing/-/epics/42) | [GitOps epic](https://gitlab.com/groups/gitlab-com/marketing/strategic-marketing/-/epics/28) | [Agile epic](https://gitlab.com/groups/gitlab-com/marketing/strategic-marketing/-/epics/185) |
John Jeremiah's avatar
John Jeremiah committed
78

79
### UseCase GTM Bill of Materials
John Jeremiah's avatar
John Jeremiah committed
80 81 82

![GTM-bom](../images/BOM-Activation.png)

83
### Market Requirements
John Jeremiah's avatar
John Jeremiah committed
84

85
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.
86

87
In product terminology, Market Requirements are similar to concept of [Jobs to be Done (JTBD)](/handbook/engineering/ux/ux-resources/#jobs-to-be-done-jtbd). Both represent something the end user or customer wants to accomplish. Like JTBD, Market Requirements are <i>**not**</i> 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](/handbook/engineering/development/ops/package/jtbd/#jobs-to-be-done) 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**
88

89
In [Command of the Message terminology (COTM)](/handbook/sales/command-of-the-message/#additional-resources) 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.
90

John Jeremiah's avatar
John Jeremiah committed
91
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.
92

93
The downstream impacts of market requirements are
94

95 96 97
- 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.
John Jeremiah's avatar
John Jeremiah committed
98 99 100

![Market Requirements](../images/market-requirements.png)

John Jeremiah's avatar
John Jeremiah committed
101
### Use Case GTM Bill of Material Priorities & Tracking
102

John Jeremiah's avatar
John Jeremiah committed
103
<div class="wide-sheet">
104
<iframe width="1200" height="1100" src="https://docs.google.com/spreadsheets/d/e/2PACX-1vTptvo1N7m8tjLSgJFOoy8l2fhnJmlyS83JhsT2DU6Ki3x1tcJ0Jd4Y4nvDnz0EbLEddAzpWHQYMWVs/pubhtml?gid=1180560927&amp;gridlines=false&amp;single=true&amp;widget=true&amp;headers=false&amp;rm=minimal&amp;range=A1:L42"></iframe>
John Jeremiah's avatar
John Jeremiah committed
105
</div>
106

107
- [GTM Tracking Spreadsheet](https://docs.google.com/spreadsheets/d/1K78pI_sqS91o8fpMReCF5n7gf7tZjCFxU4PjX2uddxk/edit#gid=2033522968)
108

Dan Gordon's avatar
Dan Gordon committed
109 110
### Bill of Materials Material Details

111 112 113 114 115
- Product Marketing
- [Technical Marketing](bom/tmm.html)
- Competitive Intelligence
- Market Research and Customer Insights
- Partner and Channel Marketing
116 117 118

### Tracking Progress

William Chia's avatar
William Chia committed
119
We will use Epics and Milestones to track our overall progress of creating and activating these use cases.
120

121
1. This [Epic Roadmap](https://gitlab.com/groups/gitlab-com/marketing/-/roadmap?label_name%5B%5D=usecase-gtm&layout=MONTHS&scope=all&sort=start_date_asc&state=opened&utf8=%E2%9C%93_) view shows the current Epics that are actively being workd.
122
1. This [Milestone](https://gitlab.com/gitlab-com/marketing/product-marketing/-/milestones/11) is tracking all the issues in the Use Case GTM Sprint #3 (March 2020)
123

John Jeremiah's avatar
John Jeremiah committed
124 125
#### Bill of Materials progress

126
![BOM Progress](../images/BOM-Progress-2020-04-06.png)