Practice of Programming

プログラム とか Linuxとかの話題

Product-Led Growthまとめ

この記事は Wano Group Advent Calendar 2022の4日目の記事となります。他にも、24日(STREAM DECK互換の仮想デバイスの紹介)と25日(Notionとtandemで作る相談しやすいリモートワーク開発のすすめ)に記事を書いているので、そちらもどうぞ。

グループ会社のEDOCODE(メインで仕事してます)のAdvent Calendar で、12/6にDockerの記事を書きますので、よろしければ、そちらもどうぞ。

この記事について

立場的に技術のこと書くべきなのかもしれませんが、リクエストがあったので、「Product-Led Growth」という本のまとめを書きます(要約と個人的な考えの追記となっています)。

なお、以下の目次を見てもおわかりと思いますが、とっても長いです。

Product-Led Growthとは?

ウェス・ブッシュによるプロダクト開発の本ですが、副題に「『セールスがプロダクトを売る時代』から『プロダクトがプロダクトを売る時代』へ」とあります。 プロダクトを成長させるための戦略や効果的なプロダクト開発、それにまつわる考え方について書かれています。

まじで良い本なので、こんなまとめを読んでる暇があったら、今すぐ、買って読んだほうが良いです。Kindleなら数秒で手に入りますし、英語なら、サイトで無料で読むことができます。

いや、それでもちょっと...という方は、時間が無駄になるかもしれませんが、以下の紹介を読んでから、本書を読む気になってください(ならなかったらごめんなさい)。

※文章内で、PLGと書いている場合は、Prodcut-Led Growthの書籍のことを指しています

ちなみに、時々「UXデザインの法則」の話が出てきますが、こちらも良書です。下記にまとめていますので、よろしければどうぞ。PLGの内容と非常に相性が良いのではないかと思います。

UXデザインの法則を読んで感銘を受けたのでまとめた

セールス主導型 vs プロダクト主導型

字句通りですが、セールス主導型のプロダクトというのは、セールスの人員が、見込み客リストにコンタクトを取って、顧客獲得するとか、オンボーディングに人手をかけるとか、広告を大々的に打って、顧客を獲得するとかそういうものです。セールスに重きを置いてプロダクトを成長させるということです。 プロダクト主導型というのは、見込み客に端的に言えばプロダクトを使わせる・体験させることによって、そのプロダクトの価値をユーザーにいち早く体験させることで、ターゲットになりうるユーザーを逃さず、成長につなげるというような感じです。

顧客を獲得するのに、セールス主導型は基本的にコストがかかります。比較して、プロダクト主導型ではコストは低く抑えられます。顧客獲得単価を低く抑えられるということは、その分サービスの利用金額も低く抑えることができ、競争優位性が高まります。

フリートライアル、フリーミアム

この2つのモデルのプロダクトがプロダクト主導型に向いています。この2種類の違いは何か、改めて書くと。

  • フリートライアル ... 一定期間は無料で使うことができる。無料期間が終わると有料プランに切り替わる
  • フリーミアム ... ずっと無料で使えるが、有料プランにすることで使える機能や回数とかが増えたりする

フリートライアルとフリーミアムの実際の例を出すと

みたいな感じですね。

自分のプロダクトが、フリートライアル、フリーミアム、どちらが向いているのかを判断するために、プロダクトの成長戦略について考える必要があります。

プロダクトの成長戦略

下記の3つの戦略のうち、自分のプロダクトにあったものを選ぶべきです。

ドミナント型 - 安価 & 大規模

全タイプの顧客を狙う差別化戦略です。低価格で機能を提供し、あらゆるタイプの顧客をターゲットとします。SpotifyNetflixのようなサービスですね。 「5000万ユーザーくらいを顧客にできないと成り立たない」との説もある(*)とのことですが、どこまで必要かは会社の目指す規模にもよりそうです。 ただ、安価なので、5000万はだいぶ言い過ぎなんじゃないかとは思いますが、それなりのユーザー数は必要かと思います。

ディスラプティブ型 - 既存より低価格 & 既存以下以上の規模

既存サービスを過剰と感じている顧客を狙う戦略。例えばタスク管理サービスのJiraに対する、Trelloみたいな感じですかね(買収されてますけど)。機能を落としても、よりユーザーが使いやすいものを作って、乗り換えさせる戦略です。

