見出し画像

実践PLG - すべてをプロダクト中心に考える

こんにちは!ひまらつです。microCMSという会社でプロダクトマネージャーをしています。

PLGとはProduct-Led Growthの略で、「プロダクト主導型の成長」を意味します。従来の営業主導型と比べて、マーケティングやセールスの機能をプロダクトにセントライズするのが特徴です。ZoomやSlackがPLG型で成功したこともあり、言葉をご存知の方は多いかもしれません。

PLGの本などもいくつか出版されていますが、日本ではまだまだPLGの実践例は少ないように感じます。
私が働くmicroCMSでは1年半ほど前からPLGの戦略をとっており、プロダクト主導での成長を目指してきました。このnoteではその取り組みを紹介し、PLGの具体例を少しでも紹介できればと思っています。

(※microCMS = マイクロシーエムエス と読みます)

前提: PLGとは何か?

PLGは「プロダクト主導型の成長」で、マーケティングやセールスなどの機能がプロダクト中心に考えられている型のことです。

イメージしやすいように、PLGの代表とされるZoomを例に説明します。
Zoomはアカウントを作るだけで利用を開始でき、基本的な機能は無料で使えます。ビデオ会議という性質上、一人で使うことはなく、取引先やチームメンバーと一緒に利用します。そのため、会議に参加した人は自動的にZoomというサービスを知ることになり、便利だと思えばまた別の機会にも使われることになります。
Zoomの無料プランでは40分までしか利用できません。40分は絶妙な時間設定で、それ以上会議を続けたい場合は課金が必要です。40分間の利用で、すでにZoomの基本的な機能は体験しているので、有料プランにアップグレードする価値があると判断されればお金を払ってもらえます。

アカウント登録から他のユーザーへ認知が拡がり、課金される。この一連の流れでZoom社のマーケティング担当やセールス担当は一度も登場しません。ユーザーが自身でプロダクトを試し、価値を感じて自分で契約を決める。これがプロダクト主導です。

PLGの成功に重要なポイントをまとめます。

  • 「フリーミアムモデル」 - 無料で使い始められて、気に入ったら課金する

  • 「使いやすいプロダクト」 - 使い始めてすぐプロダクトの価値を理解できる

  • 「バイラルループ」 - 人が人を呼ぶ仕組みをプロダクトが持っている

これらの要素がうまく組み合わさったとき、Zoomのような「プロダクトがプロダクトを売る」状態を実現できます。

なお、プロダクトの性質によってはそもそもPLGがマッチしなかったり、営業主導型の方が向いていたりします。このあたりは今回は詳しく触れませんので、興味がある方は以下の本を読んでみてください。PLGが体系的にまとめられており、おすすめの一冊です。

PLGについて整理できたところで、実際にmicroCMSで取り組んだ内容を紹介していきます。

microCMSのPLGへの取り組み

1. プライシング変更

microCMSはリリース当初から無料で使えるプランを用意していましたが、実装上の理由で「無料プラン → 有料プラン」の転換ができない仕様になっていました。規約も「無料プランでは商用利用は禁止」となっており、プランまわりの理解は少し難しかったように思います。

PLGでは「まず無料で使い始め、気に入ったら課金する」を滑らかにすることが重要です。そのため2022年1月に料金改定を行い、「無料プランでも商用利用可能。また、いつでも無料プランから有料プランへ転換できる」ように変更しました。

また、このタイミングで「無料プランで使えるメンバー数を1名 → 3名」に拡大しました。microCMSは複数メンバーで使うとより価値があるタイプのプロダクトです。その価値を早い段階で体感してもらう狙いがありました。

このnoteを書いている時点で、料金改定から約1年半が経ちました。データを見ると無料プランの商用利用、複数人利用のサービスも多いですし、そこから有料プランへのアップセルも多く発生しています。「まず無料で、気に入ったら課金」の流れはスムーズになっていると思います。

microCMSの料金プラン。無料の範囲内でもかなり使え、価値を体感できる

2. オンボーディングの改善

PLGで磨くべきは「プロダクトの価値をすぐに体感できる」点です。興味を持って触ってみて、便利かどうか分かるまでに1ヵ月かかってしまうのは長すぎますよね。できるだけ早くユーザーに成功体験を与えるために、プロダクトの「クイックウィン」を意識して改善することが重要です。

クイックウィンはユーザーがプロダクトの価値を感じる最初の瞬間のことで、「お、このサービスいいな!」と思ってもらうタイミングです。PLGではこのクイックウィンを適切に定め、それをできるだけ手前に持ってくることが重要とされています(早く価値を感じてもらう)。

microCMSは入稿したコンテンツをAPI経由で取得できるサービスです。APIで利用する際は開発者がコードを書くわけですが、その助けとなる機能に「APIプレビュー」というものがあります。

