Competitive Intelligence
Competitive Intelligence at GitLab
The Competitive Intelligence function at GitLab has two primary constituencies (1) Our prospects and customers (2) Our sales organization, which includes partners who assist in sales efforts.
Prospects and Customers: In keeping with a GitLab core value of transparency, Competitive Intelligence will ensure that anyone looking to an end-to-end DevOps solution has the information they need to make the right and unbiased decisions that serve the customer’s business goal. To this end, all our product comparison pages are un-gated and available at DevOps Tools Comparison Pages. GitLab believes that transparency of competitive intelligence creates a well informed customer and gives teams the information to be successful during their DevOps journey.
Sales Team: Another GitLab core value is results. Sales is a key constituency that helps GitLab achieve results. Hence parts of the Competitive Intelligence material is targeted at helping our sales teams effectively sell to our prospects, thereby delivering value that fulfills the customer’s business needs.
Team Charter
The competitive intelligence team brings timely and insightful analysis of competitors’ actions to help guide the actions and direction of GitLab.
- We work cross-functionally to help improve the feedback loop of turning insight into action, using competitive data to better inform key departments with the aim of improving our product for our customers.
- We work both on the front lines, empowering our sales teams with better tools to help dismantle competitors’ narratives, and with the highest levels of seniority, guiding strategic direction to help anticipate market movements.
- We measure our win and loss reasons, surfacing, triaging, and helping to solve key weaknesses, while ensuring we celebrate our strengths
- We use strategic information to proactively inform senior leadership across the company to help guide company strategy, and to ensure GitLab is a market and thought leader as the DevSecOps platform of choice
- We take timely information from the market and use it to guide our assessment of how GitLab should act, react and consider our competitors
Comparison Assets - Externally-facing
All our comparison assets - pages that compare other vendor products with GitLab are found in the DevOps Tools Landscape page and the DevOps Maturity Comparison chart
These assets have two different purposes:
- The DevOps Tools Landscape visualizes how we consider ourselves in each stage, ranking GitLab compared to the Best In Class competitors for each stage.
- The DevOps Maturity Comparison Chart visualizes how we compare on a category level to each of the Best In Class competitors in each stage.
Comparison Assets - Internal Competitive Assets
Crayon
About Crayon
All our internal competitive intelligence (competitor cards, internal webinars and documents) are hosted on our Highspot page, leveraging our Crayon competitive intelligence tool, which hosts the competitor cards.
For more information on Crayon, see our competitive intelligence page in the internal handbook
Access to Crayon has been opened to all our Sales, Product, Engineering, and Marketing teams. You can access Crayon through the Okta tile (search for it within Okta if it doesn’t appear on your list). In the spirit of the GitLab value of collaboration, all accounts are given “collaborator” level access, meaning all users can create and edit content in the same way as the competitive intelligence team. Users may be downgraded to “viewer” access if necessary.
If you are not in these teams and require access, reach out to @jkempton on slack with your request.
In the spirit of the GitLab values of iteration and collaboration, Crayon is designed to allow GitLab teammates to contribute and develop any and all competitive intelligence, wherever and whenever they encounter it, rather than it being gatekept by just the Competitive Intelligence Team. In that regard, the team are encouraged to update, correct, amend and comment on competitive intelligence news, on competitive cards, and collaborate on competitive boards to ensure everyone has the best and most up-to-date information. Crayon also has a dedicated analyst working behind the scenes to help source and surface competitive intelligence; you may see comments from our analyst within the Crayon tool.
For any questions around how to use the Crayon platform, please use Crayon’s own FAQ before reaching out to ‘@jkempton’ for any help.
Note also that the “help” functionality on the tool should ONLY be used for questions around the use of the Crayon tool, and not for general questions directed at the GitLab competitive intelligence team (for example, questions like “Can you help with this competitor” should be shared in the ‘#competition’ slack channel, not asked as a question through Crayon)
How to use Crayon
Any GitLab Sales, Product, Engineering, and Marketing team member can contribute to Crayon including:
- Adding a new competitor card
- Adding in objection handling questions and resolutions
- Highlighting a product release or notable competitor change
When adding, removing or amending competitive information to Crayon, please follow the process below:
- Find the appropriate competitive card to add the content. It’s important to evaluate the importance of the information: Does it just impact one competitor? Is it part of a broader theme? Do we need to duplicate the information across to other competitor cards?
- Once new content is created, the information will not be updated until it is re-published. Tag @Jkempton in the comments section for the card to confirm what additions/removals have been made, similar to the process of an MR within GitLab.
- @jkempton will then review the content changes, edit if appropriate, and re-publish the cards.
Remember that Crayon is designed for hosting our competitive information for the field to quickly reference. It is not a dictionary of information with expansive explanations, and needs to be straight to the point with truthful and simple explanations.
Clozd
Clozd is our third-party win/loss interview partner. Clozd allows us to undertake deep-dive interviews with customers or prospects who have evaluated GitLab. We have engaged the services of Clozd to ensure we get a non-biased view of our marketing, our sales process, and product capabilities, and to help solve the following challenges:
- Some internal data may not give us accurate enough information on why we win and lose deals, or at least gives us a high-level overview
- Knowing what product capabilities should take priority can be difficult when we have hundreds of issues on different topics
- Understanding who was the biggest threat in competitive situations can be difficult when we are often up against multiple DIY DevOps challengers
FY2024 strategy
We will engage Clozd with 60 interviews over the course of FY 2024. Our aim is to have a small majority of these as losses versus wins, as these tend give us greater insight into our shortcomings as a company. We will also split out interviews geographically in line with GitLab sales.
Our win criteria:
- The larger the better (ideally Enterprise customer)
- A customer that recently chose GitLab, and which has successfully onboarded.
- A customer that was evaluating other competitors (preferably GitHub or other major competitors)
- A customer that chose us for “interesting” criteria, (e.g. that are either our strengths, or elements where we usually lose to competitors, not just because we might have been cheaper)
Our loss criteria:
- A customer that recently chose a competitor to GitLab
- The larger the better (ideally Enterprise customer)
- A customer that considered us in the final decision (e.g. the decision came down to GitLab vs GitHub)
- Ideally, a loss where the reasons for the loss are still not entirely clear (e.g. we communicated our differences with our competitors but they weren’t convinced).
- A loss that did not come down solely to pricing
Clozd process and Risk Mitigation Plan
In order to mitigate the risk associated with Win/Loss communications, the following plan has been agreed internally with the Privacy team:
Process |
Clozd can send Win/Loss communications in the United States with no further consent from the Prospect/Lead because the United States is on Opt-Out. |
| Clozd can send automated communications in the rest of the world if there is a Win opportunity with the Prospect/Lead because then future communications are subject to a transaction and Soft Opt-In is available in the majority of the world |
| Generally Clozd cannot send automated communications in the rest of the world if there is a Loss with the Prospect/Lead because then Soft Opt-in is not available. However, these communications can be sent if the following is true: |
| The GitLab sale representative asks the Prospect/Lead during its conversations whether they can be contacted by Clozd for Loss analysis and the Prospect/Lead agrees |
| There is some kind of proof of that agreement, such as an email confirmation or contemporaneous call notes stating the Prospect/Lead agreed to subsequent communications |
| The Clozd business owner, @jkempton, manually sends the contact information to Clozd upon validating the two prior sub-bullets |
The Comparison Process
At GitLab, anyone can contribute to the Competitive Intelligence process. We strive to meet the following goals.
- Fair: For any CI process to be credible it has to be fair. That’s a reason why we use the DevOps Category Maturity as a guideline for our comparisons. This ensures that there’s common basis of understanding of each stage in the end to end DevOps lifecycle and it is not a cherry picket set of criteria just to make a vendor look good or bad.
- Accurate: We strive to be as accurate as possible by taking input from websites, product documentation, demo videos, trails where allowed, information from customers, and even competitors. For example, recently a Product Manager from a competitor reached out to us about a correction to the analysis, which we quickly made.
- Easily consumable: We make the information easily consumable by making it available on the website.
Competitors and Products with overlapping functionality
GitLab exists in an ecosystem of DevOps tools and might need to interact with any number of these tools. Many have over-lapping capabilities, but that does not mean that we necessarily directly compete with them. A user would need to patch together multiple solutions from this list in order to get all the functionality that is built-in to GitLab as a single application for end-to-end DevOps.
We tend to include those products also in the DevOps Tools comparison pages so customers have a comprehensive understanding of how we view the full landscape, not necessarily in competitive terms. Refer to this handbook page for more information on who GitLab competes with.
The Customer’s Voice
As always the customer’s voice is absolutely critical in this. Fortunately there are several such third party neutral sites that capture customer feedback about DevOps Tools, including GitLab. Here are some sites that have feedback on GitLab - in the customer’s voice.
Other comparison sites
Comparisons at a deep level are challenging and time consuming. We’d like to acknowledge some other sites that have done a sincere and strong effort at comparing DevOps tools. Some of these are by competitors but in keeping with GitLab values of transparency and to provide our prospects a comprehensive picture - here they are:
Where we are headed
- Expanding our internal competitive content, including building on the work of our exisiting competitor cards, from both platform and DIY DevOps competitors, but also on key trending topics such as AI. For more feature-by-feature comparisons we will be leveraging the internal knowledge of our product teams to ensure we are keeping information as up to date as possible
- Improving our insight into our win/loss data and enhancing our strategic guidance accordingly
- Refocusing our externally-facing competitive content in line with our marketing strategy.
Strategy
The goal of the Competitive Intelligence team will be to provide a complete set of assets and other deliverables that enable sales teams to compete and win.
The diagram below captures the overall approach. The idea is that for each use case-competitor with the exception of the strategy document (hosted in Crayon), all other resources should generally be publicly accessible. This is in keeping with GitLab value of Transparency.
See the Solutions Marketing page for more information.
Security Lexicon
A uniform lexicon is important to distinguish the use of ‘security’ in various contexts.
GitLab helps our customers Secure and Govern all of the phases of the SDLC Create, Plan, etc.). To deliver secure applications, customers use GitLab Security Controls throughout the SDLC and Security Testing in validation. Eventually, GitLab will enable vulnerability prioritization for planning and Security Monitoring in production.
-
Security Controls are capabilities of GitLab that altogether provide GitLab customers auditability of code throughout the SDLC. (This is not SAST/DAST.) For example, see GitHub security. These controls help customers in their efforts to comply with various industry regulations that require policies for auditability and access control. Examples include:
CI & CD
From “Setting up GitLab CI/CD for Android projects”
Continuous Integration (CI)
Continuous Integration usually refers to integrating, building, and testing code within the development environment. Continuous Delivery builds on this, dealing with the final stages required for production deployment.
- Martin Fowler on continuous delivery, 2013
What
- Continuous Integration is a development practice
- Focuses on frequently integrating code into a shared repository
- Involves automatically building and testing every change that is committed
- Higher frequency of integration and testing means smaller problems
- smaller problems are easier/quicker to fix
- Focus is to find code issues as early and quickly as possible
- while the developer is still in context of code change, so easier to resolve problems
Why
- Reduces late discovery of code problems/bugs, making releases non-events and fixes less costly
- Enables developer confidence in code, which results in faster development
Who
- All development organizations
- Especially those who are trying to practice DevOps
Continuous Delivery/Deployment (CD)
Continuous Delivery is sometimes confused with Continuous Deployment. Continuous Deployment means that every change goes through the pipeline and automatically gets put into production, resulting in many production deployments every day. Continuous Delivery just means that you are able to do frequent deployments but may choose not to do it, usually due to businesses preferring a slower rate of deployment. In order to do Continuous Deployment you must be doing Continuous Delivery.
- Martin Fowler on continuous delivery, 2013
Last modified October 30, 2024:
Fix broken links (39532aab
)