差別化型 - 既存より高価格 & 既存以下以上の規模

既存のサービスが不十分だと感じている顧客を狙う戦略。ディスラプティブ型とは逆に、既存サービスのできないところを補ったプロダクトを開発し、乗り換えさせる戦略です。 グループ会社のEDOCODEが開発しているPUSHCODEは、WebPushのサービスですが、他のサービスよりもAPIに力を入れているので、差別化型の戦略と言えるかと思います。

ブルーオーシャンレッドオーシャン

プロダクト主導が向いているかどうか判断するために、自分のプロダクトがすでに市場が成立しており競争過多な市場(レッドーオーシャン)にいるのか、今から市場を作り出す(ブルーオーシャン)ものなのかを把握する必要があります。

ブルー or レッド?という二者択一ではなく、セグメントによってはブルーにもなりうるし、レッドにもなりうるということもあります。 例えば、大企業向けに提供している同様のプロダクトは複数あるが、中小企業向けに提供しているプロダクトは少ない、または、無いということもありえます。

Slackに対するChatworkは、(当初の)Slackが英語インタフェースでAPIや連携サービスが充実していて開発者受けが良かったのに対して、別のセグメント(日本人向け、非開発者より)を狙っての戦略だったかもしれません。知らんけど。

ブルーオーシャン

ブルーオーシャンはこれから作り出す市場なので、競争相手はいないが、プロダクトをすぐに理解してくれる顧客も少ないということになります。 プロダクトの価値を顧客がすぐに理解できるようなものであればよい(Spotifyなど)ですが、そうでなければ、プロダクトを理解してもらうまでに手厚いサポートが必要になるかもしれませんので、コストをかける必要があります。 結果として、セールス主導型が合うようです。

レッドオーシャン

レッドオーシャンでは競争相手は多いですが、同じようなプロダクトがすでにあるので、顧客はプロダクトをすぐに理解することができます。 そのため、手厚いサポートはそこまで必要ないことが多く、プロダクトの力で顧客のオンボーディングを低コストに抑えられる可能性が高いので、プロダクト主導型にあっています。

ブルーオーシャンのほうが良いと思っていたが...

個人的に、プロダクトを新しく作るならブルーオーシャンのほうが良いよなーと思っていたのですが、プロダクト主導型のサービスにおいてはそうでもないということですね。

確かに、グループ会社のTuneCore Japanが始まった当初は市場はブルーオーシャンでしたが、ユーザー数の伸びも緩慢でした。 今は、TuneCore Japanが市場を開拓してユーザー数が増えました。後発のサービスが出ても、このタイプのプロダクトについてユーザーがすぐ理解できてしまいますね。先駆者にはメリットもありますが、当然ですが、メリットに甘えていられるというわけではないですね。

トップダウンボトムアップ型の販売戦略

販売戦略によってもプロダクト主導で行くべきかどうかが別れます。

トップダウン

トップダウン型の販売戦略とは、企業の意思決定者に導入を決定させるやり方です。大企業の全体に一つのシステムを導入させようというような場合は、トップダウン型になります。経営層やそこに近い人たちに売り込んで、全社的に採用してもらうようなやり方です。 プロダクトの導入までに数ヶ月から数年かかる場合もあります。

営業やサポートに人も時間もお金もかかるので、セールス主導型のプロダクトに向いています。

ボトムアップ

ボトムアップ型の販売戦略は、大きな決裁権のある人というよりは、実務者が実際に使ってみて、導入されていく形です。 実務者が簡単に使いはじめられ、理解しやすいものである必要があります。フリーミアム、フリートライアルが向いています。 消費者向けのプロダクトであれば、そもそもトップダウンということはないですね。

プロダクト主導型のプロダクトに向いています。

プロダクトの価値をいかに速く示せるか?

プロダクト主導型のプロダクトでは、プロダクトの価値をユーザーにいかに速く示す(体験させる)かが、重要です。フリーミアム、フリートライアルであれば、すぐにユーザーがプロダクトを体験することができます。

フリーミアムかフリートライアルか?

