Product Led Growthを読んで: プロダクト主導の成長モデルの概要とエンジニアとしての感想
最近、SaaSを開発しているエンジニアとして、事業の成長のさせ方など、技術以外の分野にも明るくなりたいと思って、Product Led Growth(PLG)という本を読みました。
SaaSの潮流の変化や、その変化に適合したビジネスモデル(PLG)の概要や具体的な手法などがわかりやすく説明されており非常に面白かったです。
本ブログではこの書籍に書かれている一部と、推薦システム等を開発・改善してきたエンジニアとしての感想をまとめたいと思います。
ソフトウェアを取り巻く環境の変化
ソフトウェア産業は、他の産業に比べ歴史は短いです。しかし、ユーザの期待値やサプライヤーのプロダクトの提供方法は、短い歴史の中で絶えず大きく変化しています。
1. スタートアップの成長に多くのコストがかかるようになった
技術の革新や、ノウハウの蓄積により、ソフトウェア市場の参入障壁が低くなり、他社との競争が避けられなくなりました。
これによって企業はユーザを奪い合う必要が増え、顧客獲得コスト(CAC)は上がり、顧客単価は下がっています。
2. ユーザーはプロダクトを自ら学び、すぐに価値を得ることを好むようになった
スマホの台頭等により、ユーザは以前に比べ、ソフトウェアプロダクトを早く、多く使うようになりました。
YouTubeやSpotify、 Uberのように、アプリストアからダウンロードして、すぐに価値を享受できるような顧客体験に慣れたユーザは、自らプロダクトを触り、何が自分に向いているかを選ぶようになりました。
購買プロセスもすぐ完結できることを望みます。例えば、Netflixで課金をする場合は、ユーザはセールスに問い合わせ依頼し、商談をした上で成約するような長いサイクルではなく、プロダクト上の決済で完結できることを望んでいます。
3.プロダクトを気軽に試してもらえるエコシステムと技術が発展した
プロダクトを気軽に試せる体験をサプライヤー側も以前より簡単に提供できるようになりました。
例えばソフトウェアはオンプレミスで密に連携しながらではなくクラウド上から安全にダウンロードできるようになったり、多くのユーザにアプローチできるApple Storeなどのエコシステムが形成されています。
環境変化に伴うプロダクトの顧客獲得の変化
上記のようにソフトウェアを取り巻く環境の変化がしたことによって、プロダクトの顧客獲得方法も変化しています。
2000年以前、OracleやIBMなどの大型ベンダーのトップセールスが、社長や経営層と密に連携をとって、長いセールスサイクルを経て、ソフトウェアを企業に導入する、いわゆるトップダウンの導入が主流でした。
2000年以降はクラウドリソースの発達などにより、ソフトウェアの価格が下がりました。これにより決裁権をもつクライアントが広がり、ボトムアップにプロダクトが導入されるようになりました。ただ、セールスサイクルは軽量になったものの、依然セールスが主導の顧客獲得モデル、SLG(=Sales Led Growth)でした。
そして現在は、ユーザーがフリーミアムやフリートライアルなど、ユーザがセールズを介さず、自身でプロダクトを試し、価値を得るモデルが主流になっています。
このようにユーザの集客やアクティベート、さらには販管などをプロダクト自身が担うモデルがPLG(=Product Led Growth)です。
PLGの優位性
PLGは従来のSLGに対していくつかの観点でメリットがあります。
広いユーザにリーチができる
カスタマージャーニーの早いタイミングでユーザを引き込める
迅速にグローバル展開できる
異国のセールスを採用する必要がない
格段に低い顧客獲得コストが下がる
1ユーザあたりへのタッチポイントが減る
事業のポートフォリオが大口顧客によらなくなる. ひとつの顧客への依存度が下げる。
一方で、PLGはSLGよりもユーザが自力で早いファネルからプロダクトの中から価値を見つけて、得ないといけないので、早くわかりやすく価値に到達できるような体験を設計する必要があります。
その他に書籍に書かれていること
書籍には他にも現代のSaaS開発において、有用な知見がいくつも書かれてていました。例えば下記の通りです。
自社のプロダクトにおいて、SLG or PLGのどの手法を選択すべきか判断できるようになるMOATフレームワーク(マーケット、オーシャン、オーディエンス、タイムトゥバリューからなる)
プロダクト開発をPLGで取り組み始める or SLGからPLGに移行するためのサイクル
価値を理解する、伝え、提供するための手順(UCDフレームワーク)
PLGを成長させるためのサイクル
SaaSのレバーとなる主たる要素(ARPU, チャーンレート, 顧客数)を最適化するための手順
読んで得られた知見
普段の開発においても活用できそうな知見を多く得られました。
まず、現代においてユーザは、プロダクトを選ぶときに、高い期待値をもって多数の選択肢から取捨選択していると改めて気づかされました。
開発者としては、頑張って作った機能は使われるだろうと期待してしまいますが、ユーザは忙しく、早くわかりやすくユーザのペインを解かないと使ってくれないと理解しました。
また、PLGはSLGよりもユーザが自力で早いファネルからプロダクトの中から価値を得ないといけないので、ユーザの離脱を防ぐガードレールとなる施策をより徹底する必要があると感じました。
推薦システムや機械学習などを扱っている身としては、前述のようなリッチな手法の前にメールやプログレスバーや、チェックリストなど多くのファネルにガードレールを敷きれているか?凡事徹底できているか?と確認する必要があるなと思いました。
PLGにおいて、推薦システムで気をつけることは?
このようにユーザの期待値が上がり、判断に要する時間が短くなった現在においては、推薦システムを導入する際も、従来よりもユーザーに価値を早く届けることの重要度が増しているように感じます。
基本的に推薦システムは回遊したユーザーの方が、インタラクションベースのリッチな情報をもとに、高い精度で推薦できますが、回遊を待ってから推薦すると言っていると、それよりも先に離脱してしまうかもしれません。
登録した直後のユーザーに対しても、プロフィール情報を元にコンテンツベースで素早く推薦したり、ニアリアルタイムで少ないデータを元に推薦結果をブラッシュアップしたり、他のユーザーの情報を活用したクロスマーケット推薦したり、まず多くのユーザが好意を示す人気アイテムを推薦したりと、工夫をこらす必要がありそうです。
日本のToB企業においても同様にPLGを導入すべきか?
本書ではSLGに比べ、PLGの方が良いと書かれていることが多かったですが、やや批判的な見方をすると、日本のToB企業においては注意深く導入する必要があるのでは、と思いました。
例えばSaaSのエコシステムが発達した米国などと比べ、日本にはPLGを導入しにくい下記のような差異がありそうです。
(あくまで個人の仮説です)
1ユーザーあたりのプロダクト導入数が欧米に比べて少ない→ 少ない導入数で多くの機能を賄うニーズが強い→プロダクトが複雑になるため、タッチポイントの多いSLGの方が有利?
多くのプロダクトを触ることに慣れていて、自身でプロダクトの価値を判断したいと思っている若年層の人口は少なく、決裁権を持っていることも少ない → 手厚いサポートができるSLGの方が有利?
インボイスなど法務周りの決済フローが日本独自かつ、煩雑なため、プロダクト内で決済を完結できるようにする開発難易度が高い → 契約ごとに柔軟に対応できるSLGの方が有利?
とはいえ、ガードレール施策を導入したり、プロダクトの使い方や価値についてすでに知っている既存ユーザのアップグレードにPLGを導入することなど部分的にPLGの要素を導入することはできそうです。
おわりに
本書を読むことで、使われるものを作れるようにするには、どのように開発すべきという点の解像度が上がったように思えます。
今後もこのような記事を書くので、良ければTwitterをフォローしてもらえるとうれしいです!
では〜
この記事が気に入ったらサポートをしてみませんか?