製品運用研修（ToB製品運用の役割位置付け）

ToB製品運用の役割位置づけ

ToBプロダクトオペレーションは、その業務において、製品とビジネスを仲介する役割を果たします。製品、運用、ビジネスを理解する必要があります。中核となる競争力は、製品よりもビジネスを理解し、ビジネスよりも製品を理解することにあります。これらの機能があってこそ、製品とビジネス間の効果的なコミュニケーションとコラボレーションを確立し、顧客に優れた製品とサービスを提供することができます。

著者はBサイドプロダクトの運用経験7年。彼は、大手インターネット教育企業 3 社の CRM と効率改善ツールを担当し、3 つのバックエンドを 0 から 1 まで構築しました。

私がこの職に就いた当初は、まだ「プロダクトオペレーション」と呼ばれていませんでした。その後、製品操作に関する書籍やオンライン コースが少数ながら市場に登場しましたが、それらのほとんどは C エンド向けであり、B エンド向けはほとんどありませんでした。

解雇された日だったので、復習する時間はたっぷりありました。そこで、インタビューの準備として、長年にわたる製品オペレーションにおける私の仕事経験の一部を振り返り、残りの部分について皆さんと話し合いたいと思いました。

個人的な意見は必然的に主観的なものになります。何か問題がありましたら、コメント欄でご連絡いただき、ご訂正いただければ幸いです。

Bサイドプロダクトの運用は、SaaS指向、二国間市場の供給側指向、社内業務システム指向の3つに大別できます。

以降の議論はすべて社内ビジネス システムに焦点を当てたものになります。製品オペレーションの役割、製品機能企画、製品機能推進、オペレーションシステム構築の4つの側面について、皆様とコミュニケーションを図ってまいりたいと考えております。

本日お話ししたいのは、ToBプロダクトオペレーションが業務の中でどのような役割を果たすべきなのかということです。

自分の職務を明確に位置付けることでのみ、習得する必要があるスキル、すべきこととすべきでないこと、昇進のチャネルが何であるかがわかり、代替可能な役割になることを避けることができます。この方法でのみ、自分の仕事に価値を感じ、この仕事を好きになれるのです。始めましょう。

駆け出しのToBプロダクトオペレーターとして、忘れられない経験をさせていただきました。

晴れた月曜日の午後、私はビジネス担当者と今週のビジネスニーズと問題について真剣に話し合い始めました。議論中は笑いが絶えなかった。ビジネスを理解した私は、すぐにビジネス上の問題を理解できるようになりました。

その後、企業との商談で円満にコミュニケーションが終了しました。

ワークステーションに戻り、要件を整理し始めました。営業スタッフの熱心な視線を思い浮かべながら、キーボードの上で私の手はより速く動きました。

また晴れた午後でした。プロダクトマネージャーと私は会議室に座っていました。いつものように3分間お世辞を言った後、要件について友好的に話し合いを始めました。

激しい交渉と数回の嘆願の末、私は要求会議をなんとか終了させた。プロダクトマネージャーが立ち去る後ろ姿を見ながら、私は「内部監査が終わったら、フィードバックを忘れずにください」と付け加えることを忘れませんでした。

私はこの戦いの結果に非常に不満でした。当初の要件は 2/3 削減されました。 「これをやらないと業務に影響しないの？」「この機能はもう使えないの？」「R&Dのリソースがなくなっちゃったから、どうしようもないよ」「R&Dの人に残業させられるならやらせてあげるよ」というプロダクトスタッフの言葉に、私は抵抗するすべもありませんでした。

弱さ、無力さ、そして無力さが私の顔に表れています。

しばらくすると、ビジネス側は私の要求の推進が遅すぎると不満を言い、プロダクトマネージャーは私の要求が全体的に優先順位が低いと感じ、双方とも私に注意を払おうとしなくなりました。

私は助けを求めてリーダーのもとへ行きました。すると彼は言いました。「要求を簡単に推進できるなら、なぜあなたに頼る必要があるのですか？」