自分のプロダクトがプロダクト主導が向いているとわかった場合に、フリーミアムとフリートライアルのどちらが向いているのかを考える必要があります。

productled.com に、下記のクイズが用意されています。クイズに答えることで、どちらが向いているか判定することができます。 https://productled.com/quiz/

ただ、二択ではなく、フリーミアムとフリートライアルのハイブリッドという選択も可能です。

ハイブリッド型

既存のプロダクトとは別に新規事業としてたちあげて、いずれかのモデルを試してみるとか、フリーミアムだけど、ブロックされている機能をフリートライアルで提供できるとか、フリートライアルから有料版に移行しないユーザーに、フリーミアムの案内をだすとか、などがあるようです。

ユーザーに価値を示すと言っても?

本当に自分たちのプロダクトの価値を理解しているのが、正しく伝えられているのかを確認することが必要です。UCD Frameworkが紹介されています。

UCD Framework

UCDは、Understand、Communicate、Deliver で、このサイクルを回して、プロダクトの価値とユーザーがプロダクトから期待する価値をギャップがないものにしていくフレームワークです。

  1. Understand(理解する) ... 主観的分析、データドリブンアプローチ、ストレステスト
  2. Communicate(伝える) ... 経済的分析、マーケットリサーチ、適切な価格ページの開発
  3. Deliver(提供する) ... Valueのギャップの特定、定常的な最適化

プロダクトの価値の理解(Understand)

顧客はプロダクトを買っているわけではなく、プロダクトの生み出す「成果(=アウトカム)」を買っています。 Slackは「チャットツールを売っている」わけではなくて、「チームの生産性やコミュニケーションの向上を売って」いて、顧客はそれを望んでいます。

1. 機能的対価

プロダクトのメイン機能。顧客が実際に解決したい問題に対応するための機能に対する対価。

2. 感情的対価

使っていることで得られる感情的な対価。何らかの発見が得られるとか、喜びが得られるとか。 UXデザインの法則に「ピークエンドの法則」というものがあります。プロダクトの感情的対価のヒントになるかと思います。

3. 社会的対価

使っていることで得られる社会的な対価。使っていることによる他者(上司、部下、同僚、外部)からの評価など。「あのサービス使ってるんだ、イケてる」みたいに思われたりすることとかも、含まれますね。

プロダクトから得られる価値を測る

プロダクトの価値を測るためのバリューメトリクスには、2種類のものがあります。

  1. 機能的メトリクス ... 機能の使用頻度によって価格がスケールするようなケース
  2. 対価ベースのメトリクス ... 例えば、動画の視聴数が顧客に利益を生むようなケース

機能を差別化することで価格をあげると、高い解約率を招く場合があり、その代わりに、バリューメトリクスを設定するほうが75%低い解約率になるとのことです。対価ベースのバリューメトリクスであれば、さらに40%低い解約率になるとのことです。

バリューメトリクスの例

  • Slack ... メッセージ数
  • PayPal ... レベニューの量
  • calendly ... スケジュールされたMeetingの数
  • Notion ... 招待されたプロジェクトメンバーの数
  • INTERCOM ... 開始されたチャットの会話の数
  • DropBox ... 共有フォルダの数

https://drive.google.com/file/d/1mK3I5lrsBSTJSi2yk2J69vX797A9dLLf/view page. 7

良いバリューメトリックスの3つの条件

  1. ユーザーにとって理解しやすいもの
  2. ユーザーがプロダクトから得られる価値と連動している
  3. ユーザーがプロダクトから価値を得れば得るほど、大きくなる
ユーザー数課金はたいてい間違っている

大抵のサービスがユーザー数で課金していますが、ユーザー数が増えたからといって、ユーザーが得られる価値が高まるかどうかは不明なので、ユーザー数に対して課金するのは良くないと書かれています(Slackのようなコミュニケーションツールは別)。

ユーザー課金チェックリストがあるので、これがすべてYesでなければ、ユーザー数課金にするべきではないとのことです。

バリューメトリクスを見つける方法
1. 条件に合致するメトリクスを探す

プロダクトのメトリクスになりそうなものをリストアップして、前述の3つの条件にあてはまるかどうか確認すると良いとのことです。

2. データドリブン・アプローチ

