GitLab における業界アナリストブリーフィング
ブリーフィングの目的は、私たちが行っている何かについてアナリストに情報を提供することまたは教育することです。ほとんどの場合、GitLab はプレゼンテーションやデモを通じて情報を提示することが期待されており、アナリストが追加の明確化を得たり、トピックをさらに探求したりするための Q&A 時間も含まれます。Gartner などの一部の業界アナリスト会社は、一般的にブリーフィングではフィードバックを提供しません。彼らは、フィードバックとアドバイスが商業サービスの中核となる要素であるため、フォローアップのインクワイアリでそれを行うことを好みます。ブリーフィング自体の間に持っているかもしれないフィードバックを提供することを喜んで行う他のアナリスト会社もあります。
いずれの場合も、GitLab 業界アナリストリレーションズチーム は、お持ちの質問に答える準備ができており、アナリストにブリーフィングしたい場合は、こちらをクリック してこのリクエストフォームに記入してください。
ブリーフィングのタイプ
業界アナリストリレーションズチームが組織し、提供を支援するブリーフィングには、いくつかの異なるが一般的なタイプがあります。IAR は、これら 3 つのタイプのブリーフィングのそれぞれに対して、暦年エピックを作成します。各ブリーフィングトピックは、それ自体のサブエピックになります。各アナリスト会社は、独自のサブエピック (Gartner) または Issue を持ちます。すべてのブリーフィングは機密のエピックと Issue であることに注意してください。3 つのタイプのブリーフィングは:
アナウンスメントブリーフィング
これらは、イベントまたは一回限りの変更にアナリストを慣れさせることを目的としたブリーフィングです。各アナウンスメントには独自のブリーフィングサブエピックがあります。アナウンスメントは異なるプロジェクトを使用する GitLab の複数のグループからの Issue を含むことがあるため、全体的なエピックは GitLab の最高レベルにあります。これらは、アナウンスメント自体の日付までに開始されるべきで、終了していなくても、アナリストがアナウンスメントについて彼らのクライアント（エンドユーザー、バイヤー、投資家など）および/またはプレスに話す準備をするためにも使用される可能性があります。アナウンスメントブリーフィングの例には、以下のものが含まれますが、これらに限定されません:
- 買収
- 価格または GitLab レベルの製品変更
- 新しいエグゼクティブ
- テクノロジーパートナーアナウンスメント
ユースケースまたはソリューションの更新
ユースケース中心のブリーフィングは、市場および/または顧客行動の文脈で枠組みされた、外部に焦点を当てたものです。これらのソリューションベースの更新は、現在、GitLab の最新の機能拡張を業界アナリストコミュニティに伝える主要な手段です。全体的なエピックは、ユースケースの作業もそのレベルにあるため、プロダクトおよびソリューションマーケティングレベルにあります。ユースケースブリーフィングは継続的で、ユースケースを通じて GitLab の Go-to-Market アプローチに関する更新を共有します。これらのブリーフィングは、ユースケース全体で類似した構造を持ち、共有コンテンツと個別のユースケースコンテンツを持っています。アナウンスメントブリーフィングで最初に共有された情報の更新は、将来のブリーフィングのために適切なユースケースプレゼンテーションに組み込まれるべきです。IAR は、ブリーフィングデッキの前半（ユースケース全体で同じままのコンテンツ）の DRI です。特定のユースケースの DRI である PMM は、ブリーフィングデッキの後半の DRI でもあり、PM および TMM とコラボレーションします。
プロダクトセクション、リリース、またはチャネル & アライアンスの更新
このクラスのブリーフィングは内部に焦点を当てており、つまり、私たちは GitLab の文脈で更新を枠組みしています。これらは、1 つまたは複数のセクションまたはステージに焦点を当てるブリーフィング、またはチャネルおよびアライアンスアナリスト向けの更新です。これらのブリーフィングは複数のビジネスユニットをカバーするため、このエピックはアナウンスメントブリーフィングのように、GitLab の最高レベルに位置します。これらは、四半期または年次に行われる製品リリース更新にも使用される可能性があります。これらのブリーフィングの DRI は、ビジネスを所有する PM、Channel Marketing、または Channel Sales DRI です。
アナリスト要請のブリーフィング
これらのブリーフィングは一般的に、インバウンドのアナリストリクエスト（例: 比較リサーチをサポートするため、または受け取ったクライアントインクワイアリへのアナリストの応答に情報を提供するため）に応じてセットアップされます。これらのブリーフィングは、定期的な GitLab のケイデンスではなく、アナリストとそのニーズに焦点を当てたアドホックなものなので、個別の Issue を通じて作業されます。
ブリーフィングのメカニズム
- ブリーフィングは、アナリストの裁量で 30 分または 60 分続き、通常はビデオ会議で実施されます。IAR は Zoom コールをスケジュールするか、アナリストがビデオ会議ソフトウェアへのリンクを提供します。Gartner と Forrester は Webex を使用する傾向があります。IDC、451、Redmonk はすべて、一般的に GitLab Zoom で利用可能です。
- 購入されたリサーチシートの権利であるアナリストインクワイアリとは対照的に、ブリーフィングは、アナリスト会社がアドバイスの品質と客観性の両方を維持しようとする努力で、クライアントと非クライアントの両方に利用可能です。そのため、アナリストは、トピックが彼らのリサーチカバレッジエリアと一致する場合にブリーフィングリクエストを受け入れる傾向がありますが、トピックがクライアントのニーズや興味と一致しない場合は丁寧に断るオプションを持っています。
- ブリーフィングには、スケジュールが許す限り同じ会社から複数のアナリストを含めるか、異なるタイムゾーン、フォーカスエリアなどに対応するために複数のコールにスケジュールを分けることができます。
- 一般的に、アナリスト（特に Forrester と Gartner から）はブリーフィング中にフィードバックを提供しません。会社の方針では、ポジショニング、戦略などについてフィードバックとアドバイスを得るために、GitLab がフォローアップのインクワイアリコールをスケジュールする必要があります。
