Product Marketing - ソリューション Go-to-market

Product Marketing - ソリューションとバリュープレイ

ソリューションとは、ビジネス課題を解決するために企業が購入する製品、または製品とサービスのスイートです。一般的には、対象とする領域に応じて 3 つのバケットに分類されます。

1. 市場セグメント要件（例: DevSecOps プラットフォームソリューション）。
2. 業界／業種要件（例: 公共部門、金融サービス、航空宇宙など）
3. ビジネスセグメント要件（例: エンタープライズ対 SMB）

関連するソリューションは聴衆によって異なります。

• C レベルのエグゼクティブは、組織の生産性向上、コスト削減、価値の迅速な提供 ― Command of the Message のカスタマーバリュードライバーに整合する事項 ― に役立つ、十分な資金が投じられた戦略的ビジネス施策によって特徴付けられる、広範なビジネスソリューションに関心があります。C レベルの聴衆は、組織のアジェンダ、戦略目標を設定し、主要な IT 施策に資金を提供する重要なインフルエンサーです。
• DevSecOps バイヤーは、C スイートに支援された変革的なビジネス目標を達成する方法を決定する責任を負っています。彼らは特定の DevSecOps 機能（CI など）を購入または置き換える予算を持つ可能性が高く、ディレクターや VP の多くは複雑な DevSecOps 環境をシンプル化する方法のより大きな全体像を見ています。
• DevSecOps ユーザーは、変革を実現するためにツールを使用する責任を負っています。彼らは、特定のツールが彼らの仕事をどれほど容易にし、時間をより生産的にし、コードをより安全にするかを気にします。

ソリューションとバリュープレイの接続

見込み客を広範なアイデアから具体的なアクション、予算、販売機会へと導くことが重要です。これは、コア DevSecOps GTM ソリューションを介して行います。ここでは、お客様がポジティブなビジネス成果を達成するためにどう支援するかというメッセージを明確にし、営業活動（バリュープレイと収益プログラム）とマーケティングキャンペーン（デジタル広告、メールキャンペーン、ナーチャリング、イベントなど）を、最大の成功確率を持つ機会に集中させるよう整合させます。ソリューションフレームワークを提供しバリュープレイにおけるステップを捉えることで、最大のインパクトのためにマーケティング支出を最適化するメトリクスを伴った、繰り返し可能で予測可能な販売成果を達成することを期待しています。

GitLab の顧客は、当社の営業チームと直接連携することで、またはチャネルパートナーやテクノロジーアライアンスパートナーと連携することで、これらのソリューションを購入できます。パートナーは、DevSecOps ソリューションを提供するサービスを提供することで GitLab の顧客を支援します。コア DevSecOps ソリューションと、それぞれが支援するバリュープレイには以下が含まれます:

• Software Security
• Software Compliance
• Automated Software Delivery
• そして、これらを総合した DevSecOps プラットフォーム

どのペルソナにどのソリューションを使うか

コア DevOps ソリューションは、HighSpot の Solutions Selling を通じて営業に伝達されます。

どこにどのソリューションを適用するかを理解するには、ペルソナ／聴衆を考慮する必要があります。以下のマトリックスは、推奨される出発点として、どのペルソナに対してどの会話が最適かを示しています。

ユースケース

コア DevOps ソリューション内には、ユースケースがあります。これらのトピックは、市場でホットなもの（セキュリティなど）や、GitLab に関連するユースケース（SCM など）である場合があります。これらは、見込み客との会話に関心を惹くことがあります。これらの機能についての会話は、バリュープレイに整合した広範な会話への扉（楔）を開く可能性があります ― 通常、プラットフォームソリューションまたは Automated Software Delivery ソリューションにつながります。

例:

• Source Code Management（SCM）
• Continuous Integration
• GitOps

カスタマーサクセスマネージャー（CSM）は、ユースケース採用によって測定される、既存顧客の GitLab ユースケース採用拡大を目標としています。ユースケースをステージにマッピングすることで、CSM はどのユースケース資料を適用するかを把握できます。

ユースケースの DRI と主要リンク

バイヤーズジャーニーと典型的なコラテラル

見込み客は、解決すべき特定の問題があると判断した時から、通常はバイヤーズジャーニーのいくつかのステージを経て、最終的に GitLab を選択することを期待されています。

バイヤーズジャーニー ― 聴衆

バイヤーズジャーニーに加えて、組織内には異なるニーズを持つ異なる聴衆が異なるタイミングで存在します。バイヤーズジャーニーの一般的なモデルは、購買サイクルの異なるステージで必要とされる種類のコラテラルを概説します。コラテラルを作成する際には、聴衆のニーズを理解することが極めて重要です。エグゼクティブ、マネージャー、個別貢献者は、彼らの特定の業務をサポートするために異なる情報を必要とします。

• エグゼクティブは、戦略目標をサポートするために、ビジネス価値、リスク、コスト、インパクトに関する情報を必要とします
• マネージャーは、計画、正当化、移行の詳細を駆動するために、より詳細な情報を必要とします。
• コントリビューターは、それがどのように機能するか、なぜ良いのか、そして将来彼らをどう支援するかについての技術的な詳細を必要とします。

バイヤーズジャーニーは、開発者やチームが日常の課題に対するソリューションを探し始めるときにも始まる可能性があります。スタッフが課題を特定し、変化のチャンピオンとなる場合、取り組みを開始します。それから、彼らはマネージャーやエグゼクティブに、現状に代わる選択肢を検討する必要性を納得させます。

市場要件

ソリューション「市場要件」は、ソリューション（製品または複数の製品）がサポートする必要のある広範な機能です。各 GitLab DevOps ソリューションには、約 8〜12 の市場要件が定義されているべきです。

製品用語では、市場要件は Jobs to be Done（JTBD） の概念に類似しています。両方とも、エンドユーザーまたは顧客が達成したい何かを表します。JTBD と同様、市場要件は機能ではなく、市場で成功するためにある特定のソリューションが含む必要のある「要件」を示すより高レベルな機能のセットです。例えば、特定の製品には市場要件を満たすのに役立つ機能が含まれていますが、機能自体は市場要件として認められません。JTBD は非常に粒度が細かく具体的である傾向があります。特定のステージの JTBD のリスト は長くなる可能性があり、理論的には終わりがありません。市場要件は、要件の総数を小さく消費可能に保つために意図的に広範です。特定の市場要件は多数のJobs to be Doneで構成されることが期待されます。

Command of the Message 用語（社内限定）で営業が使用するものでは、これらは「Required Capabilities」と同じものではありません。COTM の「Required Capabilities」は非常に狭く、GitLab に整合する特定のバリュードライバーに焦点を当てています。**「市場要件」**は、特定のユースケースに対して包括的であり、市場（アナリスト、ベンダーなど、GitLab 固有の機能ではない）によって定義され、市場の「アウトサイドイン」パラダイムを通して見られることを意図しています。

業界アナリストが調査を行うとき、彼らは市場要件モデルを使用して競合ソリューションを評価します。典型的なアナリストレポートには、ベンダー間の測定と比較に使用される市場要件モデルに 40〜60 の機能のセットが含まれている場合があります。Go-to-market の取り組みのために、私たちはユースケースごとに 8〜12 の主要市場要件に機能をバケット化します。

市場要件のダウンストリームインパクトは以下のとおりです:

• テクニカルデモは特定の市場要件を示すことに基づいています
• 市場全体（複数のベンダー、複数の製品）の比較は市場要件から駆動できます
• 特定の市場要件の価値を強調する ROI モデルを構築できます。

ページのソースコードを見る - ページの編集 - please contribute.