コアユーザーと解約ユーザーの行動の分析して、バリューメトリクスを作るアプローチです。

コアユーザーは...

  1. 普段どのように使っているか?
  2. プロダクトでやらないことは?
  3. オンボーディングの際に、最初にやること
  4. プロダクトから価値を多く得て成功している人の共通点

解約ユーザーは...

  1. コアユーザーとのユーザージャーニーの違いは?
  2. 具体的にどのようなクティビティが違うか?解約ユーザーが達成できたこと、達成できなかったこと。
  3. ターゲット市場内のユーザーだったか?
  4. 主な解約理由は何か?
バリューメトリクスの有効性判断(ストレステスト)

バリューメトリクスを作っても主観的に判断しているだけだと正確ではないです。 作ったバリューメトリクスを、ユーザーに価格面から「最も好ましいもの」「最も好ましくないもの」を選んでもらいます。

「ユーザーが好ましいと思っている」=「ユーザーが対価を受け取っているもの」なので、自分たちが設定したバリューメトリクスがユーザーの考えと合っているか確認できます。

プロダクトの価値を伝える(Communicate)

プロダクト主導型のビジネスでは売上モデルと顧客獲得モデルはは密接しており、連動しています。 プロダクト主導型のビジネスでは、プロダクトによって顧客を獲得するので、プロダクトがまずければ顧客は獲得できないですし、プライシングが複雑で理解しにくいなら、サインアップするユーザー数にも影響がでます。 この両輪がうまく回っていないと、成長もできません。

プライシングモデルと顧客獲得モデルを正しく設定する方法

1. 料金ページを複雑にしない

「UXデザインの法則」に、「ヒックの法則」というのがあります。「意思決定をさせたいなら選択肢は少ないほうが良い」というものです。 大抵のサービスで、プランの選択肢は3つ程度に抑えられています。 PLGでは、5秒テスト(5秒以内に選択できる)に合格できないなら、顧客獲得機会を失っているとあります。

2. 有料プランにアップグレードする必要がなくなるような無料プランは作らない

顧客が無料でい続けてしまってはビジネスにならないので、無料プランですべて済んでしまうようなプラン設計では困ります。

3. ダウングレードしやすい設計にしない

有料サービスをフリーミアムにしようとする場合に、有料ユーザーが無料プランに移ってしまう可能性がありますが、有料プランのユーザーを分析して、無料にする機能しか使っていないユーザーがどれくらいいるかとか、無料にすることで見込める新たな顧客はどれくらいか、とかを考えると良いようです。ユーザー数や配信数であれば、減ることは少ないですね。

プライシング戦略

需要供給に基づいて決める「適正判断型」や、サービスにかかっているコストに利益をプラスする「コスト・プラス型」や、競合の価格と比較して決める「競合ベース」。プロダクトが提供する価値をもとに決める「バリューベース」と、価格を決定する方法は複数ありますが、SaaSの価格を決定するならバリューベースでやるべき、とのことです。

プロダクトの価格の決め方

「経済的価値分析」と「市場調査とユーザー調査」の2つの方法が紹介されており、データやユーザー数が少なく、ユーザーと直接価格について話せる機会がない場合は、前者。逆であれば、後者が良く、後者のほうが正確とのこです。

経済的分析

経済的価値分析では、プロダクトの価値のところで上がっていた、3つの対価。 「機能的対価」「感情的対価」「社会的対価」を実際の金額にしてみて計算する(社会的対価は計算が難しいのでオプショナル)。 その価値の1/10の価格にすると良いとのことです。ユーザーが支払う価格の10倍の価値を提供するということですね。 例えば、あるサービスを使うことによって、今まで一日かかっていた作業が数分で済むようになるなら、1日分のその人のコストが機能的な対価といえますね。 感情的な対価は、この機能を使って得られらる機能的対価にたいして、いくら払ってもよいかということですが、「この仕事が自動化できるんだったら、毎月1万円くらい安いもんだ」みたいなことですね。社会的対価と同様で、ちょっと測りにくい気もしますけどね。

市場調査とユーザー調査

