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 products, 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 Conduct Industry Analyst Briefings
How We Conduct Industry Analyst Briefings
How We Conduct Industry Analyst Inquiries
How We Conduct Industry Analyst Inquiries
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 comparison research
-
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 comparison research
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.
This Forrester report talks about changing IT roles. They predict that key roles will become increasingly strategic and externally focused. They also believe that many of the roles, such as architects and developers, will require increased business knowledge, consulting skills, and responsibilities that span the enterprise rather than a narrow functional area, technology, or business unit. Agile methods and DevOps teams will be the defaults, and DevOps teams combined with Agile methods will become the accepted means of building capabilities.
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. There are also other analyst firms that are more than happy to provide feedback they might have during the briefing itself.
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. AR will either schedule a zoom call or the analyst will provide a link to Webex for example.
- Questions for an inquiry should be prepared in advance. If the discussion is exhausted before 30 minutes, it is acceptable to end the call early. If more time is needed, it is okay to agree with the analyst to schedule a follow-up inquiry.
- The same inquiry can be posed to multiple analysts and/or to multiple firms if one is looking for a range of feedback.
How to request and participate in an analyst inquiry
- All inquiries will be initiated by the Analyst Relations department. If you would like to schedule an inquiry, please create an issue in the project gitlab.com>marketing>product marketing and use the template AR-ResearchRequest and fill out the relevant parts for your inquiry.
- Once AR has booked the inquiry, you will receive an invite with a meeting notes attached. Before the inquiry, you are expected to go into the meeting notes and update the questions space with 3-5 questions you think you would like to ask. This is also the document where you will record notes and key takeaways at the end of the call.
- At the time of the inquiry, please connect to the videoconference and open the notes document so you are ready to begin. AR will introduce the attendees to each other and set the stage for the inquiry topic. Once that is done, AR will hand the call over to the inquiry initiator, who will direct the conversation.
- The AR team has created a slack channel #ar_chat which is for the team on the call to use as a background communication channel during the inquiry to ensure productive use of the interaction.
- If you are a secondary participant on the call, please use the #ar_chat channel in slack or the document to pose additional questions. The AR team member may call on others to verbalize questions if that is appropriate. Please note, some analyst companies only allow one person to speak and others technically are background only.
- Once the inquiry is finished please add key takeaways to the section below questions in the meeting notes document.
- If a debrief is required, it may be mentioned in the slack channel and those with time can join. This is not required nor always possible, but it is encouraged when necessary.
AR - How to set up an analyst inquiry
- Inquiry requests should come via an issue under AR-ResearchRequest
- Clarify that the request is clear. If not, use the issue or slack to get clarification of what the requestor is looking for. Clarify whose attendance is mandatory and whose is optional.
- If the request involves:
- Gartner or Forrester, please use the form on their website for inquiry.
- IDC, please reach out to Maggie Margossian to help with scheduling. Her email is mmargossian [at] idc [dot] [com]
- 451, please reach out to Christina Lamb to help with scheduling. Her email is christina.lamb [at] 451research [dot] [com]
- Redmonk, please reach out to Juliane Leary to help with scheduling. Her email is jleary [at] redmonk [dot] [com]
- For Gartner or Forrester you will receive a link to the calendar for scheduling. Load that calendar in your browser and compare it to the Google calendar to find 30 minutes that works for all required team members. Once you select a date/time, Gartner or Forrester will send a follow-up email with all the information.
- For IDC/451/Redmonk this will involve swapping potential dates and times until a match is found. You can also call if that is convenient.
- Once you receive a confirmed date/time from the analyst firm, go into the Google calendar and create a new appointment. We cannot use the invite the analyst company sends. A separate invite must be created by AR for internal GitLab folks. Forwarded emails from analyst companies do not always show up on others’ Google calendars.
- The title naming convention should be Inquiry - analyst firm - topic and if it is Gartner or Forrester, the reference ID they provide for this transaction. (e.g. Inquiry - Gartner - Monitor Vision Doc Review (Ref# 12422433))
- For Location please specify a GitLab Zoom link or write in “Gartner Webex” or “IDC Bluejeans” etc.
- Please place this on the Analyst Relations calendar, not your personal calendar
- The first line of the notes should be “Meeting Notes” with a link to the meeting notes
- After a separator please put the videoconference details in.
- Please add internal guests and specify which might be optional. Do not send the invite yet. These are nested procedures.
- Create the Meeting Notes
- Go into Google Drive to Analyst Relations>analyst-firm-name-folder>Meeting Notes
- If possible find another meeting notes using the same analyst, or pick the most recent page, open it and make a copy of the file
- Rename the new file using the date - analyst name - topic
- Make sure the analyst bio reflects the correct analyst - if not, go to the analyst firm web page and link the correct bio
- If there are other links to update, please do so. Other links may include:
- a link to the issue for Research Request
- a link to any other issue that might have generated the inquiry
- a link to any documentation to be referenced in the inquiry (such as a vision page or competitive document)
- Update the list of GitLab attendees
- Update the Purpose of Inquiry section - this should be brief and can be copied from the Research Request issue
- Clear out the space for main questions
- Clear out the space for key takeaways and update DRI (directly responsible individual) to name of inquiry requestor
- Do not close out this document yet. These are nested procedures.
- Create the Inquiry Issue
- Go to gitlab.com>product marketing> and start a new issue, use the issue template AR-inquiry
- Fill it out. Use GitLab handles for attendees. Use date format for inquiry date: year-month-day
- Go back to Google Drive to the Meeting Notes and hit “share” get a copy of the document link and paste that in the Meeting Notes section
- Copy any links to supporting documentation that may be relevant such as a link to a web page or document
- MARK ALL ISSUES CONFIDENTIAL - Inquiry with Industry Analysts typically involve non-public, proprietary intellectual property and/or other confidential information and we must do our part to keep it that way.
- Use the date of the inquiry for the Due date
- Click “Submit issue”. Once the issue is created, assign the inquiry requestor to the issue
- If there are related issues, go to that section and add them.
- Research Request issue
- Other inquiries on the same topic if this is a series
- Link to the MQ/Wave Issue or other related research
- Copy the link to the issue in the browser bar and return to the Meeting Notes page - you are done with the issue for now.
- Update the Inquiry Issue link in the Meeting Notes page.
- Click the “Share” button and make a copy of the Meeting Notes page, Check to make sure that sharing/access permissions are appropriately set to GitLab internal access - see previous reference to keeping related issues marked CONFIDENTIAL. You are done with the meeting notes for now.
- Go back to the calendar invite and add the link to where you have written “Meeting Notes”.
- Check through the invite to make sure everything is accurate then send it off.
- RECOMMENDED: Stay hydrated, keep your favorite beverage at hand and full!
- On Videoconferencing for inquiries:
- Gartner and Forrester currently and consistently use Webex to deliver their interactions, including inquiry. Either Gartner or Forrester will provide a Webex link as it confirms the inquiry. You must use this. Please remind GitLab team members of the need to use the analyst company Webex in advance if they are participating and/or planning to demo something. In our experience GitLab team members may require a little extra time to download and install Webex software and/or updates, test that all equipment is functioning with Webex, and otherwise adjust to the Webex service performance which also in our experience has not been as consistent as Zoom.
- IDC/Redmonk/451 are usually ok with using a GitLab-provided Zoom. Sometimes they also provide their own Zoom links Please check with any new analyst that this is okay. If we do use a Zoom, we need to send that to the scheduling entity and they will update the analyst’s internal invitation.
Last modified September 27, 2024:
Shorten long headings (48bcc56d)
