「企業価値2倍のPLO企業とは？」プロダクト・レッド・オーガニゼーション著者 横道 稔

2021年10月発刊の『プロダクト・レッド・オーガニゼーション』は、顧客に愛されるプロダクトを組織として作る方法や思想が数多く紹介されています。今回 Forkwell は書籍の翻訳者であり企業のプロダクトマネジメントアドバイザリーを務める 横道 稔 氏を招き、以下のような疑問に答える勉強会を開催しました。

• 顧客体験を中心に据えたプロダクトをつくるには何が必要なのか？
• プロダクトジャーニーを実現する組織作りの方法は？
• 優れたプロダクトを作る為のデータ活用とは？

プロダクト・レッド・オーガニゼーション（プロダクト主導型組織 / PLO）とは

これはPLOというよりプロダクトについての記載ですが『プロダクト・レッド・オーガニゼーション』の冒頭部分を引用します。

この辺りはプロダクトの重要性が叫ばれて久しいので、あまり違和感がないのではないでしょうか。

• あらゆる営みのど真ん中にプロダクト体験を据える
• すべての部門が狂気じみたようにプロダクトに集中する
• プロダクトはただの顧客体験の一部分ではなく、 体験そのものなのだ 
• 営業、マーケティング、教育、サービス、サポートは、 プロダクトの中で一つにまとまるべきだ

プロダクト主導型組織（PLO）が登場した背景

1.  データの影響力が向上

以前に比べ、データ取得やデータ分析しやすい環境になってきています。

2. 市場の過密

プロダクトが参入する市場が過密化しています。つまり新しいアイディアや人目を引くマーケティングだけでは勝てないので、そこにグロース戦略が必要になってきています。

3. 購買者の変化

IT部門だけでなく実際に使用した社内のエンドユーザーが購買者になってきています。現場が「これは使いやすい！」「役に立つ」と判断し導入に至るケースが増えています。

4. プロダクトのためのシステムが登場

データ収集 / 分析、フィードバック、アプリ内ガイドなどツールの一般化などが、非常に増えています。日本でも国産ツールが出始めているように感じます。

PLG企業の企業価値の中央値は、SaaS企業全体の2倍

プロダクト主導型組織（PLO）で期待できる効果として下記の5つがあげられます。

1. より柔軟で変化に強い
2. より早いイノベーション
3. より大きな価値提供
4. 収益性と顧客維持の向上
5. 効率的な拡大

ベンチャーキャピタルのOpenView社曰く「PLG企業の企業価値の中央値は（上場の）SaaS企業全体の2倍」だそうです。つまり、それぐらい市場から評価される傾向があるということです。

プロダクト主導型組織（PLO）の特徴をひっくり返してみた

『プロダクト・レッド・オーガニゼーション』は、あらゆるトピックを広範囲に取り扱っているので、本日は書籍冒頭で紹介されているこの5トピックをベースに紹介します。書籍の内容のままだと「そうだよね」「当たり前過ぎてピンとこない」と思うので、あえてひっくり返すことで自分ごと化できるのでは？という試みをしてみました。

プロダクト主導型組織（PLO）の特徴		ひっくり返すと…
プロダクトに地位を与える	⇄	プロダクトに地位なんていらない
データインフォームドである	⇄	データなんていらない
顧客に共感的である	⇄	独善的である
組織内はプロダクトを中心に協調的である	⇄	組織は縦割りである
プロダクトこそが顧客体験である	⇄	プロダクトと顧客体験は別物である

※書籍には書いてありません。

耳が痛くなければ、プロダクト主導型組織（PLO）かも

下記で紹介するチェックポイントを活用してみてください。耳が痛くなければ、あなたの組織はプロダクト主導型組織（PLO）かも知れません。

1. プロダクトに地位を与える

✔︎ プロダクトチームに企業のロードマップを推進・戦略を策定し、目標設定する正式な権限がある

✔︎ CPOを会社に置くことで、プロダクトの重要性を内外に示す

【ひっくり返すと……】プロダクトに地位なんていらない

✔︎ プロジェクトチームは、CTOや偉い人が決めたロードマップ、戦略、目標を遂行するだけで良い

これは、ちょっと辛そうですね。

✔︎ プロダクトのことをよく知っている役員がいない

なかなか良い意思決定ができなさそうな雰囲気がありますよね。

2. データインフォームドである

✔︎ 定量 / 定性両方のプロダクトメトリクスや先行指標を利用して意思決定をする（データインフォームド）

HiPPO（Highest paid person’s opinion）という言葉があります。最も報酬を得ている偉い人の意見で意思決定をすることです。「データがあればデータを見よう。意見しかないのであれば私の意見にしよう」という例えがあります。HiPPOで意思決定ばかりしているような文化は、PLOではないかも知れません。

