2024年3月21日（木）22日（金）にニューヨークでRevenue Operations Summitが開催されました。日本を含むアジアからの参加者は弊社のみ、スウェーデンからの参加者もいましたがほとんどは米国企業のRevOps部門のリーダー、レベニューイネーブルメントの方々がメインでした。

このブログでは、何回かにわけてレベニューオペレーションサミットで取り上げられていたテーマをピックアップして紹介する予定です。第1回の本ブログではSweepから2名が登壇した「プロダクトマネージャのようにRevOpsを実行する」について紹介します。切り口としても面白いですが、RevOpsのビジョンやアラインメントを表現しているわかりやすいセッションだったのではないでしょうか。

プロダクトマネージャのようにRevOpsを実行する

同じ視点で議論できるようにする、火消しを行う日々から脱却する、部門横断的なコミュニケーションを増やす、RevOpsをスケールさせていくにはどうすればよいのか。どうすればインパクトを生み出すことができるのか。どうすればより良い判断ができるのか。どうすればリードできるのか。

これらについて考える中でRevOpsにもプロダクトマネージャのベストプラクティスが当てはまるのではないかと考えたということで、このセッションではSweepのプロダクト責任者であるRonenとRevOpsのAvivがプロダクトマネジメントのメソッドをなぞりながら掛け合い形式で実施されていました。

プロダクトマネジメントは2000年頃から誕生していることもあり、RevOpsよりもはるかに歴史のある領域です。そこで培われてきたベストプラクティスは案外RevOpsにもあてはまるのではということで、Ronenから4つのポイントを紹介されています。

#1　役割の定義

#2　ノーススターメトリック（NSM）

#3　問題のスペース

#4　Minimum Viable Product（MVP）

#1役割の定義

まずプロダクトマネージャの役割は、「プロダクトを作り、その価値をユーザーに届けること、ユーザーからバリューバックされる価値をもとにまたプロダクトの価値に還元し顧客に届けるという循環である」とRonenは言います。バリューパックとは、売上やフィードバックやリファレンスなど様々なユーザーから返ってくるバリューを元にまたプロダクトに活かしていくという循環を創出するのがプロダクトマネージャの役割だということです。

一方、RevOpsの役割はなんでしょうか。GoogleでRevOpsを画像検索すると様々な図が出てきます。プロダクトマネージャの役割に当てはめて考えようとした時、RevOpsにとってのカスタマーとは誰なのでしょう。会場から「セールス！」という声があがったのが印象的でした。サイロ化した組織では、特定のレベニュー組織の一部を対象という捉え方があります。

AvivからはRevOpsのカスタマー＝レベニュー組織全体であると紹介され、RevOpsはプロセス、データ、テクノロジーを統合し、カスタマーであるレベニュー組織全体に価値を届け、レベニュー組織の活動により生まれるレベニューを捉えて更にレベニュー組織に価値提供できるようにプロセス、データ、テクノロジーを洗練させていくことが役割だと定義されていました。

‍#2ノーススターメトリック（NSM）

ノーススターメトリックとは、プロダクトの成長にとって重要な1つの指標のことです。ノーススターは北極星の意味で、向かうべき方向を指し示している指標であり、その組織でプロダクトの成功を計る尺度になるものです。

他の企業の例では下記などがあります。

• Facebook：Daily Active Users(DAU)
• Whatsapp：Sent messages
• Airbnb：Night booked
• Youtube：Minutes watched
• eBay：Gross Merchandise Volume(GMV)

 ノーススターメトリックの設定においては下記がポイントです。

• 総合的に価値と捉えられるもの
• 完璧さよりもシンプルであることを重視する
• わかりやすく、覚えやすいもので設定する

ではRevOpsのノーススターメトリックはなんでしょうか。これは会場にいる全員がブレることなく「レベニュー」と言っていました。ただし、受注目標を追いかけて日々の業務を実施しているわけではない中でどう考えていけばいいのか。分解して考えていきながら、目的はレベニュー向上であるということからぶらさないようにしなければならないということが強く語られていました。

レベニュー向上の要素を分解していくと上の画像のように、新規ビジネスか既存ビジネスか、新規ビジネスを増やすにおいては、商談数を増やすのか、受注率を向上するのか、商談単価を引き上げるのか、商談を増やすにあたっては、MQL/SQLを増やす、デモ問い合わせの数を増やすなどがあげられます。MQLを分解すると、リード獲得数を増やすということになっていくでしょう。分解すればするほど、日常業務に近い頻度高く取り組んでいるものになっていきます。そこで陥ってほしくないのは、ノーススターメトリックがレベニューであるということを忘れてしまうことです。

BtoBやBtoC、Bでも事業内容やフェーズによってKPIは変わるのは当然ですが、共通ゴールであるレベニューを意識することを忘れないことがよいRevOpsたる最低条件です。

#3問題のスペース

こちらは典型的なプロダクトのサイクルのテンプレートを表しています。ただし、実際の時間の使い方はこの通りにはなっていないのではないでしょうか。だいたいの場合、プロブレム（問題の特定）に使う時間はもっと短いことが多いです。大体の場合、下記の図の左ような状態であることが多いでしょうし、もっとひどいケースでは右のような状態であることもあります。

