さらば、全ての使われないプロダクト。
PdMノウハウの第9回目のnoteです。第8回目のnoteは「PdMがUX改善のために読んでよかった記事まとめ」でした。もし良ければ読んでいただけたら嬉しいです。今日は「さらば、全ての使われないプロダクト。」というモジったタイトルで、使われないプロダクトを創ることなく、プロダクトを成功に近づけるノウハウを言語化したいと思います。このノウハウは僕が今までプロダクトマネージャーとして考えてきたものを言語化したものであり、正しいとは限りません。参考にしていただき、自身のプロダクトが1mmでも成功に近づけば幸いです。僕が所属している組織について、このnoteで言及している概念については全く関係がないことを最初に明記させていただきます。
"プロダクト"とは何であるか
この記事では「プロダクト」という言葉を多用します。そのため、始めに「プロダクト」とは何かということを定義したいと思います。あくまでこの記事内の中での定義ですので、他で同じ単語を使った時とは同じ意味ではないことをご了承ください。
1つのプロダクトとは、ユーザーの1つの課題に対するソリューションである。
つまり、ユーザーが認知しているプロダクトの中には複数の"プロダクト"が内包していると捉えることができます。
具体的には、Spotifyというプロダクトの中には「楽曲」と「ポッドキャストと番組」という複数のプロダクトが存在します。他にもSpotifyには様々な機能が実装されています。
僕の場合ですが「楽曲」は毎日使っていて、通勤時間や仕事で集中したい時、家でゆっくりしている時のBGMとして利用しています。一方で「ポッドキャストと番組」はTwitterでシェアされているポッドキャストを主に聴いていて、集中やリラックスが目的ではなく、情報収集を通した自分のアップデートが目的です。つまり、同じSpotifyというプロダクトを使ってはいますが、自分の複数の課題を解決するために異なる機能を利用していることになります。
この記事では、僕が大好きなプロダクトの一つであるSpotifyを例に主題を説明していきます。このnoteは一つのプロダクト、つまり一つの機能を担当していたとしても、解決している課題がその他の機能と異なるならば、"プロダクト"と考え、出来る限りお役立ちできるように書いていきたいと思います。
リーンなプロダクト開発
僕のnoteやTwitterで何度も紹介させていただいているスライドですが、主題に大きく関係してくるので再度掲載します。このスライドには、不確実性が高い状況において、プロトタイピングを用いた不確実性の落とし方を紹介しています。すでに、このフレームワークに行きついてから数年が経ったので、新しいフレームワークが登場していると思いますが、僕はまだこのフレームワークは、使われない機能を創ってしまわないために有効であると考えています。しかしながら、新しい"プロダクト"を創るにあたり、対ユーザーに対して使われるかどうかという不確実性の落とし方だけでは、不十分であるとわかってきました。
つまり、リーンなプロダクト開発はユーザーを巻き込んだ不確実性を落とすための方法であり、新しく"プロダクト"を創っていくためには、社内の協力を得て、進めて行かなければ最高の"プロダクト"は創れません。このnoteでは、全員が一つのプロダクトに向き合っているスタートアップ立ち上げ期の話ではなく、既存事業が存在している中で、新しい"プロダクト"を創っていくためにはどうすべきかどうかについて書かれています。
プロダクトは複数のプロダクトを内包する
プロダクトは複数のプロダクトを内包する。この概念についてご紹介します。僕はプロダクトの中に新しい機能を開発することを何年も行ってきました。1つのプロダクト、今回の例でいうとSpotifyにはリテンションカーブが存在しています。リテンションとは、ユーザーがプロダクトを使い続けてくれているということを数値化したものだと捉えられます (継続率 : リテンション・レート、以降単純に「リテンション」と呼ぶます) 。
リテンションはプロダクトがどんな課題を解決しているかに依存します。SNSやニュースなどユーザーとの接触頻度が高いプロダクトはリテンションが高い傾向にあります。一方で、例としてSUUMOを挙げますが、不動産のプロダクトは、引越しを検討した時くらいしか訪れないので、物件が決まる1ヶ月弱はリテンションが高いとは思いますが、それ以降は数年ほとんど使われないと考えられます。この次に説明しますが、リテンションはユーザー一人一人の文脈によるので決めつけることできません。実情は、かなり複雑です。つまり、プロダクトは解決している課題によってリテンションがほとんどの場合、ある程度一定に収束します。日常生活において、月に数回しか使われる機会がない課題解決をしている"プロダクト"が、毎日使われるために一つの課題解決を改善していっても仕方がないわけです。
アンドリュー・チェンが公開している、「アプリカテゴリ別でみるロイヤルティ」の図表を日本語化しました！
— スタタイ｜スタートアップのWikipediaを作る (@Startuptimez) February 15, 2021
縦軸：1週間あたりの使用頻度
横軸：90日間でのリテンションレート
28個のアプリカテゴリを非常に細かく分類しており、プロダクト開発の参考になるのでぜひご覧ください。 pic.twitter.com/sARsOEpD5i
しかしながら、プロダクトの創り手としては毎日愛されるプロダクトにしていきたいわけです。もっと現実的に言えば、ユーザーの可処分時間や可処分所得は有限です。日本だけで考えれば、人口は減り続けていて、所得はほとんど上がっていません。その有限の時間とお金を、GAFAを始めとした最強プロダクト、今ではBATHのようなさらに強い中国勢のプロダクトと共に奪い合っています。今ですら、日々の時間をTwitterやInstagram、Tiktokといったような巨大SNSに使っていると思われますが、数年後には日本のプロダクトが駆逐されていてもおかしくないわけです。それぞれのSNSで疲れたユーザーがバーティカルなコミュニティを形成する流れがありますが、人やお金、世間の注目は集約されていくように思います。
前段が長くなってしまいましたが、解決している課題によって"プロダクト"のリテンションがある程度決まっていると仮定すると、多くの人に長く使ってもらうプロダクトにしていくためには、解決できる課題を増やしていくことになります。多機能化です。その最たるものが、中国のスーパーアップでしょうか。日本でもLINE、PayPayのように一つのプロダクトの中で何でもできてしまうようなプロダクトが出てきています。
1つのプロダクトが、複数の課題を解決できるようになるということは、それぞれの課題解決をしたいという志向を持ったユーザーが訪れることになります。解決したい課題によって文脈が異なるわけです。これは端的に、1つのプロダクトが複数の"プロダクト"を内包している状態であり、1つ1つの"プロダクト"のリテンションの複雑な集合体として、母体となるプロダクトのリテンションが規定されることを意味しています。
Spotifyの例で紹介します。僕はSpotifyというプロダクトを主に2つの課題を解決するために利用しています。2016年から有料会員で、音楽系プロダクトはSpotify一筋です。利用し始めたころは、音楽しか聴いてなかったのですが、コロナ禍になってから、ポッドキャストが増えたということもあり、情報収集を通した自分のアップデートを目的にSpotifyを利用するケースが増えました。Twitterや社内Slackでシェアされたリンクから開くこともありますが、音楽を聴くために開いた時のレコメンドや能動的に探しにいくこともあります。しかしながら、音楽を聴くのは毎日ですが、ポッドキャストを聞くのは週に何回かあるかくらいです。利用時間も大きく異なります。
仮にSpotifyがポッドキャストのみのプロダクトであった場合、僕がSpotifyを利用するのは週に数回であり、一回あたり30分程度でしょうか。これは想像の域を出ませんが、毎日ポッドキャストを聞いているコアなユーザーは音楽を聴いているユーザーから比べると少ないとすれば、ポッドキャストのみのSpotifyの利用機会は音楽が聴ける場合と比較すると大きく落ち込むと考えられます。
つまり、Spotifyは音楽が聴ける体験に加えて、ポッドキャストが聴けるという体験が構築されているが故に利用機会が増えています。単純に考えれば、音楽 + ポッドキャストの機能の足し算だと思われますが、二つの異なる課題解決を1つのプロダクト上で表現して、自然な体験としてマージしていくことは非常に難しいことです。
日本ではSmartNewsでクーポンや、雨雲レーダーなどの複数の課題解決ができるようなプロダクトが出てきています。それまでのニュースのカテゴリをタブとして増やしていくのと加えて、異なる改題解決体験を実装していくことはただ単に、機能を実装するだけではない難しさを秘めています。
複数プロダクトの難しさ
まずプロダクトマネージャーが解くべき最も難しい課題は、ユーザーに使われるプロダクトを創るということです。「Make something people want」です。これが最も難しいことは全てのプロダクトマネージャーが経験していることでしょう。使われるプロダクトを創るためのアプローチは、世界に山ほどあります。しかしながら、打率が100%のプロダクトマネージャーは世界にいないかも知れません。僕のアプローチが、上で紹介しているリーンなプロダクト開発になります。
しかしながら、使われるプロダクトを実装すれば全てが上手くいく、というわけではありません。今回は、既存プロダクトに新しい課題解決 (= "プロダクト") をマージしていくことについて考えますが、根本的には別組織として切り出された新規事業でも同じことが言えますと思います。ユーザーに使われるかどうかという最も難しい課題を解決するに加えて、組織の課題についても向き合い続けなければなりません。
ユーザーに使われるかという課題も組織の課題もプロダクトによっても変化します。BtoC、CtoC、 BtoB、BtoBtoCなど、プロダクトが提供している価値のシステムが変われば、自ずと直面する課題も変化します。
今回は組織の課題を、開発、セールス、マーケティングという側面から考えます。
価値をシンプルにしよう
アーリーなスタートアップでは、ほとんどの場合は1つのプロダクトに全員がフォーカスしていると思います。組織やプロダクトのフェーズが進んでくると、このnoteの主題である多機能化、多事業化していくとなると、限られたリソースをどこに使うべきかを考え抜く必要があります。リソースとは、人員だけではなく、お金や脳のリソースなど様々です。リソースを分配していくに当たり、それぞれのステークホルダーはどのくらいのリソースを投じれば、どのくらいの効果が得られるかということが判断に必要です。とてつもなくリソースを投下しても、得られる効果が未知数では投資対象とするのは難しいです。
つまり、新しい"プロダクト"を担当しているプロダクトマネージャーは、各ステークホルダーに対して、投資をすることでどのような価値が得られるのかを明確にしなければなりません。そして、明確にすべき価値はシンプルである必要があると考えています。
Spotifyを例に考えます。音楽を聴くという価値に加えて、ポッドキャストという新しい課題解決を加えていきます。
最初にマーケティングでいうと、ポッドキャスト機能を加えることで、新しいユーザー層を獲得できる可能性が生まれます。そのため、ポッドキャス経由での新規顧客獲得が価値かも知れません。既存の音楽のみを聴いているユーザーにとっては、利用機会の新規創出による全体のリテンションの向上、その先には新規プレミアム登録が待っていると思います。その価値を創出するために、ユーザー獲得の広告投下やポッドキャストを投稿してくれるユーザーコミュニティの構築が必要です。または、アプリ内での認知拡大施策も必要になってくるため、何かの指標が減少してしまうかも知れません。
次に、セールスとしての価値で言えば、ポッドキャスト機能経由での広告収入でしょうか。「Spotify、ポッドキャスト強化は2020年も止まらない。広告収入、リスナー急増のポッドキャストで、どこまで音楽との融合は可能か」においても広告収入について言及されています。ユーザーのトラフィックが集まるところには、それに適したフォーマットの広告が生まれてきます。ユーザーの耳の時間を占有している際に、音声広告を流すことで広告収入を得ることができ、今までSpotifyにいなかった層である情報収集をしているユーザー向けには効果的なものとなるでしょう。プロダクトは結局のところ、持続性を担保するためにマネタイズをしなければなりません。マネタイズになんの関係もないプロダクトは自然淘汰されてしまう可能性が高く、プロダクトをサスティナブルなものにしてくためにはセールスチームの協力が必要不可欠です。これが、BtoBのSaaSのようなプロダクトであれば、クライアント獲得とプロダクトは密にコミュニケーションする必要があります。
開発組織がどのようなミッションがあるかによって示すべき価値は異なります。明確に、ユーザーのリテンションなどの数値的指標を持っている場合には、それが上がる根拠を示す必要があります。Spotifyの組織構造がどうなっているかわからないですが、ポッドキャスト機能はユーザー体験を大きく向上させることに寄与していると思います。その結果として、アプリ内における様々な指標が向上すると仮定されるなら、その実装に対する開発リソースを投下する意思決定がしやすいです。どの会社も特に開発リソースが枯渇しているケースが多い中で、1秒での意味があることに開発リソースを割かなければ死活問題となります。そして、開発リソースは潤沢なものではないので、できる限り少ない開発リソースで最高の結果が得られるということをプロダクトマネージャーは示さなければなりません。そのためには、無駄な開発をリソースを使わないこと、ミニマムの価値を考え抜いて説明する責任があると考えています。
KPIを明確にして、可視化しよう
新しい"プロダクト"の担当をしたことがあるプロダクトマネージャーなら1度は直面している課題だと思いますが、新しいことを始めるためには周りの協力は必要不可欠です。本来なら良い線をいっていたのにも関わらず、協力が得られずに沈んでいったプロダクトは世の中にたくさんあると思います。イノベーションのジレンマとも表現されるかも知れません。一方で、協力体制の構築は一方的なtakeだけでは成り立ちません。各ステークホルダーにとってどのような嬉しいことがあるのかを考え抜いて、バランスを取る必要があります。どこかに重心を傾けすぎても上手くいくことは考えにくいです。それは時間経過によって解決される歪みなのか、中長期を見据えたバランス感覚と説明責任を果たしていく必要があります。
新しい"プロダクト"のしくじりに、KPIの設計ミスが大きいと考えています。各ステークホルダーは、常に最適なリソース配分を考えています。つまり、新しい"プロダクト"とはいえ、投資すべきかどうかを常に考えられていると言えます。状況が常に変わる時代において、リソース配分のミスは死活問題に直結するので、状況が変われば最適な組織も変わってくるのです。新規"プロダクト"のプロダクトマネージャーは常に、シンプルなKPIを設計して、それにコミットしていることと、進捗を報告していく義務があります。
KPIを極限までシンプルにした方が良いと思うのは、人間の認識を合わせていくのは非常に難しいからです。新規の"プロダクト"に投資をしている各ステークホルダーを始めとして、会社の中に暇な人は一人もいません。日々、難しい意思決定や難易度が高い業務に向き合い続けているので、協力をお願いする側の事情が複雑すぎると、覚えておくことが困難であり、認識の違いも生じてしまうことになります。とはいえ、新規の"プロダクト"が抱える課題はどれも複雑に絡みあっているので、それをいかにシンプルに伝えることができるのかがとても重要です。「〇〇を実現するために、〇〇という数値に全集中しています！」と一言で言えるくらい、解像度を上げつつ、適切な情報を提供して、認識を揃えていく必要があります。プロダクトマネージャーは、プロダクトを成功させるために、常に自分たちのプロダクトの情報をシンプルに保ち続ける必要があります。
そして、シンプルにした数値を可視化していく必要もあります。周りから何のために、何をしている人たちかわからないと思われている状態では、協力体制をつくっていくことは難しいです。そのためには、物事をシンプルにするのと同じく、KPIを可視化して常に閲覧可能な状態、聞かれたらすぐに答えられる状態にしておく必要があります。細かい手法については以下のnoteで記載してあるので、お時間ある方はご覧ください。
引き算の勇気
プロダクトには常に不確実性が存在します。どれだけリソースをかけても、どれだけ愛を注いだとしても使われない機能は使われないのです。時代を先取りしてしまったかも知れないし、もともとニーズなんて存在しなかったのかも知れません。使われない機能をどうやって判断するか。
明確な撤退基準を設けるというケースもあるとは思いますが、個人的には半年から1年は運営してみないと、そのプロダクトの価値を真に理解することができないと思っています。また、ユーザーには慣れるための期間が必要です。数週間のリテンションを見たり、利用率をみただけでは習慣化したかどうかなどは判断つかないと思っています。
このnoteで1つのプロダクトは、複数のプロダクトを内包しているという概念を書きました。1つのプロダクトにはそれに相当するリテンションのカーブが存在しています。それらを一元的に管理するのがまずは一歩だと思っています。BIツールを使ってもいいでしょう。全ての機能において、健全であるかどうかを定期的にチェックする仕組みを構築するのがいいと思います。
また、定性的にもユーザーにとってどのような価値を示したかどうかを見る必要があります。「たった一人の分析から事業は成長する 実践 顧客起点マーケティング」で示されている5つのセグメントに対して、仮説を立ててユーザーインタビューしてみると良いと思います。
自分たちが考えている仮説通りの行動変化や習慣化がなされているかをセグメントごとにチェックしてみてください。それが可能になるのが、リリースから半年から1年後くらいになると思っています。
もしも、自分たちの仮説が異なっていて、定性的にも定量的にも使われないプロダクトであるという結論になり、自分たちの信念も突き通せなくなってしまった場合は、勇気をもってクローズする意思決定をすることもプロダクトマネージャーの責務だと考えています。
使われていない機能がプロダクトに実装されていることはユーザーにとっても社内にとっても幸せなことではありません。ユーザーが1つのプロダクトで使う可処分時間は限られています。その可処分所得を少しでも本来解決したかった課題に向かうようにフォーカスさせることも重要です。少なからず気に入ってくれているユーザーもいて、突然のクローズに対して反発する声もあると思いますが、真摯に向き合って対話をしていき、クローズさせることが大切です。その時の熱量が高かったとしても、ずっと使い続けてくれる人は新しい状態に慣れるものです。Twitterの新しいUIに対して、使い慣れないと思っていも、今は昔のUIを忘れてしまったほどに使い慣れているのです。プロダクトとはそういうものです。
プロダクトを成功させるために
1つのプロダクトには、複数の課題解決ソリューションが内包されている (それも1つの"プロダクト"と扱う) こと、本当に使われるプロダクトを創るための開発フレームワーク、さらにはそれらを取り巻く組織上の課題について考えていることを言語化してきました。まだまだ言語化できていない部分が多く、間違った考えも多いことのように思います。
プロダクトマネージャーとしての僕の命題の一つに、プロダクトマネジメントの再現性を高め、素晴らしいプロダクトが世の中に増え、結果として人々が幸せにしたいという想いがあります。常に"失敗"という経験の連続で、心が折れてしまいそうなことが多いですが、しくじり1つ１つに向き合って、次はどうすればいいか、僕と同じ失敗をしていかないために、ナレッジをどうに言語化して共有すればいいのか、常に悩まされています。
このnoteを通して、新しいことを成し遂げようとしているプロダクトマネージャーの方の少しでもお役に立てたら嬉しいです。
この記事が気に入ったらサポートをしてみませんか？