*データインフォームドとは？

データを一つの情報として取り扱い、意思決定をするという意味です。類似する言葉として「データドリブン」があげられます。データドリブンはデータを起点にして意思決定をする考え方なので、よりデータ至上主義に近いかも知れません。

【ひっくり返すと……】データなんていらない

✔︎ プロジェクトチームは、CTOや偉い人が決めたロードマップ、戦略、目標を遂行するだけで良い

3. 顧客に共感的である

✔︎ 顧客と共に過ごし、顧客のジョブが何かを理解し、ペインを解決するプロダクトを作る

本当に顧客が欲しいプロダクトはなにか？顧客が何を解決すべきで、何を達成すべきなのかを理解しプロダクトを作ることが重要です。

✔︎ 顧客が価値を早く感じられるようにオンボーディング機能を設計する

オンボーディング機能は当たり前のようにあらゆるプロダクトに実装されていますが、その目的は顧客が利用する価値を見出すことにあります。

✔︎ フィードバックを積極的に集め、すぐに応えられなくても誠実にコミュニケーションを決着させる

「あなたの意見はどうなったのか」や「取り入れられないけれども、こういう代替案がある」とか「こういうロードマップで進んでいます」といったものを提示することで、フィードバックを言ってよかったなと思わせるということも非常に大切です。

✔︎ データを利用したカスタマーヘルススコアを算出し、推移に応じて顧客の課題にあらかじめ手を打つ

【ひっくり返すと……】独善的である

✔︎ 自分たちの都合で作ったものを売る

✔︎ プロダクト導入がゴール

✔︎ 顧客が活用できるかどうかは顧客の責任

✔︎ オンボーディング機能は、プロダクト側が欲しい情報を入力させている

顧客目線ではなく、プロダクト側が欲しい情報を入力させていませんか？これだと顧客にとっては邪魔なだけになってしまいます。

✔︎ 顧客からのフィードバックは聞かない、もしくは聞きっぱなし

✔︎ 顧客維持は顧客と相対するセールス担当の感覚のみが大切

顧客維持（リテンション）はSaaSモデルにおいて重要なトピックですが、ここを人間の感覚のみに頼っているのは、PLOではありません。

4. 組織内はプロダクトを中心に協調的である

✔︎ 「プロダクト自体が顧客獲得ツールになるためには？」を マーケティング担当と共に考える

✔︎ 「トライアル顧客のCV率最大化のためにプロダクトをどう活用するか？」をセールス担当と共に考える

マーケティング活動で獲得したトライアル顧客を有料会員にするために、どうプロダクトを良くしていくかという目線を、日頃から顧客と対峙している セールス担当と共に考えることが大切です。

✔︎ 「データから得られる成功顧客のインサイトは？」をカスタマーサクセス（CS） と共に考える

既存顧客の中でもプロダクトを使って成功している顧客、成功していない顧客がいるはずです。どうすればより成功に近づけるのかをCS担当と共に考えていくことはPLO的です。

✔︎ プロダクトOpsはフィードバックを共通のリポジトリに集約し、構造化して社内にレポートする

プロダクトOpsとは、プロダクトのデータを収集し基盤をしっかり運用する役割（組織・担当）を置き、そこにフィードバックを集約し構造化する仕組みで、北米で一般的になりつつあります。

【ひっくり返すと……】組織は縦割りである

✔︎ マーケティング：派手なキャンペーンを打ってリードが獲得できればOK

✔︎ セールス & CS：担当顧客が成功すればOK。そのための機能な優先的に実装されればOK

✔︎ 顧客からのフィードバックは各組織に分散し、知ることが難しい

✔︎ プロダクトチームやエンジニアこそが社内の権威である

PLOはあくまでProduct-ledであり、PM-ledでもありませんし、Product Team-ledでもありません。あくまでもプロダクトが中心であるべきです。

5. プロダクトこそが顧客体験である

✔︎ プロダクトの魅力を感じ、どんどん広めてくれる 「アドボケイト」をどう増やすかを考える

✔︎ プロダクトの価値を少しでも早く感じられるオンボーディング機能を、 データを用いて設計する。パーソナライズされたオンボーディングを実装する

✔︎ 迷わないシンプルな機能とUIを提供する。 困ったことがあってもユーザーが自身で解決できるガイドを用意する。

【ひっくり返すと……】プロダクトと顧客体験は別物である

✔︎ プロダクトには、派手なキャンペーンや営業資料があれば売れる。 デモも人手で作れば良い

✔︎ プロダクトのオンボーディングは、カスタマーサクセスチームが Webinar をやれば良い