ええ、私に何をしてほしいですか？私が何の役に立つというのですか？

これは私が初めて B2B 製品運用の仕事を始めたときの悪夢のような瞬間でした。入社してから3か月も経たないうちに、リーダーシップ部門、ビジネス部門、製品部門のすべてが私に注意を払わなくなりました。その段階では、仕事に行くことは墓に行くようなものでした。

自分の価値が見えなかったので、自分自身に問いかけました。ToBプロダクト運用とはいったい何なのか？

Bサイドプロダクトマネージャーに関する参考書で曖昧な答えを見つけました。

Bエンド製品運用職の業務内容は、主に製品機能推進研修、問題解決と処理、需要収集とフィルタリング、プロジェクト効果分析、ビジネス診断と分析などです。「Bエンドを勝ち取る」

この説明は、私が当時行っていた仕事とほぼ同じです。皆さんは同じような業務をされていると思いますが、機能訓練、機能Q&A、効果分析などの業務で大きな問題に遭遇することはほとんどないと思います。本質的に、このタイプの仕事は、誰にでもできるように見えるため、あまり価値を感じさせません。

そして、私はこの立場の必要性をますます疑うようになりました。

製品マネージャーは製品要件を収集し、結果を分析できます。

ビジネスニーズの概要、機能トレーニング、またはビジネス側でパートタイムの仕事を行う人を見つけることもできます。

この仕事は、ビジネスニーズの代弁者となり、製品機能のトレーナーとなることだけでしょうか?

私はその部署に所属しているという意識も、自分の仕事に対するコントロール感も感じませんでした。

私が帰属意識を持たない理由は、製品チームの目から見れば、私はオペレーターであり、決してチームの一員ではないからです。企業側から見れば、私は未完成の製品であり、彼ら自身のものではないのです。

それで、どこに立つべきでしょうか?

私がコントロール感を持てない理由は、製品もビジネスも理解していないからです。プロダクトマネージャーは、私が提示した要件は正確ではなく、優先度が低いと常に感じています。営業スタッフは私と要件について話し合うのがいつも難しく、あらゆる側面を説明する必要があります。

では、私のポジションの中核となる競争力は何でしょうか?

しばらく考えた後、私はその質問に対するいくつかの答えを見つけました。

どちらの側につくかという問題に関しては、時々本当に自分の顔を平手打ちしたくなることがあります。私の役職はビジネスレベル以下です。私はビジネス側でプロダクトオペレーションをしているので、当然何も考えずにビジネスのために立ち上がらなければなりません。

ビジネスからのプレッシャーの一部は製品機能に伝わり、この部分は私に伝わるはずです。製品機能のプレッシャーをビジネスが解決できるよう支援するのは私の責任です。

製品の需要はその一部にすぎません。完全な形式は、製品需要の合理的なスクリーニングと要約、および製品機能の進捗状況であり、ビジネス側のプレッシャーを軽減する必要があります。

自分の過去を振り返ると、製品を支持するほど愚かではなかったものの、常に中立を保とうとしていましたが、それは極めて賢明でない選択でした。事業部の下で働く小柄な人間である私が、どうして中立的であるなどと思えるでしょうか。

企業の支援があって初めて需要を促進できるのです。考え始めると、帰属意識、事業の課題を解決する使命感、そしてその立場の価値を感じるようになりました。

コア競争力の問題に関しては、私は全く間違った対象と比較していたことに気づきました。製品同士を比較したり、ビジネス同士を比較したりすべきではありません。むしろ、製品よりもビジネスを理解し、ビジネスよりも製品を理解する必要があります。

この原則は理解しやすいのですが、製品とビジネスの両方の属性を持つ立場として、どの方向に力を注ぐべきでしょうか?

ToB 製品の本質は、ビジネス上の問題を解決することです。したがって、まずビジネスを徹底的に理解することによってのみ、ビジネスのニーズについて話し合い、製品の進捗状況について話し合うことができるのは明らかです。

