ToB製品運用における3つの問題点！

以前ToB運用をしていた時は、ToB商品をToC商品として扱い、回り道が多かったため、商品が軌道に乗らず、利益が出ませんでした。これもToB運用で多くのトラブルに遭遇する原因となりました。

最近の反省と新しいビジネス モデルの開発を経て、ToB オペレーションは、いくつかのスキルを習得するだけでは十分ではないことに気づきました。

過去2年間の仕事で、私はToB製品運用で多くの落とし穴に陥りましたが、それは単に思考、認知、経験の問題に起因するものです。これら3つの問題は私を大いに泣かせました。また、これら3つの問題が、ToB運用への切り替えの恥ずかしい状況から抜け出すのに役立つことを願っています。

2018年に縁あって国内の優秀なAI企業に入社し、SaaSプロダクトの運用業務に携わることになりました。当初はSaaSプロダクトやToBプロダクトに対する明確な概念がなく、教育企業のCエンド運用からエンタープライズサービスのBエンド運用に至るまで、私の中ではまだまだユーザー数を中心とした指標が残っていました。

1年以上にわたって私が行った作業のほとんどは、最終結果には効果がありませんでした。その後、チーム内での自分の居場所が見つからず、社内異動でポジションを変えざるを得なくなったのですが、さらに恥ずかしい出来事に遭遇しました。

考えてみれば、私の考え方が未熟なせいで、もし職種や仕事を変えたとしても、今のジレンマや他の問題に直面することになるだろう。まずそれを理解して初めて、自分の才能をより発揮できるのだ。

1. 思考の深さの欠如

初期の SaaS 製品はユーザーに適していなかったため、私たちのチームは製品を改良して、C エンド ユーザーにより適したものにしました。

PFM段階を経て、製品を大々的に宣伝し、顧客を獲得できると確信したため、チームもユーザー数をノーススター指標に設定しました。残念なことに、この目標はユーザー数にのみ焦点を当てており、ユーザーがもたらす価値や、ユーザーが会社に与える最大の貢献には焦点を当てていません。

これは製品のビジネス ロジックにも関係しています。なぜなら、商品はユーザーに直接販売されるのではなく、トラフィックから広告までの収益化パスを通じて販売されるからです。このパスは非常に合理的に思えますが、非常に不合理でもあります。

インターネットがプライベートドメイントラフィックの段階まで発展したため、各PCやMエンドに保持されるトラフィックの価値は非常に低く、広告主への価値貢献も非常に低く、リンク全体がうまく流れることができません。

当初はビジネスロジックのレベルまで理解が進んでおらず、KPI の段階にとどまっていました。

会社から与えられた仕事をさまざまな手段でやり遂げれば、自分は優秀な人間になり、チームは優秀なチームになると信じています。また、KPI 重視なので、KPI の達成にのみ焦点を当て、KPI がチームの最終目標に貢献できる価値を忘れてしまいます。

KPI は超過しましたが、それでもチームにとってはリソースの無駄であり、入力と出力の比率は比例していませんでした。

個人的な利益と損失に焦点を当てた結果、チーム内での発言力が低下し、徐々に疎外されていきました。もちろん、疎外され、職場で生き残るための愚かなスキルを持っている私が、中規模の会社で生き残ることができるのは奇跡です。

私の感情的知性の論理によれば、私は小さな会社で働くことにしか向いていないのかもしれないが、今のところはそれが良いのかもしれない。

2. 前線に行くことを拒否する

ToB オペレーションの本質は、ユーザーに製品を販売し、実感できない貴重な時間を無駄にするのではなく、実際のお金で支払ってもらうこと、またはユーザーに正当な価値を提供してもらい、KPI の達成に役立ててもらったり、ビジネスを改善するための貴重な情報を入手してもらったりすることです。

さらに、ToB の意思決定プロセスは比較的長く、リーチするユーザーの多くは意思決定能力がありません。

運用の過程では、インターネットを通じて製品ユーザーと連絡を取ることだけに頼っていました。私はこれらのユーザーをよく知っていると感じており、すべての運用計画とアクションはこれらのユーザーを中心に設計されていました。運用は正しいように見えましたが、私は到達可能な最下層のユーザーを満足させるだけで、製品を購入する意思決定者のニーズについて深く考えていませんでした。

ToB 製品の運用中は、製品ユーザーと意思決定者の間の利害と対立を考慮する必要があります。運用計画では、特定のノードを製品ユーザーに傾け、特定の運用アクションで意思決定者の意思決定を支援する必要があります。

ツールを通じて製品ユーザーに頻繁にアプローチすると、意思決定者が購入を決断できなくなります。

