mcpField
G
gtm-product-led-growth

gtm-product-led-growth

github.com/githubマーケティング・グロース40.5k1.8k 回インストール今日更新
リポジトリ

gtm-product-led-growth について

プロダクトチーム向けに、PLG 戦略、チャネル評価、成長予測を扱うスキルです。セルフサービス型の成長が適するかを検証し、実験を再現可能なプロセスにまとめる枠組みを提供します。

主な機能

  1. 01PLG と営業主導の方式を評価
  2. 02成長施策とコンバージョンの関係を整理
  3. 03チャネルの採算性を測定
  4. 04初回価値までの時間を監査
  5. 05PLG と営業の連携を計画
  6. 06複数シナリオで成長を予測

活用シーン

  1. 01セルフサービス型成長への適性判断
  2. 02獲得チャネルのコストと継続率の比較
  3. 03チャネル拡大前の検証基準の設定
  4. 04セルフサービスから営業支援への移行計画

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/github/awesome-copilot --skill gtm-product-led-growth

インストール後、Claude Code で/gtm-product-led-growthを入力して読み込まれたか確認します。

詳細

プロダクト主導型成長

セルフサービスでの獲得と拡大の仕組みを構築しましょう。ただし、まずはPLGが自社製品に適した成長手法かどうかを見極めてください。

利用するタイミング

きっかけ:

  • 「PLGと営業主導型のどちらを構築すべきでしょうか?」
  • 「セルフサービスでの導入を促進するにはどうすればよいでしょうか?」
  • 「フリーミアムから有料プランへの転換がうまくいきません」
  • 「開発者主導の導入戦略」
  • 「どの成長チャネルに投資すべきでしょうか?」
  • 「PLGがうまくいくかどうすれば分かりますか?」

背景:

  • 開発者向けツールとプラットフォーム
  • セルフサービスの可能性があるB2B SaaS
  • デモなしでも価値が明らかな製品
  • ボトムアップ型の導入
  • 成長チャネルの優先順位付け

主なフレームワーク

1. PLGの現実性チェック(決断する前にテストする)

両方の成長手法を並行して実施して学んだこと:

スタートアップでよくある議論です。PLG派は「開発者はセルフサービスを望んでいる」と言い、営業派は「大企業には手厚い支援が必要だ」と言います。議論する代わりに、6か月間、両方をテストしました。同じ製品で2つのGTM手法を実施し、すべてを記録しました。

結果:

PLG:顧客数は多いものの、ACVは低め(約5,000ドル)、収益化までの時間は短く、解約率は高め。営業主導型:顧客数は少ないものの、ACVは高め(約50,000ドル)、収益化までの時間は長く、解約率は低め。顧客数が10分の1にもかかわらず、売上では営業主導型が10倍の成果を上げました。

**理由:**製品の複雑さと購入者の役職の高さが重なると、営業主導型が有利になります。この製品には、既存のインフラとの統合、チームをまたいだ変更管理、複数の関係者間での合意形成が必要でした。開発者はセルフサービスを気に入っていました。しかし、彼らは経済的な決定権を持つ購入者ではありませんでした。

PLGがうまくいく条件:

  • 最初の5分で価値が明確に分かる
  • 導入が非常に簡単
  • チームの合意がなくても、個々のユーザーが価値を得られる
  • 調達や法務上の障壁がない
  • 購入者=ユーザー

営業主導型がうまくいく条件:

  • 製品に統合やセットアップが必要
  • 複数の関係者間で合意形成が必要
  • 購入者≠ユーザー
  • 取引規模が人的な対応に見合う
  • 顧客が価値を理解するための説明を必要としている

**PLGを構築する前に、自社の成長手法をテストしてください。流行しているからという理由だけで、PLGのほうが優れていると決めつけてはいけません。**PLGは大規模な顧客獲得に効率的ですが、複雑な製品では営業主導型のほうが収益性に優れることがあります。


2. 成長の方程式(インプットとアウトプットを対応付ける)

パターン:

活動とユーザー獲得の関係を体系化すると、成長は複利的に積み上がります。「マーケティングをもっと頑張る」のではなく、具体的なインプットを測定可能なアウトプットに結び付けます。

成長の方程式の作り方:

各チャネルについて、活動(インプット)→トラフィック(アウトプット)→コンバージョンを定義します。

  • **オーガニック検索:**質の高いブログ記事を1本作成 → 月間400ユーザー → コンバージョン率5%=新規ユーザー20人
  • **有料広告:**1,000ドルを投じ、10万インプレッションに対してクリック率8%=8,000クリック → コンバージョン率X%でコンバージョン
  • **コミュニティイベント:**イベントを1回開催 → 参加者60人 → コンバージョン率35%=ユーザー21人
  • **紹介:**インテグレーションパートナー1社 → 紹介ユーザーN人 → コンバージョン率Y%でコンバージョン

重要な理由:

方程式を検証すれば、スケーリングは計算でできるようになります。「来月はユーザーをあと200人増やす必要がある」なら、「ブログ記事をあと10本作成する」または「広告費をあと5,000ドル増やす」と分かります。方程式がなければ、当てずっぽうになります。

方程式をテストする:

  1. 仮説を立てる:「Xを作成すれば、Yのコンバージョンにつながる」
  2. 小さなサンプルでテストする:ブログ記事を1本公開し、実際のコンバージョンを測定する
  3. 検証する:実際の結果は仮説と一致しているか?
  4. 確信を持って拡大する:一致していれば、インプットを増やす
  5. 一致しなければ打ち切る:4週間分のデータがあれば判断には十分

よくある間違い:

テストせずにコンバージョン率を推測する。同じチャネルから来たユーザーはすべて同じ質だと仮定する。方程式を検証する前にスケーリングする。


3. チャネルの経済性(成果の悪いチャネルを切り、成果の良いチャネルに注力する)

パターン:

どのチャネルにも経済性があります。追跡しなければ、成果の悪いチャネルに投資しすぎ、成果の良いチャネルへの投資が足りなくなります。

チャネルごとに追跡する項目:

  1. CAC: 総費用 / 新規ユーザー数
  2. コンバージョン率: サインアップ → 有料化
  3. リテンション: 流入元別の30日後、90日後のリテンション
  4. LTV: チャネルごとの顧客生涯にわたる売上
  5. 回収期間: CACを回収するまでの期間

意思決定の枠組み:

  • CAC <(LTV × 利益率)→ 積極的に拡大する
  • CAC ≈(LTV × 利益率)→ 最適化する。拡大はしない
  • CAC >(LTV × 利益率)→ 4週間以内に打ち切る

毎月のチャネルレビュー: 利益を生むチャネルはどれですか?損失を生むチャネルはどれですか?四半期ごとに予算を再配分し、成果の良いチャネルには3倍の予算を割り当て、成果の悪いチャネルは打ち切ります。

重要な洞察:チャネルによってユーザーの質は異なります

CACが安いからといって、優れたCACとは限りません。オーガニック検索では、CACが0ドルで30日後のリテンション率が85%のユーザーを獲得できる場合があります。有料検索では、CACが12ドルで30日後のリテンション率が45%のユーザーを獲得する場合があります。リテンションとLTVを考慮すると、「無料」のチャネルの価値は10倍になります。

体系的なテスト:

毎月、新しいチャネルを2つテストします。それぞれ4週間分のデータを集めます。経済性が成り立たなければ、迷わず打ち切ります。結果にかかわらず、学びを記録します。うまくいかなかったことも、うまくいったことと同じくらい価値があります。

よくある間違い:

リテンションを追跡せず、CACだけを追跡することです。ユーザーの離脱が多い安価なチャネルは、ユーザーを維持できる高価なチャネルよりもコストがかかります。


4. 初回価値到達時間(唯一のアクティベーション指標)

パターン:

ユーザーは最初の5〜10分でプロダクトの価値を判断します。すぐに「なるほど」と感じる瞬間にたどり着けなければ、離脱します。

アクティベーション監査:

  1. 新規ユーザーとして自社のプロダクトにサインアップします
  2. 初回価値に到達するまでの時間を計測します
  3. 「なるほど」と感じる瞬間までのステップ数を数えます
  4. どこで行き詰まりましたか?

初回価値到達時間が10分を超える場合、アクティベーションに問題があります。

変更前: サインアップ → メール確認 → プロフィール入力 → 設定 → ドキュメントを読む → 最初のアクション

変更後: サインアップ → サンプルデータが事前に読み込まれる → 最初のアクション(すぐに「なるほど」と感じる瞬間)