そこで私はローテーションに応募し、半月間熱心に業務に取り組み、業務プロセスを注意深く要約し、すべての製品機能を体験し、市場で入手可能なサードパーティの業務システムをすべて分解しました。

その後、私の要求の精度が向上し、ビジネス マネージャーと製品マネージャーの両方とのコミュニケーションがよりシンプルでスムーズになったことがわかりました。便秘商品のプロモーションも改善されました。

自分の仕事に対するコントロール感を感じ始め、すべてが良い方向に進んでいるように思えました。しかし、新たな問題が浮上しました。製品オペレーションは本当に単なる仲介役なのでしょうか?

B サイドの製品操作は、製品を渡して操作させる必要があるようです。この役割には、製品、運用、ビジネスに関する理解が必要です。

• 製品を理解するということは、ビジネス側から報告された問題を要件に絞り込み、要約できるようになることである。
• オペレーションを理解することは、ビジネス関係者に製品の機能をより効果的に宣伝し、繰り返し使用できるようにすることです。
• ビジネスを理解するということは、製品コミュニケーションにおけるプロセス、シナリオ、ビジネス上の問題点の重要性を説明することを意味します。

職務機能の面では、実際には製品とビジネスの仲介役として機能します。

しかし、私の仕事の中で、この理解だけでは不十分であることがわかりました。なぜなら、ニーズの精度と必要性は向上したが、ニーズの遅延とニーズの断片化という2つの問題がまだ残っているからです。

ビジネスにおいて製品や特定のビジネスリンクに問題がある場合、彼らは私に相談し、私はビジネスに関する比較的深い理解に基づいて製品の要件を提出します。

つまり、問題が発生したときだけ、私が果たすべき役割があるのです。ビジネス上の問題を事前に予測し、事前に回避することはできません。

もう 1 つは、製品が発表されるたびに、ユーザー エクスペリエンスの問題や細かい機能上のポイントが取り上げられ、全体的な計画が欠如していることです。経験上の問題により開発が重複することになります。機能要件が多すぎると、バックエンド システム全体が混乱し、システム自体が雑然とした状態になりやすくなります。最終的には、バックエンド全体のエクスペリエンスとシンプルさの両方が特に大きな課題に直面することになります。

これら 2 つの問題は、明らかに製品機能の計画に問題があることに起因しています。ビジネスの基本ロジックは明確であり、バックエンド製品の基本的なフレームワークも明確である必要があります。

しかし、現状は、全体の枠組みに責任を持つ人がおらず、各段階で製品が達成すべき目標や形態を分ける人がおらず、プロジェクトの全体的な目標やメリットを設定する人がいない状態です。

誰もがビジネスプロセスで発生する問題の解決に懸命に取り組んでいるため、根本的な原因に対処することなく症状だけを治療しています。バックエンドのパッチ数が増加し、バックグラウンドはますます肥大化し複雑化しています。

以前のプロジェクトから引き継がれた問題に遭遇したとき、彼らはただお互いに責任を押し付け合い、結局、反復の難しさから何も行われませんでした。ビジネス側は困難にもかかわらずそれを使い続け、製品側は壁紙張りの役割を果たし続けます。

もちろん、製品マネージャーの数は限られているが、製品の需要は無限であるという事実など、多くの実際的な要因が関係しています。多くの事業ラインでは、当初は製品機能全体の明確な枠組みを作るための製品マネージャーがいませんでした。彼らは通常、より成熟したビジネス ラインのバックエンド システムを直接使用し、必要に応じて変更を加えました。

しかし、企業間ではまだ大きな違いがあるため、全体的な計画作業は誰が行うべきでしょうか?

2つの状況があると思います:

前者の場合、バックエンド製品の責任者であるプロダクトマネージャーは、プロジェクト開始時に、バックエンド製品の最終的な形、段階的な実装手順、製品の詳細な機能など、ビジネスに基づいた体系的な計画を立てる必要があります。

この場合、製品オペレーションはビジネスをより深く理解していると想定されるため、製品オペレーションも製品マネージャーの計画作業をそのまま繰り返す必要があります。