開発者のデバッグに便利な機能「APIプレビュー」。
APIでのデータ取得を管理画面上でデモできる

microCMSではこの「APIプレビューの利用」をクイックウィンに設定しました。この機能を使うところまで到達できれば、microCMSの基本的な価値を理解できると考えたためです。
そして次のステップとして、アカウント登録〜APIプレビューの利用までの流れを図示し、ユーザーが戸惑う可能性のある箇所を洗い出して改善していきました。

クイックウィンまでの障壁をユーザー目線で洗い出す(Miroを利用)

計測したところ、特に離脱が大きいのは以下の箇所でした。

  • コンテンツを入稿したあとにAPIプレビューの機能に気づかない

  • アカウント登録時、確認コードを入力せずに離脱している

  • サービスの基本情報(名称とサービスID)を決められない

これらを解決するために、APIプレビューを使って欲しいタイミングでポップアップを表示。アカウント登録時の確認コードを不要にする。サービスIDは考え出すと命名に悩んでしまうので、予めランダムな文字列を入れ、後から変更できるようにしました。

こういった地道な変更によりオンボーディングが改善され、APIプレビューへの到達率は約2.5倍に改善されました。クイックウィンの増加は、より多くの方にプロダクトの最初の価値を感じてもらえたことを意味します。

オンボーディングのステップごとのファネルを作り、毎週確認していた

上記の改善結果は、集中的に取り組んだ3ヵ月の間での数字です。その後も1クリックで複数ステップ分進められる「テンプレート機能」などを開発し、今ではさらに滑らかなオンボーディング体験になっています。

余談ですが、改善した離脱ポイントの一つである「アカウント登録時、確認コードを入れずに離脱している」は、実は先述のPLG本でもまったく同じ例が紹介されています。認証コードの確認のためにGmailなどのメールアプリに移動することで意識が途切れることが離脱の理由とされているのですが、このステップを省略したことで本で紹介されたケースと同じく約30%の改善が見られました。サービスの状況が違っていても近しい数字になるのは面白いですね。

なお、クイックウィンは大事ですが、強制的にそのアクションをさせるなどevilな方法で増やしても意味がありません。あくまでユーザーの戸惑いや躓きを減らす本質的な改善に取り組む必要があることはチームとしても意識していました。

3. コミュニケーションバンパーを整える

聞き慣れない言葉かもしれませんが、コミュニケーションバンパーはPLG本の中で登場する概念です。ユーザーが価値に向かって進む様子をボウリングに例え、横道に逸れないように「プロダクトバンパー」と「コミュニケーションバンパー」でサポートする、という考え方です。

2種類のバンパーでユーザーを支える「ボウリングレーンフレームワーク」

microCMSでは、コミュニケーションバンパーとしてユーザーの状況を見てメールでサポートすることに取り組んでいます。
例えばAPIプレビューに未達のまま利用をやめたユーザーに対し、APIプレビューの便利な使い方やmicroCMSの活用方法をメールで伝えます。microCMSに興味があるけど、使い方がわからなくて離脱したユーザーであれば、もう一度プロダクトに戻ってきてもらうチャンスになります。

ここで送るメールは自動化されており、ユーザーの状況を考慮して送られるようになっています。例えばAPIプレビューをすでに使っていたり、過去に別プロジェクトでAPIプレビューを使ったことがあるユーザーにはこの案内は不要なはずです。ユーザーの文脈を見て、必要なユーザーにだけサポートの連絡をしています。

単純にメールと聞くとプロダクトとは別の施策に感じるかもしれません。しかし、コミュニケーションバンパーはプロダクトの利用状況に応じて送られ、目的はAPIプレビューの利用などのプロダクト価値を体感できるアクションへユーザーを導くことです。プロダクトの外で作用するものでありながら、あくまでプロダクトを中心に考えられており、PLGらしい施策だと思います。

教科書通りにはいかないバイラルループ

バイラルループは作るのが難しい

PLGの取り組みをいくつか紹介しましたが、サービス成長のためには「バイラル」が重要です。バイラルループ、つまり人が人を呼ぶ仕組みを作れるかどうかは、PLGの成否を分ける要素です。ZoomやSlackはサービスそのものがバイラル性を備えているため非常に広がりやすく、PLGにマッチしたサービスと言えるでしょう。

では、microCMSではどうでしょうか?多少はバイラル性はあるものの、Zoomなどに比べると少し弱い、というのが自分の見解です。

簡単に説明させてください。
microCMSを利用するユーザーには、「開発者」「コンテンツ入稿者」の2つの属性があります。Webサイトにお知らせ機能を組み込むまでは開発者が担当し、実際にお知らせを入稿するのはマーケティングチームのメンバー、のように役割が分かれていることが多いです。

