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.
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:
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:
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.
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.
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.