双方のニーズを理解したいのであれば、最前線で顧客と会い、コミュニケーション会議で二度屈辱を受けなければなりません。営業やプリセールスを通じて顧客の頭の中で処理された情報だけを持ってくるというのは不正確です。最前線に深く入り込むことによってのみ、ユーザーのニーズと両者の間の対立をより深く理解することができます。

オペレーション担当者は、常にインターネット業界では自分がハイエンドのポジションであると考えています。実際、オペレーション担当者と営業担当者の間に違いはありません。自分を過大評価しないでください。過大評価すると、ひどい失敗をします。

私は最前線に行って顧客に会うことを完全に拒否します。なぜなら、オペレーションスタッフはワークステーションに座って、製品の全体的な方向性を考え、製品の開発方向とライフサイクルを戦略的に決定するべきだと考えているからです。さらに、オペレーションスタッフは最も創造的なアイデアを持っており、ユーザーとのコミュニケーションに集中すべきではありません。

この考えのせいで、私は最前線のユーザーや製品の真の開発方向から遠ざかっていました。

入力情報が不十分な場合、トップレベルの戦略的な問題を考える必要はありません。ToB 業務は業界業務です。業界情報を十分に理解していないと、道を踏み外しやすくなります。

自身の思考の深さが不足しているため、商品に対する理解や過去の経験・判断に大きな誤りが生じやすく、これもToB業務の大きな落とし穴となります。

何かを成し遂げるために、私は部署を変えることを選択しました。最初は自分の賢明さを褒めていましたが、今では別の落とし穴に飛び込んでしまったようです。この落とし穴に飛び込んだ主な理由は、不明瞭な認識と経験の再利用に大きく関係していると私は個人的に考えています。

3. 認知の問題

認知の根本的な問題は、製品と顧客に対する理解不足ですが、この 2 つの方向性が良好な運用の基礎となります。 「基礎がしっかりしていなければ、地は揺れる」ということわざがあります。

実は、運用業務でも同様に実用的です。基本的な問題さえ理解していなければ、インターネット上に出回っている運用スキルをつなぎ合わせることしかできません。たまに良い結果を出すことはできますが、製品運用をうまく行うことはできません。

商品の認知度という点では、商品の収益化の道筋やターゲット層、商品の販売方法などを考慮していなかったため、その後の仕事において極めて消極的になってしまいました。

ToB関連の仕事をお探しの方は、大変参考になるかと思います。すでに類似プロダクトの運用に携わっている方は、目の前のユーザー数だけにとらわれず、もっと色々なことを広げていくと良いと思います。

B2Bビジネスでは、ユーザー数だけに焦点を当てるだけでは生き残ることはできません。収益化することによってのみ、存在価値を高めることができます。

転職プロセス中、人々は現在の状況から抜け出すことに熱心になり、他のチームについて明確な理解を持っていません。チームの製品はプログラマーを対象としているため、チームは開発者ベースを拡大し、開発者の間で影響力を築き、開発者に働きかけることで収益化することを決定しました。

いわゆる開発者向けの運営は依然として大きな回り道をしており、ユーザーに直接製品を販売するわけではありません。

このようなロジックは、ToC の製品運用でよく見られます。結局のところ、ToC のユーザーと購入の意思決定者は同じユーザーです。しかし、ToB の製品ロジックはそうではありません。ユーザーが製品を使いやすいと思っても、意思決定者が購入を支持しない場合があります。

たとえば、MySQL や Oracle データベースの場合、企業は、より高性能なエンタープライズ サーバー データベースを購入するよりも、さまざまなオープン ソースおよび無料コンポーネントを使用する多数のプログラマーを見つけることを好みます。

この問題は開発者の製品にも存在します。たとえ私たちの製品が開発者にとって非常に有用であったとしても、ユーザーが実際にお金を払うときには両極端の事態が起こる可能性があります。力のある企業は、関連製品を独自に開発することもあります。

彼らにとって、データは中核であり、商用製品を使用する可能性は低いです。さらに、製品の学習コストは非常に高く、ユーザーにはソリューションとプライベートデプロイメントしか提供できません。ユーザーがソリューションとプライベートデプロイメントに支払う金額は、コンポーネントチームが自主研究を通じて問題を解決するのに十分です。

あまり強力ではないチームの場合、上司はプログラマーを雇えばすべての問題が解決すると考えています。しかし、実際には商用ソフトウェアを購入したいと考えているので、十分な強力さがないということになります。

さらに、製品は完全にオープン ソースではありません。プログラマーは、実際の運用環境で使用できない製品の学習に時間を費やします。プログラマーは、完全にオープン ソースのコンポーネントに時間を費やすことを好みます。

また、ユーザーの習慣化による収益化までの道のりは非常に長く、企業側もそれをやると完全に決めているわけではない。最初は決心したとしても、それを貫くことができないかもしれない。