✔︎ プロダクトで困ったことがあれば、サポートに電話で連絡してもらえば良い

北米の調査だとサポートのために電話をしたくない人がマジョリティというデータもあるようです。

プロダクト主導型組織（PLO）まとめ

みなさんの組織はいかがでしょうか？プロダクト主導型組織（PLO）はさまざまな応用の仕方があり、極端なものではないと原作者のTodd Olson氏も語っています。Product-led or Sales-ledの二元論や、All or Nothing で考えないことが大切です。

プロダクト・レッド・グロース（PLG）とは

PLOはPLGの流れを組んで、より拡張した考え方で、2016年にOpenViewが提唱しました。「プロダクトそのものを顧客獲得、コンバージョン拡大における主要な原動力とするエンドユーザー重視のグロースモデル」と言われています。セールスレッド（セールス主導型グロース）の考え方と対比されることが多いですね。

PLGの例としては、このあたりが有名です。皆さんも使われているのではないでしょうか？

Slack / Calendly / Dropbox / Zoom / Canva / Notion / Miro 

会社にセールス担当者が来て「こういうツールがありまして」と提案されたのではなく「何やらZoomというすごく品質の高いビデオ会議ツールがあるらしいぞ」ということで使ってみたり、Zoomのミーティングに招待されて体験した方が多いと思います。そして、こちらからプロダクト側に連絡をして、Web上から契約をしたのではないでしょうか？このように、プロダクトそのものが顧客を獲得してコンバージョンまで持っていき、さらにユーザーを拡大していくモデル（考え方）がPLGです。

セールスや、セールスレッドが悪ではない

ここで、ちょっと誤解しないでいただきたいのが、決してセールスや Sales-led が悪ではないということです。また Product-led であっても、セールスやマーケティングが不要になる訳ではありません。Product-led or Sales-ledの二元論や、All or Nothing で考えないことが大切です。実はPLGでは「こういうときにはSales-ledが有効だよね」というものも述べられていたりするので、ぜひ興味があればご覧ください。

プロダクト・レッド・グロース（PLG）の3つの柱

1.  エンドユーザーのためのデザイン

BtoBの文脈を想像してほしいのですが、IT部門の人たちが喜ぶソフトウェアとかプロダクトを作るのではなく、その先にいる本当にそのプロダクトを使う人のためにデザインがされているかどうかというところです。

2. 価値が得られる前に価値をプロダクト側から提供する

PLGでは、ユーザーがアハモーメントに到達するまでの時間（Time to Value）を短くすることが大切です。アハモーメントとは「このプロダクトは素晴らしいものだ」「私にとってメリットがあり、価値を提供してくれるものだ」と感じる瞬間を指します。

3. Go to Marketの意図をもってプロダクト内に投資する

プロダクト自身がプロダクトを売るような仕組みをしっかりとプロダクト内に作り込んでいくことです。

• プロダクトデータへの投資（プロダクト内行動データ収集 / 計測 / 分析）
• プロダクト自らグロースする機能
• ユーザージャーニー改善のための実験

プロダクト・レッド・グロース（PLG）5つのHOW

1. 確実にエンドユーザーのペインを解消するプロダクト

一言で片付けられないぐらい奥が深いものだと思いますが、まずはここがポイントです。

2. フリーミアムモデル  / フリートライアルモデル

顧客流入を一気に広げる施策です。フリーミアムモデルは、無料で使い続けられるが、特定の機能のロックを解除したければ、有料プランにしましょうとかですね。フリートライアルは、特定期間はフル機能が使え、期間終了後は契約してくださいねというモデルですね。

3. プロダクト内オンボーディング機能

プロダクト内で「これは私にとって役に立ちそうだ」と思ってもらえるまでのプロセスをアシストすることです。確実かつ早期に価値を実感してもらうことが重要です。

4. セルフサービスを助けるガイド

「これどう使うんだろう？」「使い方がわからない」などの、ユーザーにとって面倒な「サポートしてもらう」作業を減らすことです。電話やメールではなく、自分でヘルプページやチャットを通じて解決できる機能を組み込むことも多いですね。

5. ユーザーによるリファラル / レビューの促進

ユーザーからのリファラルやレビューを促進するようなポップアップを出すようなプロダクトも多いと思います。

上記の継続的な改善のために「データ」で会話・意思決定をする

繰り返しですが、上記を実装・改善する際には、データを使いましょう。

• どういうときにオンボーディングすればいいのか
• ユーザー属性ごとに出し分けるべきなのか
• どこで離脱してるからどこでヒントを持たないといけないのか

このようなことは、データを使って話すことが大切です。

登壇者紹介

動画視聴はこちら