例えば、「社長が言ったからやる」という抗えないトップからの突然のアイデアが発生したときほど、右のように問題の特定に関するパートはゼロになってしまいがちでしょう。

解決策は、問題に対しての理解レベルと同じレベルにしかなりえません。理想的には40％を問題の特定に、残り20％ずつを3つのステップに配分できるとよいとRonenは言います。ただし、問題の特定はおざなりにされがちです。なぜならば、問題の特定は非常に難しく、お客様から語られる「問題」もお客様がすでに「解決策」を想像したうえで語られている状態の「真の問題」ではないものであることも多いです。そして、デザインや企画を考えるなど解決策のワークの方がクリエイティブに思えてすぐにそちらに移行してしまいがちです。長い時間をかけて問題と対峙することは、精神的に疲弊し深く考えられなくなっていることもあるかもしれません。よって、つい問題をスキップしたくなってしまいます。

 プロダクトチームに対していつもRonenが言っていることは大きく2つで、①ジムに通うように習慣レベルでユーザーから学ぶ。コミュニティに顔を出すこと含めユーザーと会う習慣を予定に組み込んでしまうということ。②ユーザーと接点のある部門との対話時間を作る。プロダクト部門の人は自分がユーザーのことを知っていると思い込みがちですが、営業部門やサポート部門はそれぞれプロダクト部門が知らないユーザーの側面を知っていることもあるため意図的に他の部門との時間も同時に確保していくべきだといいます。

 では、RevOpsの場合は、まずプロダクトを何と定義するのが適切でしょうか。Avivは仮に「プロセス」をプロダクトと捉えて考えてみようと言います。Aviv自身の業務の主たる領域がRevOpsの中でもプロセスマネジメントを担っているとのことでした。過去にAvivはすばらしくきれいなプロセスをデザインし、社内に展開したことがあったと言います。でも誰も見ないし使わなかったとのことです。テクノロジーを導入した際にもSlack連携やダッシュボード管理などすべてデザインして整備しても誰も意図したように動いてもらえなかったこともあったとのことです。

そこからAvivは真の問題を理解するためにも、ユーザーを知るということがプロダクト同様に重要だと考え、言葉の使い方や顧客であるレベニュー組織の各部門との関わり方をよりディープにしていきました。Salesforceをよく理解していないに専門用語を言ってもなんのことかわからないし、レベニュー組織の部門長やメンバーと統一言語で会話をするということを強く意識しているということです。

営業に関して新しい取組みを導入してガイダンスを実施しても、「なぜかうまくいかないからできない」と言われてしまうこともあります。ただし、RevOpsとしては幾度もテストも実施しており、再度確認してもなにがうまくいかないのかがよくわからないということもあると言います。とにかく何か新しいことを開始する際には営業側の業務をしっかり理解するために傍に張り付いて、どういうときに何をどう処理しているのかを把握していくことを心がけているということでした。

‍#4MVP

MVPとは、ミニマムバイアブルプロダクト（Minimum Viable Product）の略語で、顧客に価値を提供できる状態の最小限のプロダクトのことをいいます。完璧な完成形を目指すのではなく、顧客が抱えている課題を解決することができる最小限の状態で提供をし、フィードバックをもらいながら改善しアップデートしていきます。

長年プロダクト責任者を務めてきたRonenでも「専門家がいかに機能の価値を見積もるのが下手かを目の当たりにすると身が引き締まる思いがすると言います。新製品は顧客との対話の始まりであり、最小限のプロダクトではなく、必ず「価値提供できている状態の」最小限のプロダクトだということを忘れてはなりません。

この図のように、例えば「ある地点からある地点へ移動をする」という価値を求めている人に上の図のようなタイヤを1つ与えること自体は求められている価値を提供できていないのでMVPではありません。提供とフィードバックによる反復活動によってプロダクトをより価値あるものへとアップデートをしていきます。

RevOpsにおけるMVPとはなんでしょうか。ここでは問題のスペースの話同様に、レベニュー組織で起きていることを正しく理解し下記の図のようにMVPのプロセスを反復していくことが必要です。

ソリューションの定義→フィードバックを求める→素早く反復する

新しいプロセス、新しいセールスプレイ/メソドロジー、新しいテクノロジーの導入は、段階的に進めていくことができるものもあるとAvivは言います。

さいごに

プロダクトマネジメントのベストプラクティスを踏まえてRevOpsの役割の定義、ノーススターメトリック、問題のスペース、MVPについてのSweepのセッションを紹介しました。ともするとRevOpsは、数値などのデータ、理論やプロセスとしての正しさにフォーカスしてしまい言語の不一致でレベニュー組織のフィールド部門から距離を取られてしまうこともあるかもしれません。レベニュー貢献する組織としてのRevOpsが果たすべき役割やアプローチについて考えるきっかけになった参加者も多かったように思います。

レベニュセッションの中では全然製品紹介がありませんでしたが、SweepはSalesforceのビジュアルワークスペースで、スマートオートメーション、クロスチームコラボレーション、リアルタイムインサイト、およびパイプラインソリューションのスイートを提供することで、レベニュー向上に貢献するプロダクトです。主にRevOpsチーム向けに設計されており、CRM運用の管理をより簡単かつ迅速に行うことができます。

また次回のブログでも、ニューヨークで開催されたRevOpsサミットの他のセッションの様子などを紹介します。