エンジニア向けSaaSとPLGは相性が良い
こんにちは！ひまらつです。
前回のnoteでは実際の施策例を交えながらPLG戦略を紹介しました。PLGはProduct-Led Growthの略で、マーケティングやセールスなどの機能をプロダクト中心に考える戦略のことです。
このPLGですが、エンジニアを対象とするSaaSと特に相性が良いと思っています。このnoteではその理由について書いてみます。
PLG型で伸びたエンジニア向けサービス
PLGで成長したサービスは数多く、その代表格はZoomやSlackです。エンジニア向けのものだとTwilio、Cloudflare、Datadogなどが挙げられ、エンジニアが普段使うサービスを調べるとPLG型の企業であることも多いです。
エンジニア向けのサービスは、「B2C」「B2B」と区別して「B2D（Business to Developer）」と呼ばれることもあり、少し特殊な部分があると考えられています。それはエンジニアのコミュニティ文化であったり、SDKやOSSの提供、ドキュメントがより重要な要素となるなどの違いですが、PLGはこういった性質と非常に相性が良いと思っています。
PLGの特徴がエンジニアにマッチする
前回の記事で紹介した、PLGの3つのキーポイントを振り返ります。
まず無料で使ってみて、気に入ったら課金
クチコミで広がるバイラルループ
プロダクトが使いやすく、すぐに価値が分かる
これらの特徴はエンジニアととても相性が良いと思います。
エンジニアは気になる技術があったらまず触ってみて、気に入ったら本格採用します。最初は無料、一定の閾値を超えると料金が発生する従量課金の仕組みも、AWSやFirebase、最近だとOpenAIのAPIもそのような形になっており、馴染み深い方法です。
バイラルループはクチコミによる広がりの仕組みですが、エンジニアはコミュニティのつながりが強いです。プログラミング言語や地域、技術ごとに勉強会が開催されたり、ブログやTwitterで積極的に情報発信したり、OSSに貢献したりします。気に入ったツールは社内勉強会やLTなどで紹介することも多く、クチコミが広がりやすい文化になっています。
プロダクトの使いやすさは重要です。日常的に使うツールのUX/UIの大事さをエンジニアは理解しています。煩雑で使いづらいサービスの採用は、価格は少し安く抑えられるかもしれませんが運用時に苦しみが生まれます。普段から技術的負債と向き合っているエンジニアは、整った基盤の上で作業する大事さを知っています。
まずは触ってから考える
営業主導でプロダクトを売ろうとする場合、リード（ユーザーの候補群）を集めることが重要です。そのため、資料ダウンロード時にメールアドレスを入力させたり、料金表の詳細を伏せて「Contact us」としたりと、プロダクト利用前に連絡先を収集する仕組みを作ります。
エンジニアは興味を持ったものは自分で一度触ってみることが多いです。好奇心が高くて勉強熱心な人が多く、勉強会やブログなどで話題になったサービスは時間を作って自分で試します。
すぐに利用を始められなかったり料金プランが不透明だったりするとフラストレーションが溜まりますし、プロダクトを使う前にサービスの営業担当から電話がかかってきても出ることはないでしょう。PLGの提供する「まず使ってみる」という体験は、エンジニアが当たり前に期待することなのです。
エンドユーザーが力を持つ時代に
BtoBソフトウェアの歴史的な経緯を振り返ってみると、昔はインストール型が主流でした。企業の決裁者が何を導入するか決め、メンバー全体がそれを使う。現場が本格的にツールを使うのは導入が完了した後でした。
今はどうでしょうか？SaaSと呼ばれるクラウド x サブスクリプション型の提供が増え、初期費用も安価になっています。現場のやり方にマッチするツールを選定した方が良いという考え方も広まり、エンドユーザーが決定権を持つことが多くなっています。
実際にエンジニアの方にインタビューすると、技術選定はエンジニアチームに任されており、価格などに余程の懸念がなければ基本的にエンジニアが選んだものが採用されます。SaaSでは「利用者（ユーザー）」と「決裁者（バイヤー）」が異なる場合がありますが、エンジニア向けでいうとこの2つは限りなく近いものといえるでしょう。エンジニアの技術選定は信頼されているのです。
なので、エンジニア向けサービスで大事なのは、まず何よりエンジニアに気に入ってもらえるかどうかです。ここで太鼓判を押してもらえれば導入してもらえる確率はかなり高くなります。
技術選定を任されるようなエンジニアはいろいろなものを触ってきており、審美眼が磨かれています。取り繕って凄そうに見せてもバレます。本質的に良いもの、課題を解決するものを作るのが良いでしょう。
サービスが解決する課題の大きさはもちろん、丁寧に作られている分かりやすいサービスは受け入れられやすいです。使いやすいサービスの特徴は以前noteで書いたので、良ければこちらも読んでみてください。
開発者体験を高めるために
エンジニアに愛されるサービスを作るために何ができるでしょうか？開発者体験（DX, Developer Experience）について、少し考えてみます。
環境構築がダルい
コードを書いてモノを作っていくのは楽しいです。エンジニア的に面倒に感じるのは準備の段階、つまり環境構築ではないでしょうか。ここで詰まると解決に時間がかかることが多く、しかもまだそのサービスに時間をかける価値があるか分かっていないため、高い負荷がかかります。
クイックスタートのガイドを用意したり、エラーメッセージをわかりやすくしたり、SDKを提供してアクセスを簡単にしたり。色々な方法でオンボーディングを支えれば使ってもらえる確率があがるでしょう。
ドキュメントは超重要
機能・仕様のドキュメンテーションは超重要です。
最初のセットアップ、実装時、何かに詰まった時など、重要なタイミングでドキュメントが参照されます。ドキュメントに書かれた内容に誤りがあると解決に時間がかかって悪い開発体験になってしまい、サービスへの信頼が損なわれます。
ドキュメントの他に、実装を進める上で共通して困りそうなポイントやTipsをブログなどに書くのも有効です。検索エンジンで調べた時に公式ブログの記事がヒットすると安心してもらええます。また、学習の進め方は人それぞれなので、ブログや書籍、YouTubeなど、色々な形でコンテンツを提供できるとベターでしょう。
すべてのケースをフォローすることは難しいので、つまづくことが多いポイントを公式でサポートし、ユースケースごとに発生するような内容はサービスのユーザーがコンテンツを用意してくれるような雰囲気になるとハッピーです。便利で使いやすいものを提供し、気に入ってもらうことでこういう雰囲気が少しずつ生まれていくのかなと思っています。
技術的にサポートする
詰まった時、詳しい相手に聞けることは重要です。プロダクトに一番詳しいのは開発している社内メンバーだと思うので、社内メンバーと直接やり取りできるのが一番解決に近いです。
技術に明るいカスタマーサクセスチームを組成してユーザーからの質問に答えたり、サポート情報を発信するのは有効です。
また、サービスのファンになってくれた方が善意でヘルプしてくれることもあります。サービスのコミュニティを作ってユーザー同士が交流できる場所を作るのも良い方法だと思います。
一貫性を持たせる
使いやすいサービスの話の中で、一貫性は慣れを育む重要な要素だと書きました。これはUIだけでなく、エンジニアが利用するAPIにも同じことが言えます。
複数のAPI間でリクエストやレスポンスの形を共通にするとか、APIの一般的な慣習に合わせるとか、エンジニアが期待する動作に揃えておくと使いやすいです。独特なAPIリクエストが必要で分かりづらいとか、ステータスコードが統一されてなくてハンドリングが大変とか、そういった摩擦をできるだけ無くすのが肝心です。
おわりに
エンジニア向けSaaSとPLGは相性が良いという話を書きました。
「まず使ってみて、それから課金する」というのはエンジニア的にも自然な流れで、価値を体感しやすくマッチする方法だと思います。
エンジニアは良いものは認めてくれる一方で、使いづらかったり微妙な体験をさせてしまうと、それも同じくコミュニティにシェアします。エンジニアの目線に立ち、使いやすく便利なプロダクトを作っていくことが大事だと思っています。
募集のおしらせ
私の働くmicroCMSではPLGを加速するため、各職種の採用を行っています。
少しでも興味を持っていただけたら、ぜひ気軽にカジュアル面談をリクエストしてください。一緒に良いサービスを作りましょう！
この記事が気に入ったらサポートをしてみませんか？