拡販戦略において、今や馴染みのある「Product-Led-Growth（PLG）」というキーワード。従来はSMBを中心とした限定的な戦略だと思われてきましたが、この言葉の意味を拡張させている事例が生まれています。
Product-Ledな思考を「組織作り」に取り入れ、急成長を続けているSaaS企業がPendo.ioです。プロダクト体験を向上するSaaS「Pendo」を展開する彼らは、開発だけでなく、セールス、マーケティング、カスタマーサクセスにおいても、その考え方を推進しています。
よりお客さま目線で、データを基に判断し、実行に移していく「プロダクト・レッド・オーガニゼーション（プロダクト主導型組織）」という手法。それは、まさにPLG戦略の進化系と言っていいでしょう。
そこで今回は、「プロダクト主導型組織」をテーマに、PendoのCEO / FounderであるTodd Olsonさんと、イベントマーケティングの効果を高める「EventHub」を提供する、株式会社EventHub代表取締役CEOの山本理恵さんとのトークセッションをお届けします。
【プロフィール】
Pendo.io
CEO / Founder
Todd Olson
All in Oneのプロダクト・エクスペリエンス・プラットフォームであるPendoの共同創業者兼CEO。3度の起業経験を持ち、2013年10月、Red Hat、Cisco、そしてGoogleのプロダクトリーダーや技術者たちとチームを組み、Pendoを立ち上げる。 VCから3億5,600万ドルを調達してから、2,500社以上の顧客を獲得し、現在では世界8カ所のオフィスに750人の従業員が在籍。ForbesのCloud 100とInc. Best Workplacesに過去5年間ランクイン。
株式会社EventHub
代表取締役CEO
山本 理恵
米国ロードアイランド州ブラウン大学経済学部・国際関係学部卒業後、マッキンゼー・アンド・カンパニー サンフランシスコ支社に入社し、金融・医療・パブリックセクターのプロジェクトに従事。在籍中に認定特定非営利活動法人Teach For Japanへ出向する。 2016年に株式会社EventHubを設立し、2019年からイベントマーケティングプラットフォームEventHubを提供開始。
セルフサービス型で買わない顧客でも、概念や原則は通じる
山本：まずは、ToddさんとPendoについて、ご紹介いただけますか。
Todd：もちろんです。Pendoの共同創業者であり、CEOを務めているTodd Olsonです。「Pendo」は、ソフトウェアアプリケーションの体験を向上させるためのSaaSです。創業して約10年で、3億5,600万ドルほど調達。3,000社以上の顧客がいて、世界に8つのオフィスを展開しており、東京にも10人ほどのチームがいます。
山本：今日のテーマにも触れますが、「Product-Led」を取り入れた組織作りに関する著書もありますね。
Todd：2020年に『The Product-Led Organization』を刊行しました。まさに、私たちの日々の実践の記録から生まれた本で、日本語版も出ています（『プロダクト・レッド・オーガニゼーション 顧客と組織と成長をつなぐプロダクト主導型の構築』）。
山本：プロダクト・レッド・オーガニゼーション（プロダクト主導型組織）の構築について、今日は色々と聞かせてください。早速ですが「プロダクト主導型組織」とは、具体的にどういった組織を指すのでしょう？
Todd：Product-Led Growth（PLG）は、みなさん聞いたことがあると思います。私たちはこの単語を、セルフサービス、ロータッチなGTMにとって重要なバイラルモデルの一種として使っています。
代表的な企業はDropbox、Zoom、Slackですね。BtoBだけでなく、BtoC企業でも事例は豊富です。業界全体で注目され、重要性を増しています。
ただ、私たちは「プロダクト主導型組織」を、それよりも拡張的なものとして定義しています。なぜなら、大企業ほどセルフサービス型で導入を進めることが難しいからです。
たとえば、私はこの数日間、日本企業を訪問していました。その理由は大きな銀行や政府機関はオンラインでは購入しないからです。まぁ、多くの企業がそうですけれどね。
とはいえ、セルフサービス型で買わない顧客がいても、概念や原則が使えないわけではありません。
山本さんが私の顧客だとしましょう。実際にこれまで会ったこともあって、すでに関係が築けている。もし、EventHub社員の誰かが私たちのプロダクトユーザーなら、新プロダクト、新機能、拡張プロダクトなどを宣伝する素晴らしい機会ですよね。収益の拡大、共同販売、アップセル、NRRの促進も叶えるチャンスです。
もう一つの例は、伝統的な企業の多くはセルフサービス型ではじめるということです。誰も顧客サポートなんて電話したくないんです。使い方がわからずにイライラしているのに、30分も電話を待てる人なんて、いないでしょう？
アプリ内でサポートを受けたり、自力で解決できるサービスがあれば、企業のコスト削減にも繋がる。Product-Ledの心地よい体験になります。これらは、Product-Ledの概念が、セルフサービス型のフリーミアムから、有料版へ切り替え、さらに拡張できたという簡単な例に過ぎません。
まとめると、プロダクト主導型組織とは、顧客体験全体から「自動化できる方法」を探すことなのです。
プロダクトやデジタル主導のワークフローに切り替える
山本：プロダクト主導型組織を推進するためには、どういったアプローチやカルチャーが必要ですか？
Todd：まずは、人間主導のワークフローから、プロダクトやデジタル主導のワークフローへ。そういう思考の進化からはじまりますね。
例えば、ワークフローで見ると価値が相対的に低いとされる「大量で価値の低いタスク」から手を付けてみるのも良いでしょう。
具体的な例をお伝えしましょう。
私は技術が大好きな元開発者なんですが、ある時、使ってみたSaaSアプリが面白くて、ブラウザコンソールでコードを開いてみました。すると、HTMLコードの一番上に、「このコードを見たあなた、私たちの会社で働くのにぴったりかも！ □ □.comから応募してね」とメッセージがあったんです。クールでしょう？
まず私は、そのプロダクトのユーザーで、会社のことも知っている。さらにコードを見るほど気に入ったのですから、（そういった相手にアプローチする方法としては）とても賢明なコンセプトです。私はCEOなので応募はできないけれど（笑）。
この例では、採用担当者はエンジニアやプロダクトのメンバーと動いていたわけです。多くの部門間協力も必要です。つまり、このSaaS企業はプロダクトを用いて採用のソーシングを自動化したといえますね。採用担当者に対して望む仕事は候補者を探して、ファネルの第一層を作るだけではダメですよね。面接やリファレンスチェックなど、適性確認のプロセスこそ深めて欲しいわけです。
人間のワークフローを、いかにプロダクトへ組み込み、デジタル化するのか。そうして、あらゆる仕事の進化を考える。それがわかる、とても良い例です。
部門ごとに行動してしまう企業は多いものです。プロダクトチームも、営業チームも、それぞれに専念していて、部門間のコミュニケーションがなかったり……そういう状態に陥ってしまいがちなんだと思います。そういう状態を、プロダクトを全体的な体験の中心に置くことで変えていけます。
最初は「Product-Ledリーダー」を据えることから
山本：では、プロダクト主導型組織を実現するための初手とは何でしょうか。組織の構造を考える、カルチャー作り、内部コミュニケーションの刷新……何から進めますか？
Todd：最初は「Product-Ledリーダー」を据えること。実現したい重要なことがあっても、DRI（最終責任者）がいないと失敗する、と強く信じています。
ですから、グロースチームとグロースリーダーを置くんです。PendoのグロースリーダーはCPOの直下で、グロース活動の責任者です。彼女のチームはクロスファンクショナル型で、時にはプロダクトマネージャーなどの個人をマネジメントしたり、プロダクトマーケティングやセールス、カスタマーサクセスと間接的に関わってもらったりします。
彼女は、そのグループを1つのチームとして運営しています。同じ会議に参加し、同じTシャツを着て、同じイベントに参加しますが、各チームメンバーの実際のレポートラインは、HRシステムの組織図上にある各ファンクションのリーダーです。要は、組織図上のレポートラインと別に、方向性やKPIなどの定量的な目標は、グロースチームと決めているのです。
ただ、セールスについて掘り下げると、PLGを踏まえたやり方は複雑なんですよ。セールスには「チャネル競合」という問題がありますよね。PLGの流れで顧客になったアカウントに対して、セールスが担当した場合に、売上は誰の功績になるのでしょう？セールスチームとグロースチームが、時には険悪になってしまうかも…。
そこでお勧めするのは、最初にすべての摩擦を解消すること。つまり、報酬を両方に払うのです。組織の変革を推進するときには、報酬の活用は一般的です。とにかく、組織の変革を推進する際は、摩擦をできる限り解消することが大事です。
IDR＞PQL＞MQLとリードを階層化する
山本：Toddさんの本では「Product Qualified Leads（PQL）」について言及がありましたね。あるいは「Marketing Qualified Leads（MQL）」のようにインバウンドで入ってくるリードもあります。これらのリードに対して、フリートライアルの体験者は、マーケティングとセールスで異なる扱いにしますか?
Todd：リードには階層があって、私たちは「Inbound Demo Request（IDR）」と呼んでいます。たとえば、誰かがあなたのウェブサイトに来て、「デモをして欲しい」と言ってきた。これはとても良いリードなので迅速にセールスへ繋げます。
MQLは、当社サイトの訪問者や、ウェビナーやイベントの参加者など、意欲を示してくれた人です。これらのリードはSDRかセールスに渡して、さらに働きかけようとします。
そしてPQLは、フリートライアルやフリーミアムユーザーの中でも、プロダクトの重要な機能を体験したリードで、他の機能を使った人よりも、有力なリードになることが多い。もし、そのリードがすべてのエンドユーザーへメッセージを送っているなら購入意欲は高いはず。これらの見込みの高いリードは積極的にセールスへ渡します。
他には、しきい値に基づく例もあります。例えば、PendoはMAU数に基づいて課金しています。フリートライアルでは、アカウントごとのMAU上限を500人に設定しているのですが、それが450人に達したら、私たちはユーザーに連絡しはじめます。これはPQLにおける「しきい値へ近づいたときに動く」型の一つです。
「MAUが500に到達すると、プロダクトが使えなくなるわけではないけれど、使える機能が制限されてしまうよ」とユーザーに伝えるんです。データによると、ウェビナー参加や資料請求など慣習的なMQLより、PQLは購入意欲が遥かに高い。
デモを要請してくるリードであるIDRが、もっとも金銭的価値が高いとすると、PQLが2番目で、MQLとその他が続きます。私たちはこのようにリードを階層化しています。
山本：もし、フリーミアムやフリートライアルを提供していない場合、何がPQLにあたりますか？
Todd：フリーミアムやフリートライアルを導入していない場合でも、面白い選択肢はあります。実際、プロダクトのオンラインデモを行なうSaaS企業はたくさんありますよね。私たちも実際に「Reprise」というサービスを使ってオンラインデモを行っています。
オンラインデモのサービスを使ってプロダクト全体のスナップショットを撮り、提供することで、顧客はあなたのプロダクトを体験できるんです。使うのは、私たちが「ダミーデータ」と呼ぶサンプルデータですが、それでも本物みたいに体験できるんですよ。その顧客体験は、PQLのトリガーになります。
私たちはすべてのリードを点数化していますが、オンラインデモを通して創出したリードはフリーミアム体験者より点数は低いです。フリーミアムに一歩及ばないPQLの良い例ですね。誰でも買う前には試してみたいものなんですよ。車だって試乗しますし。
こういったことは2023年の今ではもう当たり前です。試させてくれなければ買わないかもしれません。きっと試せる場所へ行くんです。試用は、購入体験として重要です。
いかに自分のプロダクトの中に、居続けてもらえるか
山本：Toddさんはデータについてよく言及されますね。
Todd：Pendoはあらゆるものを厳密に測定しています。すべてを測定してインサイトを取得し、ユーザーがどのように利用しているか、など。
山本：Pendoの戦術を少し共有していただけますか？正しく測定するための戦術のヒントを、ぜひ。
Todd：シンプルに言うと、何を作るにしても『有益なビジネス成果となる目標』が必要です。
その目標は収益の場合もありますが、そうでない方が多いです。特に当社のビジネスモデルであるSaaSでは簡単に測定可能なアドオンのプロダクトもあれば、大規模プロダクトのいち機能の場合もありますよね。要点は「他の機能よりいかに価値があるか」です。それを知るのに時間をかけすぎてはいけません。
以前、プロダクトマネージャーが「Aという機能を使っている10人のユーザーがいて、収益を得ている」と考え、そこからビジネスケースを作ったことがありました。でも、その10人はプロダクトのBの機能も使っているんです。これは望ましくない考え方です。そこで、機能のゴールについて考えます。
実践的な例を紹介しましょう。ほとんどのSaaSプロダクトには、ExcelやCSVをダウンロードできるエクスポート機能があって、多くの顧客がその機能を使っています。これがなぜなのかを考えてみたんです。
私たちのプラットフォームだけでは、顧客が欲しいデータは得られず、CSVから手動計算していたことがわかったんです。これは良くない体験ですよ。私たちに10万ドルも払ってプロダクトを買ったのに、自分たちの3つの質問に答えるためだけに、さらに計算しないといけないなんて。
そこでプロダクトマネージャーは「CSVをダウンロードする顧客数を減らす」という目標を立てました。とても具体的ですし、チャートにすれば変化も目に見えます。機能を公開するごとに段々と数値が下がって、嬉しかったですね。最近ではダウンロードする顧客もわずかです。
これは、プロダクトマネージャーが特定の指標を取り上げ、それが自分の機能分野における北極星となり、結果の指標となった例です。私たちは顧客にはプロダクト内にいて欲しいのです。長く頻繁にPendoを使ってもらえますし、その他のメリットもあります。何を構築するにしても、目標がありきで、みんなでその責任を負う必要があります。
企業の戦略から、ロードマップの推進を考える
山本：測定時に、様々な機能にわたる一連のデータセットがある場合、どの機能を、いつ構築するかについて、ロードマップや意思決定はどのように考えますか？
Todd：すべては企業の戦略からです。あなたが、何を改善しようとしているのか。
私がアドバイザーを務める某企業では「顧客の定着率」が低く悩んでいました。主な目標はチャーン防止です。そこでプロダクトマネージャーに、「チャーンを減らすロードマップは？」と聞きます。すると彼らは調査をはじめ、離脱してしまった顧客と話し、問題を理解しようとします。そこから目標数値のためのロードマップを作ります。
企業の全体的な目標から逆算し、ロードマップを推進するための方法を考えます。私は目標設定、ストラクチャー、規律を定めることはとても重要だと信じています。
Pendoの場合は、OKRからはじめました。OKRは階層的に伝播する構造になっています。創業まもない企業ほど余分な仕事を嫌い、階層的な情報伝達を怠りがちですよね。彼らはハイレベルなメトリクスは設定しても、そのOKRにアラインした目標を立てることを各チームに求めません。面倒な仕事ですが実は大事なのです。私ならそこからはじめて、優先順位を検討します。
もう一つ考えるべきは投資の種類ですね。私たちは、「開発しているものが何か」をベースに、エンジニアの支出を考えています。エンジニアの20%はプラットフォーム指向に基づいた支出として、パフォーマンスや品質、クラウドコンピューティングのコストなどに重点を置いています。売上原価やクラウドのホスティングコストを削減すると、粗利益率が向上します。
そこで、粗利益向上に重点を置くチームも設けることもあります。それがR&D費全体の10%に相当させることもあるでしょう。あとは「顧客を幸せにするチーム」を設けることもあります。彼らは顧客からの要望にひたすら対応していくので、顧客の定着率が上がります。さらに、他の市場への関心や成長促進といった戦略的取り組みに集中させます。
これら全体を、協奏的な投資戦略として考え、それを取締役会や会社でも伝えています。
山本：R&D費の支出と結果をチェックするということですね。比率や焦点を変えることはありますか？
Todd：ええ、四半期ごとに比率は見直します。先程のアドバイザー企業なら、顧客の定着率向上のために「顧客を愛するチーム」を増やしていますよ。
データドリブンではなく、「データに基づいているか」
山本：とても体系的でオーガナイズされた方法だと感じます。企業戦略のほか、R&D費の割合の配分もあり、データ中心でデータドリブンな意思決定ですね。一方で、本能や直感を優先することもありますか？
Todd：いつもですね。
Todd：本能と直感には、いくつかの考え方があります。
何年も前に聞いた表現なんですが、「机上に2本の線がある。一本はデータを持つ人、もう一本はそうでない人。データを持つ人はとても速く進む」というものです。
メンバーには「何かを決めたければ、データを持ってきてください」と言っています。データがあれば、答えが得られる可能性がはるかに高くなります。あるいは、データがなくとも本能と直感で良いアイデアだから実行したいとしましょう。この時も、どうしたら検証できるのか、あるいは腹落ちするためのデータを得られる、最も安価な実験方法を考えます。
私は「データドリブン」って、好きじゃないんです。「データドリブン」だと、データが示す方向へ進むだけで、まるで私たちは機械かのように聞こえます。だから私は、「データに基づいている（data-informed）」という表現を好みますね。データを知っていたとしても、決断するのは私たち人間であることには変わりません。もっとも、AIによって、よりデータドリブンになるのかもしれませんが。
データに通じていることで、人間はより賢明に決断できるはず。そして事後にも、データを通じて、決定の有効性も測れるのです。
組織内で成長しつつある「プロダクトオペレーション」の役割
山本：プロダクトオペレーション（Product Ops）についても教えていただけますか？必ずしも多くの企業が備える機能ではないと思いますが、Pendoにおいては、そのチームの主要な目標は何ですか。そして、チームが機能するために、CEOとして何をしていますか？
Todd：どれほどの規模の会社がプロダクトオペレーションを必要とすべきかはわかりませんが、組織内で成長しつつある新たな役割ですね。とはいえ、他のオペレーション機能と考え方は同じですよ。セールスオペレーションも、CSオペレーションも、エンジニアリングオペレーションもね。プロダクトも独自のオペレーション機能を持ちはじめたわけです。
何をしているチームなのかと言うと、プロダクトマネージャーの責任を取り除き、「本来やってほしいこと」を進める時間を作ります。プロダクト、エンジニアリング、マーケティングのリエゾン（連絡役）だと考えてみてください。
多くの企業で、付随的な作業ばかりで顧客に十分な時間を費やせないとか、エンジニアリングチームと話し合えないという話を聞きます。その原因になっている、ツールスタックの管理、分析のセットアップ、顧客向けのベータプログラムの管理などは、まさにプロダクトオペレーションが担えます。
ローンチ時のコーディネートも務められますし、分析プログラムをまとめることもできます。彼らが管理するMPSプログラムなど、すべての定性的なフィードバックもまとめます。顧客からのフィードバックや機能リクエストの管理システムも運用しますね。プロダクトマネージャーに代わって管理できるものがたくさんあるんですよね。
Pendoには、フィードバックリクエストを受け付ける仕組みがあります。顧客が「Pendoでやって欲しいこと」を書き込んだとしたら、プロダクトマネージャーは、それらのリクエスト項目をいかに優先順位付けするのでしょうか？
そこで、プロダクトオペレーションが、その仕事を担うんです。特定分野で一定数のリクエストがある場合、プロダクトチームへ「AとBとCの機能について調査すべきかも」と伝えに行きます。ロードマップを統合し、中央集権的に機能するわけです。プロダクト横断的な活動を可能にする役割ですね。
こうして、各プロダクトマネージャーは独自のロードマップを持ちながら、プロダクトオペレーションは企業レベルのロードマップをまとめて管理します。プロダクトの仕事はそのままでも十分に難しいです。他に何かを付け足すと本来やるべき仕事に支障をきたすと思います。
山本：一般化は難しいとは思いますが、起業家や企業にプロダクトオペレーションへの投資を勧めるなら、いつ頃ですか？
Todd：プロダクトマネージメントチームが、5～6名程になったときに考え始めると良いと思います。
山本：ありがとうございました。最後に、日本の起業家やプロダクトマネージャーたちに、ぜひ一言ください。
Todd：大胆になろう。検証しよう。失敗を恐れないで。
顧客の声に耳を傾けるだけ、現状を維持するだけでは限界への挑戦も、イノベーションも起こせません。失敗を恐れず、現状から抜け出す方法を見つけるのです。
※この記事は2023年11月9日に開催した「ALL STAR SAAS CONFERENCE 2023」のセッションから抜粋・再構成しています。
