最初の顧客は営業先じゃない ― SaaS立ち上げを救うデザインパートナー

皆さんこんにちは、タカシです。今日は SaaS 立ち上げ期の超重要テーマ、デザインパートナーです。最初の顧客って、売上をくれる相手というより、事業の進む向きを決める共同検証者なんですよ。

かなり危ないです。初期顧客の声をそのまま全部プロダクトにすると、受託開発みたいな SaaS になりやすい。一方で、正しい相手を選べば、課題の本質も価格感も導入障壁も一気に見えてきます。

その通りです。特に B2B SaaS は、導入の手間、業務フローの変更、社内稟議、オンボーディングまで含めて価値が決まります。だから最初の顧客と何を学ぶかが、そのまま PMF までの速度を左右します。

いい視点ですね。今日は定義、選び方、成功事例、失敗パターン、そして明日から使えるアクションまで一気に整理します。SaaS を立ち上げる経営者なら、かなり実務に直結する話になるはずです。

まず定義です。デザインパートナーとは、まだ粗いプロダクトを受け入れながら、定期的に業務フィードバックを返し、場合によっては事例公開や紹介まで協力してくれる初期顧客のことです。

そこが大事です。SaaStr では、初期のデザインパートナーには 30〜50% の期間限定割引や優先対応を与える代わりに、四半期ごとのフィードバックや事例協力を明文化すべきだと整理しています。

まさにそれです。無料ユーザーは感想をくれても、必ずしも本気で困っているとは限りません。ところが払う意思がある顧客は、業務に刺さっているからこそ時間も使うし、改善要求も鋭くなります。

ここも SaaStr の示唆が明快で、3社から5社程度に絞れ、です。初期は一社ごとの学びが重いので、多すぎると要望を処理するだけで終わります。深く伴走できる数に制限するのが経営判断なんですね。

では、誰を選ぶか。条件は大きく4つです。課題が強い、業務フローが他社にも近い、導入の意思決定者か強い推進者がいる、そして改善の対話に時間を割いてくれる。この4つがそろう相手を狙います。

その通りです。大手は魅力的ですが、意思決定も導入も遅く、個別要求も増えやすい。初期は「名前が有名」より「痛みが深く、反応が速く、次の顧客にも近い」相手を優先したほうが再現性を作れます。

OpenView の初期顧客の話でも、焦点を狭くしろという助言が繰り返し出てきます。たとえば「小規模事業者」では広すぎる。「Shopify で年商 0〜100 万ドルの店舗」のように、具体的に切れ、と。

さらに重要なのは、最初から自社プロダクトの説明をしすぎないことです。OpenView の顧客開発論でも、創業者は売り込む前に痛みの現れ方を聞けとあります。欲しいのは称賛ではなく、現場の不便の言語化なんです。

ここでかなり示唆の大きい事例が ServiceTitan です。住宅設備の現場業務 SaaS を立ち上げた同社は、業界団体 Nexstar の会員企業にボトムアップで入り込み、正式提携前にすでに20社を獲得していました。

そうです。Bessemer のメモでは、その後に Nexstar の正式パートナーになってから、同じ会員基盤で78社まで拡大しています。さらに、業界団体経由の顧客が全顧客の50%を占め、平均でより大きい約2,500ドル MRR の案件だったとあります。

経営的に見ると、ここで効いているのは顧客の類似性です。同じ業界団体に属する企業は、業務フローも悩みも比較的近い。だから最初の導入で得た学びが、次の受注にもそのまま転用しやすかったわけです。

その通りです。デザインパートナーの価値は、1社の売上ではなく、次の10社に効く構造を作れるかどうかにあります。ServiceTitan は初期顧客を、参照顧客、紹介経路、そして市場理解の資産に変えたんですね。

もう一つ重要なのは、初期顧客開拓を創業者が外さないことです。Lenny’s Newsletter では、Vanta が YC の卒業生一覧を徹底的に掘り、最初の10顧客を自力のアウトバウンドで取っていった事例が紹介されています。

そうなんです。初期の営業は派手さより執着です。誰が一番強く困っているかを自分で探し、自分で断られ、自分で勝ち筋を見つける。この痛みを創業者が浴びないと、あとで営業組織を作っても再現しません。

Sprig の例も象徴的です。コールドメールから Thunkable を最初の非紹介顧客として獲得し、その1週間後に創業者自身が現場の使い勝手や不具合を一緒に潰し込みました。受注して終わりではなく、立ち上がりまで伴走したわけです。

OpenView もかなり早い時期から、創業者こそ最初のマーケターであり最初の営業であるべきだと言っています。最初の顧客との会話には、課題仮説、価格仮説、オンボーディング仮説が全部詰まっているからです。

ここからは失敗パターンです。まず一つ目は、無料ユーザーを増やしすぎること。フィードバック量は増えますが、痛みの強さも継続意思もバラバラで、ロードマップがノイズだらけになります。

二つ目は、個別要望を全部飲むことです。初期受注がありがたいあまり、相手の言う機能を全部作ると、共通課題より個社要件が勝ってしまう。SaaS ではなく、受託ソフトの匂いが強くなります。

判断基準は、その要望が次の3社にも起きるかです。同じ役職、同じ業務フロー、同じ導入文脈で再発しそうなら共通課題。そうでなければ個社最適の可能性が高い。ここを毎回、言語化してから実装判断するんです。

三つ目と四つ目は、期待値を契約化しないこと、そして導入後を軽く見ることです。値引きの期限、定例頻度、事例利用可否、初回価値到達の定義。この4点を曖昧にすると、せっかくの良い顧客が参照顧客になりません。

最後に、明日からのアクションを3つに絞ります。一つ目、強い痛みを持つ顧客候補を5社に絞る。二つ目、値引きやフィードバック義務を1枚の合意文書にする。三つ目、導入30日で出す最初の成果を決める。この3点です。

そうなんです。SaaS 立ち上げ期は、顧客を増やすことより、学習の質を上げることが先です。デザインパートナーは、その学習を圧縮してくれる存在。だからこそ、営業先ではなく共同検証相手として設計する必要があります。

皆さんもぜひ、自社の初期顧客候補を思い浮かべながら考えてみてください。その会社は、売上だけでなく、次の10社を呼び込む学びをくれる相手か。ここを問い直すだけでも、立ち上げの精度はかなり変わります。

それでは今回はここまで。タカシでした。