market-to-devs-sell-to-buyers について
利用者が製品を採用し、購入者が予算を決める開発者向けツールチームのためのGTMスキルです。販売モデルの選定と、開発者の社内提案を支える方法を扱います。
主な機能
- 01四つのGTMモデル
- 02開発者から購入者へのペルソナ対応
- 03アクティベーションを基準にした有料化
- 04社内提案を支える資料
- 05よくあるGTMの落とし穴
活用シーン
- 01優先するGTMモデルの選定
- 02開発者の予算申請に向けた準備
- 03有料プランを導入する時期の判断
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/market-to-devs-sell-to-buyersを入力して読み込まれたか確認します。
詳細
開発者にマーケティングし、購買担当者に売る
あなたのツールを導入する開発者が、その費用を支払う人であることはほとんどありません。開発者の心をつかみ、社内で予算を獲得するための材料を渡しましょう。
こんな場合に活用してください： スターや登録者がいて、無料プランが愛されているのに、収益がゼロの場合。
核心となる考え方（Czakon）
開発者にマーケティングし、意思決定者に売る。 開発者は評価して導入し、購買担当者（CTO／VP／調達担当者）は予算を承認します。成長の原動力は、社内で製品を売り込む開発者の推進役です。ですから、上司に賢明な選択だと思ってもらえるよう、推進役を支援するのがあなたの仕事です。
フレームワーク：効果的なGTMモデル（Czakon）
製品とICPに合うものを選びましょう。4つすべてを中途半端に実行してはいけません。
| モデル | 適している状況 | アプローチ |
|---|---|---|
| オープンソース | インフラ／開発者向けツールで、信頼性と検証可能性が重要 | OSSコア → 導入 → 有料クラウド／エンタープライズ |
| PLG／セルフサービス | 価値実現までが速く、小規模チームでは開発者が購買担当者 | 無料プラン → 利用 → 拡大 → 大口顧客には営業が支援 |
| インバウンド | 課題に関するコンテンツ／SEOで主導権を握れる | 課題を啓発 → 見込み顧客を獲得 → 育成 |
| 営業主導／ABM | ACVが高く、エンタープライズの商談が複雑で、大口顧客が少数 | 対象アカウントを指定し、開発者の推進役を通じて導入 |
ほとんどの開発者向けツールでは、PLGに、人的対応に見合うアカウント向けの営業支援を組み合わせるのが効果的です。
フレームワーク：推進役を支援する（Czakon + Frankl）
開発者が社内で上申するために必要なものを提供しましょう。
- 上司向けのKairos事例（リリースサイクルを数週間短縮、リスクを低減）。
value-prop-that-convertsを参照してください。 - 社内スレッドに貼り付けられる1ページ資料／ROIの概要。
- 購買担当者が尋ねるセキュリティ／コンプライアンスに関する回答（SOC 2、データの取り扱いなど）。CTOが本当に懸念している点に答えます。
- 同等の企業の同僚による、出典が明記された成果の証拠。
ペルソナから成約までの流れ（Frankl）： Alpha Devが見つけて推奨 → VPE／SREが実現可能性を検証 → 権限を持つCTOが予算を承認 → 調達担当者が契約条件を処理（後半、エンタープライズのみ）。複雑な商談では、それぞれにとってのメリットが必要です。ひとつのペルソナだけに注力すると、商談は順調でも意思決定に至らなくなります。
有料プランを導入するタイミングを判断するフローチャート
Has the developer hit real, repeated value (Activation)?
├─ NO → too early. Gating now kills adoption. Keep delivering value.
└─ YES → is this a small team (dev controls spend)?
├─ YES → self-serve upgrade in-product; keep it frictionless.
└─ NO → trigger sales-assist: help the champion build the internal case.
最初の100万ドルは自分で獲得しましょう。 それを達成する前に営業を引き継いではいけません。反論を身をもって経験した創業者に教えるより、営業担当者に教えるほうがはるかに難しいからです（Frankl）。
もっともらしく見える失敗
- 開発者に予算があると思い込む：Alpha Devはあなたのことを気に入っていても、支払うことはできません。
- 価値を早い段階で制限する：「なるほど」と実感する前のペイウォールは、好奇心を離脱に変えてしまいます。
- VPにいきなりコールドセールスする：推進役を飛ばしています。購買担当者が信頼するのは自社のエンジニアであり、あなたのメールではありません。
- 推進役を支援しない：開発者は購入したくても、上司に持ち込む材料がありません。
- 4つのGTMモデルをそれぞれ10％ずつ実行する：主要なアプローチをひとつ選び、注力しましょう。
次の30分でやること
- 自社のモデル（OSS／PLG／インバウンド／営業主導）と、まず注力するひとつを決める。
- もっとも満足度の高い無料ユーザーを特定する。その人が推進役です。予算承認に必要なものを上司に尋ねてもらいましょう。
- 推進役向けの1ページ資料を作る：Kairos事例＋実績＋セキュリティに関する回答。
- 有料プランに触れる前に必ず発生させるべきActivationの瞬間を定義する。
実際の開発者向けツールのGTM経験と、Adam Frankl（The Developer-Facing Startup）およびJakub Czakon（markepear.dev）のフレームワークをもとに作成。 GTMモデルの選択は、何年にもわたって影響する賭けです。相談したい方は、LinkedInからご連絡ください。