Industry Analyst Briefings at GitLab

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.

In either case, your GitLab Industry Analyst Relations team is ready to answer any questions you might have and if you would like to brief an analyst please click here and fill out this request form.

Types of briefings

There are several different, yet common types of briefings that the industry analyst relations team will organize and help you deliver. IAR will create a calendar year epic for each of these three types of briefings. Each briefing topic will be its own sub-epic. Each analyst company will then have its own sub-epic (Gartner) or issue. Please note all briefings are confidential epics and issues. The three types of briefings are:

Announcement briefings

These are briefings intended to familiarize analysts with an event or one-time change. Each announcement will have its own briefing subepic. The overall epic sits at the highest GitLab level because announcements may involve issues from multiple groups in GitLab that use different projects. They should be started, if not finished before the date of the announcement itself and may also prepare analysts to speak to their clients (end users, buyers, investors, etc.) and/or press about the announcement. Examples of announcement briefings include, but are not limited to:

• Acquisition
• Price or GitLab-level product change
• New executive
• Technology partner announcement

Use case or solution updates

Use case-centric briefings have an external focus, framed in the context of market and/or customer behavior. These solution-based updates are currently the primary means by which we keep the industry analsyt community apprised of GitLab’s latest functional enhancements. The overall epic sits at the Product and Solution Marketing level, since Use Case work is at that level too. Use Case briefings are ongoing, sharing updates on GitLab’s go-to-market approach through use cases. These briefings have a similar structure across use cases with shared content as well as individual use case content. Updates to information initially shared in an annoucement briefing should be incorporated into appropriate use case presentations for future briefings. IAR is DRI for the first half of the briefing deck - the content that stays the same across use cases. The PMM who is DRI for the specific use case will also be DRI for the second half of the briefing deck, collaborating with PM and TMM.

Product section, release or channel & alliance updates

This class of briefing has an internal focus, meaning we are framing our updates in the context of GitLab. These are briefings that focus on one or more sections or stages, or are updates for channel and alliance analysts. Because these briefings cover multiple business units, this epic will sit at the highest level of GitLab, like the announcement briefings. These may also be used for product release updates done on a quarterly or annual basis. The DRI for these briefings is the PM, Channel Marketing or Channel Sales DRI who owns the business.

Analyst-requested briefings

These briefings are generally set up in response to an inbound analyst request e.g. in support of comparative research or to inform an analyst’s response to a client inquiry they received. These briefings will be worked through individual issues as they are ad hoc and focused on the analyst and their need rather than a regular GitLab cadence.

Briefing mechanics

• Briefings can last 30 or 60 minutes minutes, at the analysts’ discretion, and are usually conducted by videoconference. IAR will either schedule a Zoom call or the analyst will provide a link to their videoconference software. Gartner and Forrester tend to use Webex. IDC, 451 and Redmonk are all generally available for a GitLab Zoom.
• In contrast to analyst inquiries, which are an entitlement of research seats purchased, briefings are available to clients and non-clients alike in an effort for analyst firms to maintain both the quality of their advice and their objectivity. As such, analysts will tend to accept briefing requests when the topic aligns with their research coverage area(s), but have the option of politely declining if the topic is not aligned with their client needs or interest.
• Briefings can include multiple analysts from the same firm, as schedules allow, or scheduled over several calls to accommodate different time zones, focus areas, etc.
• Generally speaking, analysts (especially from Forrester and Gartner) will not offer feedback during briefings, with firm policy requiring GitLab to schedule inquiry calls in follow-up to get feedback and advice on positioning, strategy, etc.