開発者 → コンテンツ入稿者 の順で利用する

microCMSは複数人で使うとより便利なサービスであり、メンバー招待機能を持っています。招待するのは「一緒にWebサイト構築をしている開発者」か「コンテンツ入稿者」のいずれかです。
microCMSは開発者を起点に使い始めてもらえるサービスなので、招待の属性が分かれる分、バイラルでの広がりは少し弱いことになります。

Zoomと比べるとバイラル性が低い構造になっている

このバイラル性の違いは、ZoomやSlackをお手本にPLGを実践しようとした時に引っかかったポイントです。そして、このバイラル性はサービスの性質として備わっているかどうかが大きく、ちょっとの機能開発で高められるものではありません。友人と一緒に使うと面白いとか、チームで使うとさらに便利だとか、プロダクトが解決しようとしている課題に依るものが大きいです。

少し特殊な開発者界隈

ところで、これまでのmicroCMSの成長はユーザーのみなさんのクチコミに牽引してもらってます。サービスを使ってみて、気に入ってくれた開発者の方がブログや勉強会、Twitterなどで他の開発者にシェアしてくれて、それで興味をもった方がまた使ってくれる、というループです。

他の職種でもこういった流れはあると思いますが、特に開発者界隈では「共有する」文化が色濃いです。OSSに貢献したり、自分の調べた内容を惜しげもなくZennやQiitaで公開したり、良いサービスを見つけたら積極的に共有する。こういった活動を日常的にする文化は、開発者ならではのものだと思います(そして個人的にとても好きな文化です)。

プロダクトを気に入ってくれた開発者がそれを周りに伝えて広まっていく。ZoomやSlackのプロダクトが直接広める形とは少し違いますが、開発者コミュニティを通じてバイラルが広まっていくのは、開発者を対象としたSaaSの面白い部分だと思います。そしてこの文化に支えられる形で、microCMSのバイラルループは成立しています。

ユーザーサクセスファーストで考える

microCMSは無料プランでもかなり使えます。商用利用であっても無料の範囲内で事足りるケースも多いかと思います。会社としては売り上げにはなりませんが、それでOKだと思っています。

以前の記事でも紹介しましたが、私の好きなTwilioの創業者の方のインタビューの一節を紹介させてください。

"We love developers, and it’s a long game for us. If you don’t ever spend a penny on Twilio, but you’re a successful developer, we consider that a win.”

「私たちは開発者を愛していますし、長い目で見ています。もしあなたがTwilioに1円も使わず、開発者として成功したなら、私たちはそれを勝利だと考えています。」

How Twilio Does Product-Led Revenue より(日本語訳は筆者)

TwilioもPLG型の企業ですが、この考え方にはとても共感します。まずは開発者が成功することが重要。そこで直接売り上げが出なくても、サービスを気に入ってもらえれば次の案件で採用してくれたり、他の開発者にシェアしてくれたりします。
私たちがやるべきことはシンプルで、開発者が課題に思っていることを解決したり、歯痒い部分を機能改善したりして、プロダクトの価値を高めていくことです(ボランティアにならないようプライシングは重要)。

「プロダクトだけやればいい」ではない

PLGはあくまで「プロダクトを中心に」据える手法であり、「良いプロダクトを作っていれば自然と売れる」という考え方ではありません。マーケティングやセールスは非常に重要で、それなしで事業を成長させることは難しいでしょう。

PLGは組織全体でのチャレンジです。各チームの取り組みがあると思いますが、それをプロダクト中心に考えます。プロダクト中心とは、ユーザー目線でとことん考えることだと思っています。色々な施策がありますが、「ユーザーが何を求めているのか」「何に困っているのか」を軸に進めることが重要です。例えばコミュニケーションバンパーも、メールでガイドする先がユーザーにとって意味のない機能であれば、ユーザーにはノイズになってしまうでしょう。

組織全体がユーザー目線で考え、プロダクト機能を実装し、それが仕組みとなって「プロダクトがプロダクトを売る」状態に近づいていく。PLGは取り組む難しさもありますが、本当に便益のあるものを作れる手法だと思います。

おわりに

microCMSが実際に取り組んだ施策を振り返りながら、PLG戦略について紹介しました。
PLGは魅力のある手法ですが、グローバルに比べると日本ではまだまだ実例が少ないです。今後もプロダクト主導での成長にトライし、その取り組みを紹介させていただければと思っています。

募集のおしらせ

microCMSではPLGを加速するため、各職種の採用を行っています。
少しでも興味を持っていただけたら、ぜひ気軽にカジュアル面談をリクエストしてください。一緒に良いサービスを作りましょう!


#PdM日記」というシリーズでnote書いています。フォローしてもらったり、他の記事も読んでもらえるとうれしいです!

この記事が気に入ったらサポートをしてみませんか?