B2B と B2C の製品管理: 実際にはどのように異なりますか?

プロダクトマネジメントの技術には多くのニュアンスが含まれており、その役割は企業ごとに、また業界ごとに大きく異なる場合があります。

この分野で繰り返される質問は、B2B と B2C の製品管理の違いを中心に展開しています。結局のところ、個々のユーザーが直面する問題は、通常、企業が直面する問題とあまり似ていません。

私は Intercom に入社して以来、このテーマについてよく考えてきました。以前は製品管理のキャリア全体を B2C 分野で過ごしていたため、類似点と相違点についてすべて直接学んできました。

この質問について考えてみると、Intercom で使用している研究開発原則が、相違点と類似点を理解するための非常に役立つプリズムであることがわかりました。

高レベルの製品原則は次のとおりです。

• 問題から始めましょう
• 大きく考えて、小さく始めて、早く学びましょう
• 早く発送、早く発送、頻繁に発送
• 成果を出す

では、これらの原則は B2B と B2C の異なる環境にどのように適用されるのでしょうか?

原則 1: 問題から始める

どの業界の PM の役割においても、「問題から始める」という原則は物議を醸す原則ではないと言えるでしょう。 優秀なプロダクト マネージャーは、自分たちが解決している問題に集中する必要がありますが、B2B 環境で問題の粒度を実際に深く理解する際に、私が気づいた違いがあります。 B2B 分野では、顧客の問題だけでなく、製品のエンドユーザー (つまり、顧客の顧客) についても考慮する必要があります。

「解決しようとしているすべての問題には、探索すべき膨大な量の下位問題が伴います。」

これに SaaS 製品の開発を加えると、製品が非常に複雑になり、考慮する必要がある問題が発生します。 解決しようとしているすべての問題には、検討すべき膨大な量の下位問題が伴うことはほぼ確実であり、構築している各製品や機能には、考慮すべき多数のユース ケースやエッジ ケースがあることになります。 私は、問題を明らかにするフェーズにずっと多くの時間を費やし、「深く掘り下げる」ことを自分に課し、解決すべき問題、誰のために解決すべきか、そして同じくらい重要なことの概要が本当に明確になるところまで到達することに気づきました。私たちが解決しようとしていないこと。

原則 2: 大きく考え、小さく始め、早く学ぶ

この原則の一部は、ご想像のとおり、「大きく考える」ことと、問題を解決するための幅広い方法を模索することであり、おそらくすでに頭の中にある解決策のアプローチを直接実行するのをやめることです。 解決策の方向性が定義されたら、顧客の問題を解決できる最小の解決策を考えます。ここで範囲を絞るのは難しいはずです。 一般に、原則のこの部分は B2B と B2C でかなり一貫していると思いますが、原則の後半部分である「早く学ぶ」を考慮すると、間違いなくいくつかの違いがあります。 これは製品開発のあらゆる形態において絶対に重要ですが、B2B と B2C では学習方法が大きく異なる場合があります。

「B2B 製品管理では、製品と機能を検証するためのベータ版の実行に重点が置かれています。」

B2C プロダクト マネージャーは、多くの場合、何百万もの顧客が製品を使用しているという膨大な量の定量的データにアクセスできることに恵まれています。 偽のドアのテストなどの実験タイプを定期的に活用して、何かを構築する前に顧客が機能を使用するかどうかを知ることができます。 このデータへのアクセスは、A/B テストを通じてソリューションが問題を解決したかどうかを学習したり、多変量 (MVT) テストを通じてどのソリューションが正しいかを検証したりするのにも役立ちます。

B2B 環境では、多くの場合、この種の実験を効果的に実行できるサンプル サイズがありません。 もちろん、これは常に当てはまるわけではなく、成長製品チームは依然としてこれらを実行していることがよくありますが、必ずしもデフォルトであるとは限りません。 代わりに、問題レベルと解決策レベルの両方で顧客と実際に話すことに多くの時間を費やし、正しい軌道に乗っているかどうかを理解するために定性データにさらに依存します。 また、定量的な使用状況データと定性的な学習データを組み合わせて使用​​して、製品と機能を検証するためのベータ版の実行にも重点が置かれています。

原則 3: 早く発送、早く発送、頻繁に発送

この原則は一目瞭然で、前の原則の「小さく始める」要素を主に踏襲しています。 真の製品主導の組織では、業界に関係なく、迅速、早期、頻繁に出荷することが最前線にあるべきです。 ただし、私の個人的な観点からすると、B2C 環境で実行するのは少し難しい可能性があります。

「法人顧客はベータ版機能の使用に非常に前向きであることがわかりました。」

場合によっては、B2B 顧客は消費者よりも忍耐強いことがよくあります。 これは必ずしも、問題が解決されるまで喜んで長く待ってくれるという意味ではなく、代わりに、私たちが出荷するものに対してもっと忍耐強く待ってください。 ビジネス顧客は、ベータ機能が完璧な製品や完成品ではないことを十分に承知しており、ベータ機能を使用することに非常に前向きで、問題を解決するためにどのように協力できるかについてフィードバックを共有するために時間を費やしてくれることがわかりました。

私たちは、Amazon のような企業が消費者の期待を信じられないほど高く設定し、必要なものはすべてすぐに提供または解決できると人々が思い込み、それができない場合には無数の代替手段に頼る世界に生き、競争しています。 それに比べて、企業顧客は、迅速、早期、頻繁に提供される機能を使用することにはるかに積極的です。

原則 4: 成果を達成する

私は、「結果を提供する」という原則について、また、B2B 製品と B2C の製品に実際に違いがあるのか​​どうかについて、少し時間をかけて考えました。 早く学習する方法と、消費者製品が大量の定量的データにアクセスできることについての私の論点を思い返すと、私の最初の反応は「はい」でした。 ファネルコンバージョンや収益の向上などの定量的な成功指標に重点を置くと、B2C プロダクトマネージャーが成長プロダクトマネージャーと並んで、成果を出すことに重点を置いているという認識に確実につながる可能性があります。

「Intercom では、最近の機能リリースに使用した手法の 1 つが、プロダクト マーケット フィット (PMF) パネルです。」

しかし、さらに深く掘り下げてみると、これは純粋に認識であると思います。 業界に関係なく、すべてのプロダクト マネージャーは成果をあげており、問題が解決されたかどうかを確認するために適切な成果指標に重点を置いている必要がありますが、違いはおそらく、成果の種類にあります。

B2B では、使用状況や製品満足度などの明確な定量的な指標であることがよくありますが、B2C 分野ではあまり見られない、品質に焦点を当てた指標になることもあります。 Intercom では、最近の機能リリースに使用した方法の 1 つがプロダクト マーケット フィット (PMF) パネルです。これは、少数の顧客が当社製品への移行や製品の一部の使用を妨げられないようにするまで協力します。 7 ～ 10 人の顧客のブロックを解除して製品を使用できるようにすることは、重要な B2C ビジネスではほぼ確実に測定できるものではありません。

普遍的な問題解決

B2B と B2C のプロダクト マネジメントが実際にそれほど違うのかを考えた結果、私はある結論に達しました – いいえ、それほど違いはありません。

基本的に、B2B 環境でも B2C 環境でも製品管理は一貫しており、Intercom の研究開発原則は業界全体に関連しており、拡張可能です。

私が発見したのは、異なるのはプロセスだけであることが多いということです。 さまざまなレベルの製品の複雑さ、データの種類、出荷方法、学習、結果の測定などの作業がこの例です。 しかし、最終的には、製品管理とは、置かれている環境に関係なく、実際には問題解決がすべてです。