最終的に、ビジネスと製品の両方で満足のいく結果が得られるように 2 つの計画を統合し、段階的に実行しました。

2 つ目のケースでは、バックエンド製品を担当する製品運用担当者が前述の詳細な計画を立て、製品側とビジネス側との綿密なコミュニケーションを図り、三者すべてが満足する結果を得てから開始します。

したがって、どちらの場合でも、製品オペレーションは全体的、段階的、詳細な計画に責任を負う必要があります。

これは当社の中核競争力に依存します。私たちは製品よりもビジネスをよく理解しており、製品マネージャーが気付かない盲点も見ることができます。ビジネスと比べると、私たちは製品をよりよく理解しています。多くの複雑なプロセスは、ビジネス側だけでは製品機能に抽象化できません。仕事の焦点が異なるため、製品思考が欠如していることが多いのですが、私たちにはそれができます。

私たちは、製品マネージャーとビジネスの間の代弁者、製品機能のトレーナー、またはデータフィードバック専用の PPT 作成マシンになるべきではありません。代わりに、私たちは、製品のフレームワークを計画し、製品の段階を決定し、機能の詳細を記入し、ビジネスプロセスと開発に基づいて製品機能の実装を主導するチーフデザイナーになる必要があります。

これがToBプロダクトオペレーションポジションが本当にかけがえのない存在である理由であり、最も価値のあるポイントであると考えています。

つまり、プロダクトマネージャーは複数の事業分野に関与している可能性が高いため、私たちはプロダクトマネージャーの上流にいて、彼らを複雑な業務から解放する必要がありますが、私たちは 1 つの事業分野に特化するだけでよいのです。

私たちは、特定のグループ（営業グループなど）の下流になって経験と反復部分だけを行うのではなく、ビジネス全体の下流になり、ビジネス開発とプロセスをバックエンド製品フレームワークのリファレンスとして使用したいと考えています。

このようにして、製品機能の制限からビジネスを解放することができます。ビジネス側が思いつかないようなことを考え、製品化によって解決できるとは思ってもいなかったビジネスプロセス内の頑固な問題を抽象化し、実践することで、製品レベルでのビジネスをより良く前進させることができます。

このように、私たちは商品とビジネスの仲介者から大きく変化を遂げました。

• 製品レベルでは、私たちは提供者から計画者へと変わりました
• ビジネスレベルでは、私たちは聞き手からリーダーへと変化しました

引き継ぐバックエンド システムにすでに完全な計画がある場合、またはプロダクト マネージャーが担当している場合は、そのプロダクト計画も慎重に分析して理解し、その上で独自の計画や意見を提示する必要があります。

これを実行すると、次のようないくつかの利点が生まれます。

• バックエンド システムについて包括的な理解を持っています。ビジネスに対する深い理解に基づいて、プロダクトマネージャーとより緊密なコミュニケーションをとり、システムバックエンド全体に対して真に方向性のある建設的な意見を提示することができます。
• バックエンド製品のさまざまなモジュールをより明確に理解し、各モジュールに対応するビジネスシナリオをより深く理解し、将来のニーズの優先順位と必要性についてより合理的な判断を下せるようになります。
• ビジネスに対する理解に基づいて、ビジネスの問題点やプロセスの難しさなどを事前に予測し、この部分の製品化についてより前向きな計画を立てることで、ビジネスの問題を真に解決し、タイムリーな支援を提供できます。
• 明確な製品フレームワークとビジネス プロセスに依存することで、私たちのニーズはモジュール化されます。これは細かい要件でもありますが、あなたと製品マネージャーは、この詳細がどのモジュールを構築するためのものか、また、このモジュールが形成された後にはどのような質的な変化がもたらされるのかを知っています。これはプロダクトマネージャーにとって大きなモチベーションになります。結局、誰もが完成した作品を作りたいのです。
• あなたはプロダクトマネージャーとビジネスの間で大きな発言力を獲得し、真のリーダーとなり、代わりの人を見つけるのが難しくなります。

