Analyst Relations
Industry Analyst Relations at GitLab
Industry Analyst Relations (IAR) is generally considered to be a corporate strategy, communications and marketing activity, but at GitLab, because of our mission that everyone can contribute, we view the industry analyst community as participants as well. The primary owner/DRI of Industry Analyst Relations (including but not limited to relationships, communication, coordination, research participation, and contractual arrangements with industry analysts and their respective firms) at GitLab is Portfolio Marketing. This is in order to provide the most accurate, consistent, and comprehensive perspective on GitLab to industry analysts and to enable receiving the same from industry analysts.
If you would like to engage the analysts (e.g. research a topic, ask questions of an analyst, request analyst reports, brief an analyst) please click here for the research request form.
Examples of how we engage with analysts include:
- Briefings to update analysts on our product, our company, and our future direction
- Inquiries where analysts answer specific questions we have about product strategy, messaging, competitive positioning
- Advisory days for a deeper dive into the products, markets, and strategies
- Responding to analyst RFIs in support of comparative analyst research such as Forrester Waves, Gartner Magic Quadrants, and IDC MarketScapes
- Collaborating on market research procucts, surveys, sales enablement tools, etc.
- Providing an analyst newsletter to update analysts on what GitLab is doing between briefings
- Promoting analyst reports that feature GitLab to help enhance or clarify our story for customers, prospects, and partners
- Inviting analysts to participate in webinars, speaking engagements, media engagement, and other events where an analyst presence would be beneficial
- Open an issue in the Product Marketing project using the Analyst On-boarding template that details:
- what they cover
- alignment with internal use cases and technology areas
- plan for engagement
- Set them up in ARInsights, the third party analyst-tracking software we use
- Add them to the appropriate analyst newsletter distribution list
- Add them to the appropriate use case profile(s)
- Open an issue in the Product Marketing project using the Analyst Off-boarding template that details:
- Identify their reason for off-boarding, including departure or change or coverage
- Identify who is their short-term/long-term replacement
- Remove them from ARInsights distribution lists
- Remove them from the appropriate use case profile(s)
- Notify the product management and product marketing teams
How we incorporate Use Cases into our industry analyst interactions
- An initial round of inquiries to explore and get input into market requirements, target personas, etc. for a given use case
- Ongoing briefings to provide updates on progress made within the scope of a given use case
- Subsequent inquiry calls to revisit market requirements, competitive positioning, etc. as updated to meet evolving market conditions
Responding to requests to participate in industry analyst research comparing vendors and/or their products (e.g. Magic Quadrants (MQs), Waves, etc.)
-
GitLab evaluates participation in industry analyst comparative research to which we are invited based in large part on how well we meet the qualification criteria and how we are likely to score for strategy/vision. When participating, we are committed to providing our best possible answers for the questionnaires.
-
The teams responsible for answering the questionnaire will make this a priority. We will:
- Present every feature in the best possible light so we have the most defensible chance at high scores.
- Provide whatever evidence we can that illustrates our current and future capability to address the market needs identified by the analysts.
- When responding to the analyst request, challenge ourselves to find a way to honestly, unhesitatingly say “yes” and paint the product in the best light possible. We carefully work to understand specific feature and capability descriptions that often make up inclusion, exclusion and even evaluation criteria. If, at first glance we think we may not or do not support a specific feature or capability as described, we will take a deeper, second look at the requirement and look to see if there is a way that our existing features solve the problem at hand.
- Present our overall solution within the context of the entirety of a specific, defined market, meaning these exercises are bake-offs; we are being evaluated in comparison to everyone else rather than in comparison to an ideal world. We should take into account the competitive landscape as we craft our position and support it.
- Our demo should be viewed as a further proof point of our solution and a way to demonstrate things we might not be able to illustrate or otherwise communicate the way we’d like to in the questionnaire response.
Process for responding to industry analyst research comparing vendors and/or their products (e.g. Magic Quadrants (MQs), Waves, etc.)
Before the questionnaire arrives:
- GitLab AR is aware of what industry analyst research comparing vendors and/or their products (e.g. Magic Quadrants (MQs), Waves, etc.) we may be asked to participate in, particularly if we have done so before. AR should be checking with Forrester/Gartner to see if
- A MQ or Wave or similar comparative research is likely to be repeated
- The likely time frame for that comparative research (MQ, Wave, etc.) to begin
- Once the timeline is determined, 30-45 days in advance AR will
- Set up an inquiry with the lead analyst(s) to discuss customer inquiries they have received on this topic over the last year and gain insight on where they think the market is at currently
- Set up a short (30 minute) demo on the relevant part of GitLab to have them aware of our present position
- GitLab usually receives notice 1-2 weeks in advance that a Wave or MQ is forthcoming, in which they can participate.
- With Forrester, the process may begin with a Now Tech report. With Gartner, this process may begin with a Market Guide. It may also begin earlier, with an analyst asking for a meeting to discuss what we see in the market. This happened for example with Chris Condo of Forrester in 2019 with CI.
- AR works with PMM team to determine lead PMM, lead TMM and lead PM for the project.
- AR notifies Customer Reference that a request is imminent.
- If it is a Gartner MQ, AR will work with the Peer Review team to make sure GitLab reviews are being collected by the Peer Insights team or to get that activated, and coordinate with Peer Review and Customer Reference to funnel references to the appropriate Peer Insights page.
When the questionnaire arrives:
-
AR replies to the industry analyst firm, acknowledging receipt of invitation and agreement to participate, and indicates key participants (AR Manager and lead PMM.)
-
AR responsibilities:
- Create an issue for the report, a place to keep all links, due dates, supporting materials, related issues, and overall conversation
- Create a slack channel dedicated to this report, inviting all relevant members to the channel, pinning the issue in the channel
- Forward any Customer Reference material to the CR Manager
- Send out an invite for any kickoff call that the analyst may run related to this report and create a notes page for the meeting, adding that to the issue
- Coordinate all activities for deadlines
- Manage all correspondence between the industry analyst firm and GitLab, including an questions or clarifications, any requests for extension for demo or customer references, any conversation on choosing dates for demos/briefings, and submission of final questionnaire and customer references
- Coordinate with team for demo/briefing time slot
- Work with finance and sales ops, for company information
- Support the team in finding additional help where necessary
- Start and track issues for marketing, including a blog, changes to the web page, and gating the asset
- Remind the team of all due dates and hold periodic meetings if necessary to discuss progress and potential issues
- Create or update the report web page and make it available to PMM/PM to add their commentary - get it approved by the analyst company
- Work with corporate marketing and PR to decide if the results should be used in a press release or campaign and if reprint rights are required
-
Product Marketing Manager (PMM) responsibilities:
- read all information provided by AR in the issue
- attend all meetings with the analysts related to this report
- own responsibility for coordinating, collating, and organizing all input requirements including:
- draft questionnaire feedback
- final questionnaire response
- briefing presentation to analysts
- demo for analysts
- follow up questions for analysts
- drive the briefing to the analysts
- coordinate with Product leadership/CEO/others on final version of the questionnaire
-
Developer Advocate responsibilities:
- read all information provided by AR in the issue
- attend all meetings with the analysts related to this report
- work with PMM and PM in creation of demo and briefing
- drive the demo during the demo and briefing time slot
-
Product Management (PM) responsibilities
- read all information provided by AR in the issue
- attend all meetings with the analysts related to this report
- provide feedback to PMM on draft questionnaire and demo
- place the questionnaire and briefing/demo at the top of the work priority list
- provide first pass answers to the questionnaire to PMM
- work with PMM to finalize all answers to the questionnaire
When the Factual Review (Fact Check) arrives:
- AR shares the draft report with the PMM/PM/TMM team to check for technical accuracy
- PMM takes lead in verifying/correcting technical accuracy and the initial rewrite suggestions
- PM & TMM provide corrections for technical accuracy
- AR works with PMM for company accuracy issues
- AR submits final corrected version to analysts
When the courtesy copy of the report arrives (when we know final positioning):
- AR schedules a meeting with PMM/PM to discuss key messages and overall positioning
- basis for blogs
- basis for sales enablement
- basis for report web page
- basis for announcement level and reprint rights (may require additional budget to be allocated for reprint rights)
- Social Media: AR will follow the social marketing guidelines to create appropriate social media posts
- Blog posts and PR: will follow the Request for Announcement process to determine if this is a Level 1 or Level 2 announcement, get blogs and press releases started
- Landing page: If reprints will be contracted, then AR will initiate a Landing Page with the gated content request issue
- PMM writes and submits a blog post on the report - following the blog process for time sensitive announcements
- AR will follow the process to create a new web page. Once that page is created:
- AR adds the preliminary analyst information to the top section.
- PM/PMM adds content on the GitLab response
- AR gets the webpage link to the industry analyst firm for citations approval
- PMM requests a slot on the Sales Enablement calendar to discuss the report results and the web page with sales
Once the report is published by the industry analyst firm:
- AR posts the results/summary on the What’s Happening at GitLab page with either an internal link or a link to the reprint
- AR sets up an inquiry with the industry analyst firm to discuss the results of the report and answer questions for PM/PMM/TMM
- AR adds the link to the spreadsheet of sales report
- AR adds the report to the appropriate Use Case resource page(s)
Accessing analyst reports
Most analyst companies charge for access to their reports.
- If GitLab purchases reprint rights to a report, then that link will be available here, on the Analyst Research web page, and on the relevant product page. Reprint rights are the rights to share the link to the report - these generally last six months to one year.
Analyst reports that can help you deepen your knowledge
Forrester Total Economic ImpactTM of GitLab
In 2020, GitLab commissioned Forrester Research to create a Total Economic Impact (TEI) study on GitLab. According to Forrester, “The TEI methodology quantifiably measures the business value of an IT decision or project. TEI is composed of four main elements with associated tools and methodologies for quantification. Individually, each provides only a piece of the decision-support puzzle. Together, they provide a holistic tool for assessing and justifying IT investments.”
In Forrester’s methodology, the four main elements of the TEI are:
-
Benefits - measure financial impacts of positive business results.
-
Cost - measures the negative impact on IT and the business.
-
Risk - quantifies the impact of inherent uncertainties.
-
Flexibility - monetizes the value of future options.
Click here to learn more about the TEI, how to access it, and how to use it with customers and prospects.
Additional reports to aid Sales can be found here.
This is a list of analyst resources that may be useful for deeper dives into the topics covered in SDR Enablement conversations. Please do not share these documents outside of GitLab. They are for your personal use only. Thank you.
Enterprise IT Roles This is the Forrester report Tina referenced in the SDR Enablement or Enterprise IT Roles part 1.
Digital Rewrites The Rules Of Business: The Vision Report In The Digital Business Playbook, February 26, 2018 This Forrester report talks about changing IT roles.
GitLab commissioned Forrester Consulting to conduct a Total Economic Impact™ (TEI) study examining the potential return on investment (ROI) enterprises may realize by using GitLab.
GitLab customers were interviewed and related data was collected independently by Forrester Consulting in this process. The data collected, resulting model, and study itself was reviewed independently by Forrester Research analysts. GitLab stakeholders were also interviewed as part of the data gathering and review process.
The purpose of a briefing is to inform or educate analysts about something we are doing. The majority of the time, GitLab is expected to be presenting information, usually through presentations and demos, along with some Q&A time for analysts to get additional clarity or further explore a topic. Some industry analyst firms, like Gartner, will generally not provide feedback in a briefing and will prefer to do that in a follow-on inquiry as their feedback and advice is a core component of their commercial service offering.
How We Conduct Industry Analyst Inquiry Using inquiry with industry analysts Inquiry is about a two-way dialogue on a particular topic that GitLab initiates. Appropriate topics for an inquiry include: Asking about a market Getting feedback on something we are doing (e.g. product vision page, competitive document, presentation, market positioning etc.) Asking about what customers are bringing up in inquiry Ask about upcoming research (e.g. a forthcoming Wave or MQ, or area of focus) Asking opinion on something a competitor is doing or has announced Prepare or get feedback from a GitLab briefing and/or demo Inquiries generally last 30 minutes and are usually conducted by videoconference.