具体的な改善策:

  1. サンプルデータを事前に読み込みます。 ユーザーが見たいのは価値であり、セットアップではありません。すぐに使える例を提供します。
  2. 必須ではないセットアップを省きます。 メール確認、プロフィール、設定は、いずれも「なるほど」と感じる瞬間の後で構いません。
  3. 段階的に情報を提示します。 最初からすべての機能を見せないでください。中核となるワークフローを1つから始め、徐々に複雑さを見せていきます。
  4. 説明するより、実際に見せます。 インタラクティブなチュートリアル > 動画 > テキストのドキュメント。ワークフローを実際に操作してもらいます。

よくある間違い:

ユーザーがドキュメントを読むと思い込むことです。ユーザーは読みません。5分ほど操作してみて、何も動かなければ離脱します。


5. 5,000ドルから50,000ドルへの転換点(PLGが機能しなくなる段階)

パターン:

PLGはARRが1,000〜10,000ドルの範囲では機能します。20,000〜50,000ドルの範囲では、調達、法務、セキュリティ、複数の関係者の合意といった組織的な摩擦が生じ、販売の仕組みが機能しなくなります。

ハイブリッドアプローチ:

PLG(0〜10,000ドル): セルフサービスでサインアップ → 無料プラン → 有料プラン → クレジットカード決済 → オンボーディングの自動化

営業支援型(10,000〜50,000ドル): セルフサービスで情報を探す → 利用状況のシグナルに応じて営業が対応 → 担当者と契約条件を交渉 → 専任のオンボーディング

エンタープライズ(50,000ドル以上): アウトバウンドまたはインバウンドのリード → デモ → POC → 提案 → 法務/セキュリティレビュー → 経営幹部のスポンサー

PQLシグナル(営業に引き継ぐタイミング):

  • 利用の深さ: 毎日アクティブ、中核機能の利用、上限に近づいている
  • 拡大のシグナル: 同じ企業からの複数ユーザー、チーム機能、インテグレーション
  • 購入のシグナル: SSO/コンプライアンス/SLAのリクエスト、チーム向け料金についての問い合わせ

引き継ぎ:

悪い例:「サインアップされたのを見ました。」(唐突で、一般的で、信頼を損ないます) 良い例:「御社のチームでは、12個のリポジトリで[具体的な機能]を利用されています。[具体的な価値]の実現をお手伝いできます。15分ほどお時間をいただけますか?」(自然で、具体的で、価値を提供しています)

よくある間違い:

5,000ドル未満の案件に営業が早くから関与することです。PLGの流れを損ない、ユーザーを不安にさせます。ユーザーがサポートを必要とするまでは、セルフサービスで進めてもらいましょう。


6. 成長予測(不確実性に備える)

パターン:

予測は必ず外れます。それでも計画には価値があります。考えることを促し、説明責任を生み出すからです。

3つのシナリオをモデル化する:

ベースライン(現在の軌道が続く場合):

  • オーガニック検索:35%成長 → 新規ユーザー40K
  • 有料:横ばい → 新規ユーザー2K
  • コミュニティ:10%成長 → 新規ユーザー400
  • 合計:42.4K

上振れ(すべての成長施策を実行できた場合):

  • オーガニック:50%成長(コンテンツを3倍に) → 48K
  • 有料:支出を2倍にし、効率は同じ → 4K
  • 新施策(パートナーシップ):拡大 → 3K
  • 合計:55K

下振れ(主要チャネルが機能しない場合):

  • オーガニック:成長率0% → 26K
  • 有料:CPAが2倍 → 1K
  • 合計:27K

活用方法:

  • ベースライン目標の設定(ベースラインシナリオ)
  • ストレッチ目標の設定(上振れシナリオ)
  • エスカレーションのトリガー(下振れに達した場合は、何かを変える必要があります)
  • リソース配分(上振れを実現するには、どの投入要素を変えるべきか?)

**月次更新:**予測と実績を比較します。モデルを調整します。予測したまま放置しないでください。

よくある間違い:

すべてがうまくいくと仮定した、楽観的すぎる予測。月次で更新しないこと。予測を目標として扱うこと(予測は幅であり、単一の数値ではありません)。


7. プレイブックを文書化する習慣

パターン:

人とともに知識は失われます。目標は一度きりの成功ではなく、うまくいく方法を体系化することです。

