founder-led-sales について
技術系創業者が初期顧客への営業を自ら行い、再現可能な営業プロセスを築くためのスキルです。顧客発見、デモ、買い手への価値説明、次の行動の設定を扱います。
主な機能
- 01商談に必要な役割と条件の特定
- 02利用状況から見込み客を探す
- 03質問を通じたニーズ発見
- 04顧客の用途に沿ったデモ
- 05買い手への事業価値の説明
- 06社内提案者向けの営業資料作成
活用シーン
- 01無料ユーザーは多いが有料化しない状況
- 02創業者が初めて営業通話に臨む場面
- 03買い手の保留で商談が停滞する状況
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ aidevgtm/ gtm-cofounder --skill founder-led-salesインストール後、Claude Code で/founder-led-salesを入力して読み込まれたか確認します。
詳細
創業者主導の営業(最初の顧客は自分で獲得する)
あなたが売れるようになる前に、誰かが売ることはできません。最初の10件の成約は採用の問題ではなく、実際に何を誰に売っているのかを学ぶためのものです。営業の流れが繰り返せるようになるまで、最初はうまくいかなくても自分で取り組みましょう。
こんな場合に使います: 開発者には好評で無料プランを使い続けてもらえているのに誰も支払わない、何かを売った経験がなく実際の会話になると身動きが取れなくなる、どの商談も「検討させてください」で終わる、あるいは、まだ自分でもやり方をつかめていない仕事を営業担当者に任せたくなっている場合です。
基本的な考え方
market-to-devs-sell-to-buyersでは、誰に売るか(導入するのは開発者で、支払うのは上司)を説明しました。pricingでは価格を決めました。ここでは、技術系の創業者に誰も教えてくれないこと、つまり実際に売ることを扱います。しかも、押し売りをするわけではありません。開発者向けツールをうまく売るには、ニーズを探り、推進役が予算を確保できるよう支援します。誰かに嘘を信じ込ませるのではなく、すでに課題を抱えている人を見つけ、安心して導入を決められるようにするのです。
すべての基本となるルールは一つです。営業の流れが繰り返せるようになるまで、自分で取り組みましょう。 まだ確立できていない営業の流れを、外部に任せることはできません。最初の商談で営業担当者を雇う創業者は、まだ存在しない仕事で失敗する人を雇っているのです。
実際の商談には必ず4つの要素があります
どれか一つでも欠けていれば、それは商談ではなく、単なる会話です。何が欠けているのかを見極めるのがあなたの仕事です。
- 推進役。 製品を使い、気に入り、社内で導入を推し進めてくれる人です。通常は、製品を導入した開発者です。
- 購入者。 予算を持つ人です。推進役とは別の人であることもよくあります。
- コストの伴う課題。 「これはいいですね」ではなく、今まさにお金、時間、またはリスクの損失につながっている問題です。
- 導入のきっかけ。 来四半期ではなく、今行動する理由です。インシデント、監査、期限、スケール上の限界などです。
営業の流れ
1. すでに関心を示している人から始めます。 知らない人に手当たり次第に連絡してはいけません。最初の顧客は、自社の利用データの中に隠れています。無料プランで3席利用しているチーム、4件の課題を報告した人、利用上限に達したアカウントなどです。彼らはすでに課題を示しています。
2. 一斉送信ではなく、創業者らしい連絡をします。 気づいた具体的な点について、実在する相手に短く自然なメッセージを送ります。千人にそのまま送れてしまう内容なら、送らないでください。
3. 最初の通話は売り込みではなく、ニーズの把握です。 自分が話すのは30%、相手の話を聞くのは70%にしましょう。何に使っているのか、以前はどうしていたのか、その課題によってどれだけの損失が生じているのか、ほかに誰が困っているのか、誰が予算を管理しているのかを把握します。創業者は早く話しすぎたり、話しすぎたりしがちです。最も的確な質問をする人が会話の主導権を握ります。
4. 機能一覧ではなく、相手のユースケースをデモします。 相手のデータを使って、相手の業務を製品でどう進められるかを見せ、成果を実感できるところまで導きましょう(time-to-first-valueを参照)。機能をひと通り紹介するだけではデモになりません。「この問題をこう解決できます」と具体的に示すことがデモです。
5. 開発者ではなく、購入者にとっての価値を伝えます。 開発者が実感するのは節約できた時間です(クロノス)。購入者が予算を承認するのは、その成果があるからです。リリースサイクルを取り戻すこと、インシデントを回避すること、コンプライアンス要件を満たすこと、競合に勝たれるのを防ぐことなどです(カイロス)。開発者の好意を、上司が説明できるビジネス上の成果に置き換えましょう。
6. 推進役が社内で売り込めるよう支援します。 導入が決まる場に、あなたが同席できることはほとんどありません。推進役が上司に説明できるよう、1段落のビジネス上の根拠、価格、そして「なぜ今なのか」への答えを渡しましょう。これがミドルアウト型の進め方です。熱意ある開発者と、ROIを理解した購入者を結びつけます。
7. 必ず具体的な次のステップと日付を決めて終えます。 こうすれば、話が停滞する前に防げます。
「検討させてください」は反論ではありません
次のステップが決まっていないか、こちらが聞き出せなかった懸念があるということです。そのまま受け入れて立ち去ってはいけません。穏やかに尋ねましょう。「もちろんです。前に進むと決めるために、何を確認できればよいでしょうか?」そうすれば、本当の障壁(予算、関係者、足りない機能、タイミング)がわかり、実際に対処できます。曖昧な「後で決めます」は、原因をまだ特定できていない「いいえ」です。
知っておくべき目安
- 最初の有料顧客をおよそ10〜20社獲得するまでは、自分で取り組みましょう。 あるいは、うまくいく方法を書き出して、繰り返し実行できるようになるまで続けましょう。採用を検討するのはその後です。
- 複数の関係者とつながりましょう。 推進者だけに頼る取引は不安定です。予算を持つ人と話していないなら、取引があるのではなく、ファンがいるだけです。
- 次のステップがなければ、取引はありません。 具体的なアクションと日程を決めずに、営業の会話を終えてはいけません。
- 恐れから値引きしないでください。 価格への抵抗は、価値について話し合うきっかけであり、折れる理由ではありません(
pricingを参照)。 - 話しすぎないでください。 ニーズの聞き取りで顧客より多く話しているなら、それは営業ではなく、売り込みです。
もっともらしく見える失敗
- 早すぎる営業担当者の採用。 自分で理解できていない営業の進め方を、他人に任せることはできません。最初の取引を通じて、何を売っているのかがわかります。
- 質問せずに売り込むこと。 創業者は製品の話から始めがちです。優れた営業担当者は質問から始め、顧客自身に購入したいと思ってもらいます。
- 推進者に売り込んで、それ以上進めないこと。 推進者が製品を気に入っていても、契約を締結できるとは限りません。購入担当者にたどり着く必要があります。
- デモで機能を一つずつ紹介すること。 すべてを見せても、何も伝わりません。顧客の課題が解決されるところを見せましょう。
- 「検討します」を前向きな返事と受け取ること。 それは、理由がわかっていない「いいえ」です。立ち去る前に、実際の障壁を明らかにしましょう。
- 利用状況と売上を混同すること。 無料ユーザーが1万人いても、購入担当者との会話がゼロなら、成長の兆しではなく、人気のある無料プランにすぎません。
- 料金を請求することに引け目を感じること。 価値を提供するなら、その価格は妥当です。価格をためらう創業者は、購入担当者にも値下げをためらわないよう仕向けてしまいます。
次の30分でやること
- 利用データを開き、もっともエンゲージメントの高いアカウントを5つ書き出します(シート数、利用量、報告された問題の多さで判断します)。それらが最初の営業電話の相手です。
- 最有力のアカウントについて、推進者、購入担当者、コストを伴う課題、きっかけの4つを埋めます。欠けているものを記録します。
- その推進者に向けて、気づいた具体的な事柄に触れる、短く人間味のあるメッセージを一つ書きます。テンプレートは使いません。
- 何かを見せる前に尋ねる、ニーズ把握の質問を5つ作成します。
- 購入担当者がお金を払うであろうビジネス上の成果を一つ決め、1文で表現します。
実際の開発者向けツールのGTM経験をもとに、Adam Frankl(The Developer-Facing Startup)とJakub Czakon(markepear.dev)のフレームワークを取り入れています。 取引がなかなか進まず、実際の営業電話に同席してくれる人が必要なら、LinkedInからご連絡ください。