はじめに
本記事は、NewsPicks Advent Calendar 2022 の12/10公開分の記事になります。
taroxと申します。プロダクトマネージャーを担当しております。
ここでは toCプロダクトばかりを経験してきた筆者が、転職してtoBプロダクトのPdMを担当したことで、今まで腑に落ちなかった価値検証アプローチがしっくりきたことと、toCプロダクトにプロセス転用できるかも？と思ったことについてまとめたいと思います。
それを語るには先ず背景情報として、自分がIA（インフォメーション・アーキテクト）業務をしていた頃からお話ししたいと思います。
少し長文になりますがご容赦ください。
UXデザインとの出会い
私がUXデザインについて知ったのは2005年なので、今から17年も前になります。
当時web制作ディレクターとして、プロジェクトマネジメント兼コーダー兼Flasherとしてほぼ自分自身をディレクションするような形で仕事をしていました。
このままでは器用貧乏なキャリアを歩むことになってしまう、と漠然と不安を抱えていた私は、UXコンサルからWeb制作まで一気通貫して行う会社に転職しました。
そこで、IA（インフォメーション・アーキテクト）として着任し、UXデザインを知ることになりました。それまでのキャリアの中で、ユーザビリティとかアクセシビリティは知っていたし実践しようと努力していたのですが、それとUXデザインはなにが違うのだろう？と思いました。
当時のUXデザインの考え方はマーケティング的な考え方であり、「ターゲットユーザーとビジネスゴールをつなぐための体験を設計すること」という理解をしていました。
今思うと、この考え方はダークデザインを許容する考え方なので、余り良くない面もあったのですが、それまでは、HCDプロセスに準じてユーザー検証しながら制作などしてこなかったので、私に大きな気づきと成長をもたらしてくれました。
アジャイル開発との出会い
クライアントコンサルという立場での制作業務に徐々に限界を感じ始め、プロダクト運営会社に転職をしたのが2011年。ちょうどスマホシフトが始まった頃でした。
そこでは初めてスクラムでのアジャイル開発を体験し、開発ディレクターとしてエンジニアとプロダクトグロースするという仕事をしていました。
そこでは数値ドリブンでの意思決定に重点が置かれており、A/BテストとMAU、WAU、DAUといったユーザー軸のKPIモニタリングで数値検証を行いながら課題解決のプランニングをし、チケットを作成してカンバンで優先順位をきめて開発をしていました。今では当たり前ですけれども。
それまでの数値検証はSite Catalyst（現在のAdobe Analytics）による流入別PV,UUや経路分析などページ軸の分析が主だったので，特定人物の振る舞いをアクセスログで観察して課題を洗い出すユーザー軸の分析まではできていませんでした。
ただ一方で数値ドリブンだけでは、ユーザーインサイトに迫れないもどかしさも感じていました。あくまでサービス上のログしかわからないので、そこから類推できるインサイトというのはかなり断片的なものです。
以前のクライアントUXコンサルをしていた時のように、調査会社に依頼してターゲットユーザーをリクルーティングしてアンケートを実施し、インサイトを明らかにできれば良かったのですが、日々運営をするプロダクトにおいて実施するのは費用的に難しく、そういった取り組みはできませんでした。
クライアントUXコンサルは年に一回くらいのペースでやっていたので予算確保できていましたが、プロダクトグロース業務だとその時間軸はフィットしません。都度インサイトが知りたいが費用的に厳しいからできないというモヤモヤを抱えてプロダクト運営をしていました。
*今みたいにネットプロモータスコア（NPS）を取りに行くみたいな話は、日本ではその直後くらいから広まっていきました。2013年以降くらい。
新規事業開発との出会い
2012年にリーンスタートアップの日本語版が発売され、リーンキャンバスを用いた新規事業起案のムードが高まっていた頃、私も新規事業開発のノウハウが知りたくて、2013年に新規事業開発が得意な事業会社に転職をしました。
そこでPSF（Problem Solution Fit）の考え方とPMF（Product Market Fit）の考え方など新規事業を起案する上で重要な考え方を学びつつ、既存事業の運営をしていました。
また、前職の頃はなかったグループインタビューやデプスインタビューを比較的安価で実施できるサービスも増えてきて、要所要所でインサイトを確認しつつ、数値ドリブンの意思決定するためのデータ基盤やBI整備などもやりました。
ただまたモヤモヤする出来事にぶつかりました。プロダクトの起案時はPSFやPMFを重視してユーザーファーストな価値提供をしようと取り組むのに、売上げ目標を持たされたプロダクトは、売上＝KGIオリエンテッドになってしまいユーザーのことを見なくなり、ダークパターン・デザインも平気でやってしまうという状況を目の当たりにしてしまいました。
また、グループインタビューをたくさん回しても、本当にあなたのその考えは全体最適に値するか、というところでもモヤモヤしていました。
5人にユーザーテストすれば80％くらいのユーザビリティの問題を発見できると言ったヤコブ・ニールセン博士の言葉がミスリードして伝わって、5人に聞けば良いとかよくわからないこという人がいますけど、それは違います。
母集団と同じユーザー構成のサンプル集団を作って、その人たち全員に意見を聞けば統計的に正しいインサイトが得られると思いますが、そのサンプル集団を作るのが本当難しい、というか無理。調査会社でのリクルーティングをする時点でユーザーに偏りがでていますから。
toCプロダクトのユーザーインサイトをつかむ難しさ
本当にtoCサービスにおいて正しいユーザーインサイトをつかんで、バリュープロポジションキャンバスを書いてPMFしていくのは難しいです。
それは声を上げないユーザーが多数派なので。サイレントマジョリティというやつですね。
また、そのような人達にフォーカスを当ててグループインタビューをしても、プロダクトへの思い入れがない人が多く、たいしたフィードバックを得られないという点もより難しくしています。
toCプロダクトは大体上記のような悩みを抱えているので、次の2つの方向性をとることになります。
- 1.数値ドリブンでA/Bテスト偏重主義
- 2.PO/PdMのセンスドリブン
1は全ての施策の効果をA/Bテストの評価で行って、善し悪しを決めるという割り切りをしたもの。
ただA/Bテストにはいくつかの条件がありまして
- 正規分布する確率にしか適応できない。
- サンプルサイズに達さないデータしか集まらない場合、評価できない
というポイントがあります。ですのでA/Bテストを実施できるものはかなり限定されてしまいます。
2はプロダクト責任者のセンスで正しいと思う方向に倒すというやり方ですが、プロダクト責任者がITリテラシー高すぎたりすると、利用者のインサイトとズレまくって、結果ユーザーが離れていってしまうということは往々にしてあります。
2で行く場合は、ハレーションが起きたら素直に謝ってピボットする姿勢が大切だと思いますが、責任者のセンスドリブンだと認めたくなかったりもしますし、全体の数値に悪影響があまりなければ、ハレーションが起きてもスルーされがちです。
アクセス数が多ければ多いほどこの傾向になりがちですが、ファン心理に大きな傷を与えてしまったことを重要視すべきだと思います。
ただし、一部の声の大きなマニアのクレームをスルーする必要はありますので、そのハレーションはどっちなのかを判断しなければなりません。これもとても難しい判断になります。
toBプロダクトの価値検証アプローチ
toCプロダクトのPMFの難しさにくじけて一旦プロダクト運営から離れ、バックオフィス的な仕事やデータ分析担当などを一時期していたのですが、またプロダクト運営したくなり、転職してtoB SaaSのPdMを担当することになりました。
転職した会社は前任者の方がすでにtoB SaaSにおける業務フローを設計しており、PdMとしてどう振る舞えば良いのかが業務をこなすことで理解できる状態になっていました。これはとても幸運だったと思います。細かなところはブラッシュアップする必要がありましたが。
まずtoC/toB関わらず、プロダクトを磨き込むには2つのアプローチがあります。
価値検証アプローチと課題発見アプローチです。
価値検証アプローチとは、仮説をユーザーにぶつけて価値があるかどうかを調査する手法です。
課題発見アプローチとは、利用者の声を集め、抽象化した上でどう解決していくか考える手法です。
toCプロダクトだとそれらのアプローチは以下のようになります。
- toC課題発見アプローチ：アプリストアのレビューを読んだり、UTやデプスインタビューなどを行うことで課題を発見して改善していくアプローチ。ただこれも声の大きな人のニーズがズレてたりすると、プロダクトをおかしな方向に開発してしまうことになったりするので、だんだん誰の声を聞くべきかわからなくなってくる。
- toC価値検証アプローチ：プロダクト・ビジョンに沿った提供価値を仮説立て、MVPの状態でリリースし世の中の反響を鑑みながら、手探りでMVPからフルスペックの状態に開発を進める。世に問うスタイル。ただ、ユーザー数が増えてくるとどんどんサイレントマジョリティが増え、どっちの方向に開発して良いかわからなくなってくる。上記に書いたとおり。
これに対してtoBは以下のような感じ。
- toB課題発見アプローチ：カスタマーサクセス他から報告される各クライアントの課題を整理し、解決策をプランニングしてPRD（プロダクト要求仕様書）にまとめ、エンジニアとキャッチボールしながら開発・リリースするアプローチ
- toB価値検証アプローチ：プロダクト・ビジョンを実現するために必要な価値を先ず仮説立て、その仮説をクライアントにレビューしプロトタイピングすることで検証するというアプローチ。
toBプロダクトのPdMをやり始めてすぐに気づいたのですが、toBプロダクトはtoCと違ってヒアリングすべきユーザーに直接アクセスすることが可能なので、CSサーベイなどを行ったり個別インタビューを実施することで、ユーザーが増えてもユーザーインサイトの解像度を下げずに開発継続できます。
toC運営していたときにはもやもやしていましたが、toBは価値検証を行いながら継続的にプロダクトグロースすることが可能なので、IAの頃からやっていたUXデザインとアジャイル開発とPMFユーザーファーストな思想の歯車がすべてかみ合った感触を得ました。
迷いの森に入らずtoCプロダクトをグロースするには？
ついぞtoCプロダクトグロースの方法が見つからないまま、toBプロダクトのPdMにキャリア・スイッチしたのですが、1つ思ったことがあります。
toBプロダクトとtoCプロダクトを重ねてしまえば、toBプロダクトから得られる解像度の高いユーザーフィードバックの方向性で、toCプロダクトも開発できるのではないだろうか？
これはプロダクト・レッド・グロース（PLG）の考え方に似ているところがあります。
PLGは雑に説明すると「営業を介さずにプロダクトがプロダクトを売る仕組みでユーザー拡大する」というtoB SaaSの戦略のことです。
- 1.プロダクトリリース時はフリーミアムでリリースし、営業は一切せずサポートもなし。
- これはtoCのMVPをリリースして世に問うスタイルに似ています。
- 2.カード決済＋有料会員向けの機能をつけ、有料会員化を促す。テックタッチサポートを行う。
- テックタッチサポートとはZendeskなどでヘルプサイトを構築・提供し、ユーザーの自己解決を促す。
- 3.大きめのクライアントが利用し始めたら、そのクライアントに対してハイタッチ、つまりAE（アカウントエグゼクティブ）やCS（カスタマーサクセス）担当者をつけ、重要顧客のニーズを聞きながらエンタープライズ版をリリースし、プロダクト育成・ユーザー拡大を行う。
1の状態ってtoC SaaSの状態に似ているというかほぼイコールだと思います。2は中間の状態、3の状態はtoB SaaSそのものです。
よく例に挙がるのが、ZoomとかSlackです。
- 1は無料版Slack
- 2はSlackPlus
- 3はSlackEnterpriseGrid
に対応します。
ここで重要なのは、2,3の段階に入ったら事業戦略の本丸は2,3にシフトすることです。
1はあくまで入り口でしかないです、有象無象のユーザーがどんどん入ってくるので、1→2は有料機能お試しとかで2への以降を促し、2→3は営業を介してハイタッチで伴走します。
世の中の伸び悩んでるtoCプロダクトはPLGの手法に則ってtoBプランを設定し、解像度の高いクライアントのフィードバックを使ってプロダクトグロースすることで、迷いの森から抜け出せるのではないでしょうか？
おまけ：toBプロダクトグロースの落とし穴
先ほど、価値検証アプローチと課題発見アプローチについて解説しましたが、toB SaaSは課題発見アプローチによりがちです。
CSが顧客とハイタッチで向かい合っているため、そちらの課題をなんとかしないといけない、という圧力が高まってしまうためです。
ただ、プロダクトは2つのアプローチ、どちらに偏っても歪な者になってしまいます。
価値検証アプローチだけで開発していると、ビジョンドリブン過ぎて、現場のユーザーが本当にほしい価値がいつまで経っても実装されない状態になります。
課題発見アプローチだけで開発していると、フィードバックをよく上げるクライアント用のプロダクトにどんどんなっていき、個別最適化してしまいます。機械学習における過学習のような状態になってしまいます。
偏らないようにプロダクト育成するために、「プロダクトOKR」を先ずは設定します。その前にプロダクト・ビジョンが策定されてないといけないですが。
プロダクトビジョンからプロダクトOKRを作成する流れは以下の通りです。
- 1.プロダクト提供価値に沿ったプロダクトビジョンを策定したあと
- 2.売り方戦略を設計し、
- 3.顧客拡大に沿った優先順でのプロダクトロードマップを策定し
- 4.クォータ単位でのプロダクトOKRを策定する
という流れです。
プロダクトOKRを策定することで、2つのアプローチを偏らずにプロダクトグロースする道しるべになります。
もしプロダクトOKRを策定してなければ、必ず策定するようにしましょう。
組織OKRだけだと、組織のミッション達成が目指すべきゴールになってしまい、プロダクト運営とは別の方向性の話になってしまいますので注意しましょう。