キャンペーンや実験が成功するたびに、1ページのプレイブックを作成します:

PLAYBOOK: [Channel/Tactic Name]

Goal: [What outcome]
Steps: [Numbered, specific enough for someone unfamiliar]
Expected Output: [Specific metrics]
Metrics to Track: [How to measure]
Risks & Mitigations: [What could go wrong]
Owner: [Name]
Last Updated: [Date]

**テスト:**関与していなかった人でも、このプレイブックを実行できますか?できない場合は、曖昧すぎます。

**四半期ごとに見直します。**効果がなくなったプレイブックは削除します。変化したプレイブックは更新します。これが成長のための運用システムになります。

よくある間違い:

学びを文書化せずに実験を行うこと。仕組みを理解する前に拡大すること。成長に関する知識が一人の頭の中に閉じ込められていること。


意思決定ツリー

PLGとセールス主導型のどちらを構築すべきか?
Can users get value in <10 min without docs?
├─ No → Sales-led required
└─ Yes → Can they self-serve implementation?
    ├─ No → Sales-led required
    └─ Yes → Is buyer = user?
        ├─ No → Hybrid (PLG + sales-assist)
        └─ Yes → Pure PLG viable
このチャネルを維持、拡大、それとも終了すべきか?
CAC < (LTV × margin)?
├─ No → Kill within 4 weeks
└─ Yes → 90-day retention > 60%?
    ├─ No → Optimize (improve activation/onboarding)
    └─ Yes → Scale aggressively (3x budget)

よくある間違い

1. PLGは常にうまくいくと思い込む プロダクトの複雑さ + 購買担当者の役職の高さ = セールス主導型が有利です。決める前にテストしましょう。

2. チャネルの経済性を把握していない すべてのチャネルにCAC、リテンション、LTVがあります。追跡しなければ、状況が見えないまま進むことになります。

3. 無料プランの範囲が広すぎる、または狭すぎる 広すぎるとコンバージョンしません。狭すぎるとアクティベーションしません。10~20回の「なるほど」と思える体験を可能にしましょう。

4. 成長の方程式がない 「マーケティングをもっとやる」は戦略ではありません。チャネルごとに投入要素 → 成果 → コンバージョンを整理しましょう。

5. 検証前に拡大する チャネルを拡大する前に、4週間分のデータを集めましょう。経済性が成り立たない場合は、きっぱり終了します。

6. 成長に関する知識が一人の頭の中にある 成功した実験はすべて、プレイブックとして文書化しましょう。


クイックリファレンス

**PLGの準備状況:**10分未満で価値を実感 + セルフサービスで導入可能 + 購買担当者 = ユーザー

**成長の方程式:**活動(投入) → トラフィック(成果) → コンバージョン(チャネルごと)

**チャネルの経済性:**CAC、コンバージョン、30日/90日後のリテンション、LTV、投資回収期間 — チャネルごとに月次で見直す

**終了基準:**CAC >(LTV × マージン)→ 4週間改善を試み、その後終了

**PQLのシグナル:**利用の深さ + 拡大(複数ユーザー) + 購入意向(SSO/コンプライアンスに関する要望)

**セールスへの引き継ぎ:**10Kドル未満:PLG → 10K~50Kドル:セールス支援 → 50Kドル超:全面的なセールス対応

**予測:**ベースライン + 上振れ + 下振れを、毎月更新する


関連スキル

  • technical-product-pricing:フリーミアムの利用上限と料金の適用条件
  • developer-ecosystem:開発者向けの導入促進プログラム
  • 0-to-1-launch:PLG が拡大する前に最初の顧客を見つける

複数のプラットフォーム企業での経験に基づいています。ゼロから PLG と営業主導の施策を構築する成長チームを率い、急成長企業で成功している PLG と営業主導の仕組みの中で業務に携わってきました。この経験の組み合わせから、両方の側面を学びました。すなわち、リソースが限られ、あらゆる賭けが重要な初期段階で、こうした施策を確立するために必要なことと、成長方程式、チャネル経済性の仕組み、フリーミアムの料金適用条件、成功と失敗のすべてを実行可能なプレイブックに記録する体系的な A/B テストなど、成熟した施策が大規模に展開される姿です。理論ではなく、仕組みを構築し、実際にうまく機能した仕組みの中で業務に携わった経験から得た教訓です。

コメント