市場調査とユーザー調査では、価格をいくつか用意して、「高すぎる」「安くない」「高くない」「安すぎる」価格を選んでもらうという方法が書かれています。より単純化して、「納得できる」「高い」価格の二択でも良いとのことです。

分析方法は、この辺に書いています。

価値を提供する(Deliver)

プロダクトの説明を読んだり、説明動画を見たりして理解する「知覚価値」と実際使ってみたときの「体験価値」にギャップがある(バリュー・ギャップがある)とユーザーはがっかりします。この2つが一致するのが理想です。 バリュー・ギャップが大きいと、ユーザーはプロダクトを二度と使わなくなるので、バリュー・ギャップの解消に力を入れる必要があります。 「できると思って登録したのに、できないんかー(できるけど、えらい複雑だなーとか)」みたいな経験ありますよね。それがバリュー・ギャップです。

バリューギャップの解消

下記にあげるようなバリュー・ギャップを解消していく必要があります。

アビリティ・デッド

プロダクトが提供すべき価値をユーザーが受け取れていない状態です。別に機能がバグっているという話だけではなく、仮登録したけど、実際の機能は使わずに離脱してしまった、というのも含まれます。

(プロダクトの提供者が)顧客がプロダクトを購入する理由を理解していない

顧客がプロダクトに期待している価値を正しく理解して、その価値を可能な限り最短で体感できるようにする必要があります。

価値の提供に失敗している

ユーザーへの事前の認知(プロモーションやサイトの説明)と実際提供される価値が違っていれば、それは問題です。 単純に機能的なものもあれば、すぐに使えると書いているのに、実際は一週間経たないと使えない、みたいな時間的なものもあり得ます。

UCDフレームワークで考えてみる

Wanoのグループ会社の事業の例で考えてみました。D は実装部分なので、わからない場合は省略しますというのと、関わっていない事業も多いので、テキトーに想像しました。数分で考えたものなので、超、雑です。

なお、下記のバリューメトリックスの中で「3つの条件」と書いているのは、先に紹介した、下記の3条件のことです。

  1. ユーザーにとって理解しやすいもの
  2. ユーザーがプロダクトから得られる価値と連動している
  3. ユーザーがプロダクトから価値を得れば得るほど、大きくなる
TuneCore Japan

チューンコアジャパンのサービスです。僕はほぼほぼ関わってないので、テキトーなことを書いています。

  1. Understand(プロダクトの価値)
    • 価値
      • 音楽を発表したい・販売したいという人が簡単に配信でき、売上を得ることができる。
    • 対価
      • 機能的対価
        • 自分の曲を様々なストアに配信できる
      • 感情的対価
        • ストアに楽曲が並ぶ
        • リリースして世間の人に聞いてもらえる
        • 売上が上がる
      • 社会的対価
        • 多くの人に聞いてもらうことでアーティストとしての認知度が上がる
    • バリューメトリクス
      • リリース数
        • リリース自体が目的の場合3つの条件にあてはまるが、売上が目的の場合は3つ目の条件(価値を獲れば得るほど大きくなる)は当てはまらない
      • 楽曲の売上
        • 3つの条件に当てはまりそうです
  2. Communicate(伝える)
    • 現在のプランはリリース数による課金です
      • そもそも、フリーミアムでもフリートライアルでもないですが、クーポンやキャンペーンででフリートライアル化している場合はあります
  3. Deliver(届ける)
    • 省略
ポイントモール

僕がメインで関わっているEDOCODEの事業ですが、そもそもフリーですね。 普段から使ったほうがお得ですが、ふるさと納税とか旅行とかで割と大きい金額使うときは、使わない手はないですよ!(「自分の使っているクレジットカード名 ポイントモール」とかで検索してみてください)

  1. Understand(プロダクトの価値)
    • 価値
      • ポイントモールを経由して買い物をすることで、通常より多くのクレジットカードのポイントを貯めることができる
    • 対価
      • 機能的対価
        • クレジットカードのポイントが貯められる
      • 感情的対価
        • ポイントが溜まって嬉しい
        • たまったポイントで買い物をお得にできる
      • 社会的価値
        • 特に無い気がしますが、余計にポイントが貯められていることを自慢できるかも?
    • バリューメトリクス
      • 獲得ポイント数
        • 3つの条件にあてはまりそうです
  2. Communicate(伝える)
    • そもそもフリーなので、料金設計はないです
    • サイトに来た人に価値を伝える工夫は必要そうです
  3. Deliver(届ける)
    • モールによりますが、ポイントを獲得した結果を見ることができます(ただし、仕組み上タイムラグが大きい)
    • モールによりますが、獲得できるであろうポイントの対象ショップを見ることができます(タイムラグが数日あります)