素晴らしいと思う友人もいるかもしれませんが、あなたとプロダクトマネージャーの境界線はどこにあるのでしょうか?これはプロダクトマネージャーの仕事を奪うことではないでしょうか?

これは補完的だと思います。業界には、「優れたオペレーターは製品を理解し、優れた製品は操作を理解しなければならない」という格言があります。

プロダクトオペレーションとプロダクトマネージャーは機能面では異なりますが、機能の立ち上げ、業務の改善、機能の利用率、B サイドのユーザー満足度など、担当する指標は似ています。

言い換えれば、これら 2 つのポジションは、同じバックエンド システムの同じ船に結び付けられています。製品をより良いものにし、ビジネスを円滑にすることが出発点である限り、機能の重複は発生しません。それどころか、私たちの専門的なビジネス観点、全体的な計画、ビジネスシナリオに対する深い理解は、プロダクトマネージャーに大いにフィードバックすることができます。

私自身の職務経験から、私はバックエンド システムを主導し、この役割でプロダクト マネージャーを支援してきました。私たちは非常に調和的に協力しており、製品マネージャーもプロフェッショナルな製品運用を尊重します。信頼と尊敬を基盤として、製品機能のプロモーション、フィードバック、反復はすべて非常にスムーズに行われます。

製品のプロトタイプを急いで作成する必要がない限り、製品マネージャーはあなたの提案を喜んで受け入れます。しかし、前提条件は、ビジネスを本当に理解していることです。

別の観点から見ると、トレーニング、グレースケールの調整、使用率の向上など、運用上の作業もたくさん行う必要があります。製品作業の重複は、私たちにとってプラスにしかなりません。

これにより、ToB 製品運用の全体像を把握できます。

役割の位置付け:

事業部門の下流では、事業全体の整理・把握を通じて、事業運営を支える業務システムの全体的・段階的・詳細な計画立案を行い、事業側との合意形成を図ります。

プロダクトマネージャーの上流では、全体計画に従って、製品部門と合意を形成し、プロダクトマネージャーと協力して製品機能の決定、推進、発売などを行います。

一般的に、製品運用は、ビジネスシステム全体の機能の立ち上げと反復、機能のトレーニングとフィードバック、データの収集と分析、使用率の向上とユーザー満足度を担当します。私の意見では、C エンドと比較して、B エンドの製品オペレーションは、製品の方向性の能力に重点を置いています。

2020年末に大手企業にて営業を0から1に効率化するツール群を構築しましたが、その効果は非常に良好でした。

そこで、他の新興事業部門も当社のツールを使い始め、より有効活用するために、2 人の製品運用担当者を派遣して学習してもらいました。

私はビジネスモデルから利用シーン、そして詳細な機能まで、大小40以上の機能について説明を始めました。彼らは、私がすべてを知っていて、使用シナリオを詳しく説明できることに驚いていました。彼らの印象では、これらの問題を考慮するのは製品マネージャーだけだろう。

そこで私たちは製品運用についての理解について話し合いましたが、予想通り、彼らは製品運用とはトレーニングとフィードバックに関するものだと考えていました。まさにこのような認知の違いが、私たちの能力プロファイルの違いにつながります。

これは、当社の将来の発展経路や給与パッケージ、さらには代替可能性の程度にも影響を与えるでしょう。

B サイドの製品オペレーションに新しく加わる人は、たとえ現在比較的基本的な業務を行っているとしても、他の理由がなくても、より安定した仕事とより高い給与を得るために、全体的な方向性を考え、成長していくべきだと私は提案します。

次の記事では、ToB 製品運用の能力ポートレートについて詳しく説明します。ご提案がありましたら、コメント欄で議論したり修正したりしていただければ幸いです。

この記事はもともと @宋知了 によって Everyone is a Product Manager に掲載されました。無断転載禁止

タイトル画像はCC0プロトコルに基づいたUnsplashからのものです

この記事で述べられている意見は著者自身の意見のみを表しており、人人士品夢家プラットフォームは情報保存スペースサービスのみを提供します。