末端の従業員としては、合理的な提案をすることは不可能であり、上司は他の大企業の人の結論や経験、または専門のトレーニングインストラクターの考えに耳を傾ける傾向があります。誰かが何かを達成するのは難しいと言うと、上司は簡単に動揺し、末端で実行する人々はすぐに消極的になります。

したがって、ToB 製品は製品の収益モデルを考慮する必要があります。最も直接的な方法が最も効果的であり、ユーザーの習慣を育てようとしないでください。取引を迅速に完了することによってのみ、オペレーターの価値が反映されます。製品ユーザーと意思決定者の間の対立を慎重に検討し、製品に固執する必要があるかどうかを総合的に検討する必要があります。

そうでなければ、ToB オペレーターとして、トップレベルのフレームワークの変更により、製品の収益化パスが最下位に落ちてしまうため、私のような状況に陥ることになります。

その後のインタビューで、ToB企業はアリババやJD.comのポジションを含む運用担当者がもたらす売上を評価することが徐々にわかりました。彼らは収益化能力、ビジネスセンス、運用フレームワーク全体の論理的思考を評価し、製品のユーザー数を考慮することはほとんどありませんでした。

製品運用を行う際には、会社の中核指標に価値をもたらすような業務を行わなければ、すぐに排除されてしまいます。

IV. 経験の問題

Cエンド製品の操作方法とスキルに慣れている友人は、Bエンド製品での経験の再利用の問題に注意する必要があります。私もCエンドでの経験に頼ってBエンドを行いましたが、これは過去2年間の私の操作作業における最大の失敗でもありました。

特に、一部の中小企業の製品オペレーターにとって、製品を成長させる方法は比較的シンプルで、チャネル、チャネル、チャネルだけです。基本的に、データ駆動型の操作というものは存在しません。ユーザー数の増加につながる方法を見つけられれば、会社のKPIは達成されるでしょう。

Bサイドには異なるロジックがあります。Bサイドの顧客獲得コストはCサイドよりもはるかに高く、Bサイドの製品はユーザーの更新率をより重視しています。新規顧客を獲得するためのコストは非常に高いですが、更新は利益をもたらします。

そのため、製品のコア機能のユーザーによる使用状況やユーザーからのフィードバックを調べることが特に重要となり、データを活用してBサイドの製品運用を推進することが不可欠になります。

Bサイドのリードが入ってきてから顧客取引に至るまでのプロセスは長く、ユーザーから自発的に取引をしてもらうことは稀です。このプロセスにおけるコンバージョンファネルと、ファネル内でのキーとなる行動は、運用上必須のものとなっています。

しかし、ほとんどの企業では体系的なBサイド運用ツールがないため、運用担当者は手探りで作業を進めています。ユーザーの維持とコンバージョンの重要なノードは、単なる推測です。運用担当者は、おそらく、おそらく、これらの言葉を発すべきではありません。

しかし、B面の運用作業ではそれが現実の事態となってきました。

私が見てきた中小企業でも、経験した中規模企業でも、B サイドのユーザー変換は、完全に企業の個人的な主導性に依存しています。運営側が制御できるリンクは非常に少なく、運営担当者が参加して制御できるプロセスも非常に少ないです。過去の経験から、B サイドの運営は顧客獲得の責任を負っています。

今考えてみると、B面オペレーターであることはやはりとても悲しいことです。

Bサイドの運営者としては、まずは本来のAARRRモデルの理論的な応用を捨て、商品の収益化パスを考えることを優先し、次に商品の支払い能力とコンバージョンパスを考え、最後にトラフィック獲得について考えるべきだと私は思います。

さらに、オペレーションはユーザー変換パスにさらに関与する必要があり、最善の方法は便利なツールを使用するか、B サイド変換用の SOP を構築することです。

また、これらのことを仕事で理解することができた寛容さをくれた元雇用主にもとても感謝しています。今では、ToB 運用への移行プロセスで誰もが回り道を避けられるように、それらを記録して全員に共有しています。

ToB オペレーションが存在するのは当然の理由があるのですが、今はまだ誰もが混沌とした状態にあり、オペレーターは一緒に手探りで川を渡る必要があります。

また、すべての理由を会社のリーダーシップの弱さや市場環境のせいにするのも好きではありません。客観的な要素は存在し、オペレーションの価値は、さまざまな失敗の中から実行可能な道を見つけ、製品やビジネスモデルを市場に導き、企業に価値を生み出し、自己成長を達成することにあります。

残念ながら、私はそれに気づくのが遅すぎました。仕事を始めた頃は、製品エクスペリエンスの悪さと製品のユーザーグループの狭さが原因だと考えていました。自分への言い訳として見つけた解決策はすべて、最終的に自分自身を傷つけ、苦い涙を流すことになりました。

著者: 張牧

出典：作戦部長 張牧