PUSHCODE

EDOCODEのもう一つの事業です。こちらにはそんなに関わってないので、テキトーなことを書いています。

  1. Understand(プロダクトの価値)
    • 価値
      • WebPushを通じて、サイトの運営者がユーザーとより良いコミュニケーションができるようになる
    • 対価
      • 機能的対価
        • ユーザーにWebPush通知を好きなタイミングで送れることで、タイミングを逃さずユーザーにアプローチできる
        • サイトのPVを増やすことができる
        • カゴ落ち防止に使うことができる
      • 感情的対価
        • 許諾数や通知に対する反応がわかることで、サイトに集まるユーザーが増えていることが実感できる
        • カゴ落ち防止からあがった売上を確認することで、売上が上がっていることが実感できる
      • 社会的価値
        • 効果的にWebPushを使うことで集客や売上を上げることができ、社内で評価される
    • バリューメトリクス
      • 配信数
        • 3つの条件にあてはまりそうですが、コミュニケーションが片思いに終わる場合もあるので、3つ目の(価値を得れば得るほど...)条件は使い方に依存しそうです
      • 配信から上がる成果(PVや売上等)
        • 3つの条件に当てはまりそうですが、1つめの条件(理解しやすいか)はちょっと考えどころというか見せ方に工夫がいるかもしれません
  2. Communicate(伝える)
    • 現状のプランは配信数です。一定配信数以下は無料のフリーミアムなプランです
    • 配信から上がる成果をプランに組み入れるのは、利用者にわかりにくいような気はしますが、ECサイトに特化したプランとかであれば、ありかも?
  3. Deliver(届ける)
    • 省略

トリプルAスプリント

プロダクトを改善するために、何が問題なのかを、迅速に特定し、解決し、効果を測定しなければなりません。 そのためのプロセスモデルです。

  1. Analyze(分析)
  2. Ask(質問)
  3. Act(実践)
Anayze(分析)

ビジネスのインプットとアウトプットを特定し、それぞれを分析します。

アウトプットは、例えば、以下のようなものです。

  • サインアップ数
  • 有料会員へのアップグレード者数
  • ARPU(顧客平均単価)
  • 顧客解約率
  • ARR(年間経常収益)
  • MRR(月間経常収益)

これらのアウトプットを生み出しているインプットが何なのかを特定する必要があります。

Ask(質問)
  1. 目的はどこか?
    • 売上とか、ビジネスがもっている目標
  2. 目的にたどり着くには何をすればよいか?
    • 解約率、ARPU、顧客数のいずれに注力すべきか?
    • 通常、解約率を下げればARPUは改善されるので、その後に顧客数を伸ばすことでARRが伸びる
    • それぞれがビジネスにどのような影響を与えているか把握する
  3. どのインプットに賭ければ良いか?
    • 注力すべきところがわかったら、それに一番効くインプットは何なのかを特定する。

改善すべき/導入すべきインプットが見つかったら、ICEフレームワークで、優先順位をつける。

ICEフレームワークは、

  1. Inpact(影響度) ... インプットがアウトプットに与える影響度
  2. Confidence(自信度) ... インプットがアウトプットを改善する自信がどれくらいあるか
  3. East(容易度) ... どれくらい容易に導入できるか

この3つを各5点ずつ配点して、合計点が高いものが優先度が高いとみなすという方法です。

Act(実践)

優先順位が付けられたら、後は実践するだけです。

ボウリングレーン・フレームワーク

穴を開ける方じゃなくて、ピンを倒す方のボウリングです。

「プロダクトの価値を顧客が正しく体験できている状態」を、

  • 「ボール」が「顧客の現在地」
  • 「ボウリングのピン」が「得られる成果」
  • 「ピンに届くまで」が成果が得られるまでの「時間経過」

を表しています。「ボール」が「ピン」に届いたら、「顧客」が「プロダクトからの成果」を得たということになります。

例えば、超単純に

  1. Web広告からプロダクトのサイトに遷移 => ボールの開始位置
  2. プランページを読む => ピンまでの途中(1)
  3. サインアップ => ピンまでの途中(2)
  4. 何かしらの成果を得る => ピンが倒れる

といった感じです。

この過程でプロダクトからユーザーが離れてしまうことを、ボールがガターに落ちることで表しています。

やることは、まず、

  1. ストレートラインを作成する
  2. プロダクトバンパーを設置する
  3. コミュニケーションバンパーを構築する

ストレートラインとは?

ユーザーが脇道にそれないように、プロダクトの価値を最短で感じ取ってもらえる最短距離をストレートラインと呼んでいます。

ユーザーがプロダクトの成果を得るために、それに「必須のもの」「オプショナルなもの」「不要なもの」のようなラベリングをして、ストレートラインは必須なもののみにして、最短で価値を提供できるようにすべきです。

バンパー

子供がボウリングで遊ぶときに、両脇にバンパーを設置しているの見たことありますかね?あれです。 プロダクトバンパーとコミュニケーションバンパーは、ユーザーがガターに落ちないように、防御するためのものです。

プロダクトバンパー

プロダクトバンパーは下記のようなもので、必要なものを取り入れたほうが良いです。

  • ウェルカムメッセージ
    • サインアップしたタイミングでユーザーに送るメッセージ
  • プロダクトツアー
    • 最短でユーザーに価値を届けられるように、ユーザーに何をするべきなのかを伝える。余計な選択肢は隠す。
  • プログレスバー
    • 価値が体感できるまで、現時点で何%まで来ているのかを視覚的にわかるようにする
  • オンボーディング・チェックリスト
    • プログレスバーが100%まで終わった後に、やるべき細かいタスクをチェックリストとして提示する
  • オンボーディング・ツールチップ
  • エンプティステート
    • プロダクトに最初にログインしたときに、ユーザーがこれから何をしないといけないかを見せる。
コニュニケーションバンパー

コミュニケーションバンパーは以下のようなものです。

  • ユーザーオンボーディング・メール
    • ウェルカムメール
    • 利用ガイドメール
    • セールスタッチメール
    • ...
  • プッシュ通知
  • 説明動画
  • ダイレクトメール

省略しますが、このあたりに、どういう観点で作るべきか、文例まで含めて載ってますのでかなり参考になると思います。

ユーザーごとの平均収益(ARPU)をあげる

ユーザーは誰か?というのは、疑問を挟む余地がないようにも思えますが、単にアカウントを作った人ではなくて、利用料を払っているユーザーとみなしたほうが良いとのことです。 ユーザーの定義が決まったら、ARPU(ユーザーごとの平均収益)の計算は以下のとおりです。

ARPU = MRR(月間経常収益) ÷ ユーザー数

ARPUを上げることがプロダクトの成長につながります。

チャーンビーストの退治

チャーン(解約)は低いに越したことはありません。PLGでは、「顧客維持率を5%あげるだけで、売上を25-95%改善できる」と書いています。

チャーンは単にユーザー数をみるだけでは不十分で、下記の3種類を見たほうが良いとのことです。

  1. カスタマーチャーン ... 一定期間に失ったユーザー数
  2. レベニューチャーン ... 一定期間に失った売上額
  3. アクティビティチャーン ... 解約リスクがあるとされるユーザー数

おしまい

以上、Product-Led Growthのまとめでした。書籍(Webでも)の方では、実例も豊富ですし、実際どうやったら良いか、まで書かれているので、ぜひそちらを読まれるのをお勧めします。

この記事の内容はほぼ書籍の内容ですが、https://productled.com/ にも関連情報は結構あり、参考になりました。

きっとこんなまとめ読んでる暇があったら、本買えば良かったと思うことでしょう!(その前に、長いからここまでたどり着く前に本を買ってるかもしれませんが)

人材募集

現在、Wanoグループでは人材募集をしています。興味のある方は下記を参照してください。 group.wano.co.jp

EDOCODEについては、以下をご参照ください。 go.edocode.co.jp