見出し画像

私がSalesforceで学んだプロダクトマネジメントの3つのこと

ChatGPTによる一言要約
— Salesforceでのプロダクトマネジメントは「Customer Success」を徹底し、お客様の成功を最優先に考える。プロダクト組織は超構造化されており、厳密なリリースサイクルと、明確な評価制度がある。一方で、プロダクトマネージャーの役割も多岐にわたり、PMの多様性を大切にしている。


2019年 米国サンフランシスコ Dreamforce

新卒でSalesforceに入社して7年ほど経ち、今月で退社します。
キャリア全般については、以前キャリアハックさんでまとめていただいたこともあるのでこちらもぜひご覧ください。

今回は、そのほとんどを過ごした、AI製品のプロダクトマネージャーとプロダクトマーケティングマネージャーでの経験から感じた学びを共有します。

徹底した "Customer Success"

Salesforceは"Customer Success"をコアバリューとして最も重視しています。
イノベーションを掲げる企業として、革新的で製品重視と思われがちですが、Salesforceの根底にあるミッションは、イノベーティブな機能を導入するだけでなく、お客様がSalesforceを通して成功することでした。

2017年に初のAI製品であるSalesforce Einsteinが発表されました。
当時は、いわゆる第三次AIブーム。各社が機械学習やディープラーニングを使った予測モデルの構築や、データ処理など、エンジニアやデータサイエンティスト向けの製品を発表する中で、Salesforceは「誰もが使える CRM のための AI」として打ち出しました。
営業のための売り上げ予測、コールセンターの問い合わせ分類、マーケターのためのメール開封予測など、ビジネスユーザーが「スイッチを入れるだけ」で最適な予測モデルを使うことができるという製品を立て続けに発表しました。

これはAIに限ったことではなく、分析、データ、コミュニケーション、開発者向けアプリなどあらゆる場面で 顧客中心に設計されていました。

一方で、高機能を維持しながらこれだけ複雑に複数のユースケースを持つマルチプロダクトを一貫したユーザー体験で提供するのは、大変難しいことだったりします。

では、

どのように一貫したプロダクト体験を提供できるのか?


完璧に組織化されたプロダクト開発

Salesforceではプロダクト組織のことをTechnology, Marketing and Product(TMP)と呼びます。営業やサポートと独立した組織であるプロダクト組織は、膨大なスクラムチームや何千に及ぶプロダクトマネージャー、エンジニア、UXリサーチャー、デザイナー、プロダクトマーケターなどが属しています。

これほどの大きな組織であるにも関わらず、買収組織を除くほとんどのプロダクトが春、夏、冬という年間3回のメジャーバージョンアップのリリースサイクルに完全に従っています。
これに従い、約1年先のリリース計画を策定し、数ヶ月前には具体的な実装機能を定め、1ヶ月前にはその開発を終えるというサイクルを繰り返しています。

プロダクトマネジメントの現場では、連続した締め切りが設定され、ユーザーリサーチ、PRDの作成、UIデザイナーとのデザインの協議、ユーザーインタビュー、エンジニアとの仕様決定、実装、そしてバグの修正などが、Sprintに合わせて週単位のスケジュールで進められています。

さらに、各グレードでのプロダクトマネジメントの役割も明確に定義されています。
「今何ができればいいか?」「次に上がるには何ができればいいのか?」
昇給に必要な明確な基準や与えられた役割でやるべき日々の行動まで、グレードごとに定義されています。

このように非常に構造化された組織と、プロセス化された開発体制があるからこそ、一貫したプロダクト体験をマルチプロダクトで何年も提供できているのだと感じます。

ビッグテックにいきなりプロダクトマネージャーとして入るのは難しそう…と考える方も多いと思いますが、実は温室育ちだったりします。
新人向けのAPM (Associate Product Manager)プログラムや、明確なキャリアパス、オンボーディング支援、社内教育コンテンツ、メンター制度などプロダクトマネージャーを育てる土壌が備わっているので安心して成長することができます。

そんなPMのオンボーディング資料の冒頭にあるメッセージが

「プロダクトマネージャーは十人十色」

というものでした (意訳)

プロダクトマネジメントの多様性

これまで主に開発を担当するCore PMについて触れてきましたが、PMには主に4つのカテゴリーがあります。詳細はこちら

私の直近の役割は「アウトバウンドプロダクトマネージャー」(OPM)というものでした。
OPMは、多くの企業、特にGoogle CloudやOracle, ServiceNowなどのプラットフォーマーに多く、直接開発チームを持たない一方、顧客の声をダイレクトにキャッチし、それを開発のPMへと橋渡しする役目があります。

特に開発拠点が米国やインドに集中しており、その他の地域での対応が難しくなる場合に、このOPMの役割が重要となってきます。
ただ、すべての企業が必ずOPMを必要とするわけではなく、しばしば贅沢なロール、とも揶揄されます。

顧客の声を聞くというのは多くの場合、営業、サポート、CS, PMMなどのチームがその役割を果たしています。しかし、こうした役割が機能しなかったり、連携が取れずにボールがこぼれてしまう時に必要とされるのがOPMです。
OPMを自社でも取り入れたいと思った方はこちらをご覧ください

しかし今年、SalesforceのOPMチームは解散となり、私は新たにインドの開発チームでの生成AI製品の開発PMとしての役目を任されることとなりました。しかし、色々なタイミングもありそのアサインを断り、別の挑戦をすることとなりました。これについてはまた別の機会に。

日本でのPMの認識は、米国よりも少し遅れているかもしれません。
正確で理想の「プロダクトマネージャー像」を追求するよりも、その会社や今のプロダクトに求められることに応じて最も適切な形を模索することが重要です。そのためには会社としてのブレないコアバリューと、構造化と柔軟性を合わせ持つプロダクト組織作りが大切なのだと思います。

振り返って

Salesforceのプロダクトマネージャーは、Customer Successという絶対的なコアバリューがあるからこそ、ガチガチにプロセス化された組織と、その中で柔軟に活動する、ことができるロールでした。
日本の会社では体験できないダイナミックさやイノベーション、規律や統制、そして個人の自由を新卒から学んだ気がします。そして多くの人にお世話になりました。LinkedInでの退職についての投稿

プロダクトマネジメントの領域で一つ明確なことは、成功への単一の道がないということです。
そのためには、常に好奇心を持ち、経験をすることだと思います。

手前味噌ですが、そんなことを実現する環境を PM DAOという場所で作っています。
プロダクトマネジメントをプロダクトマネージャーの専売特許にせず「誰もがプロダクトを通して価値を創れるように」をビジョンに掲げたコミュニティ?のような新しい組織です。
ぜひ、こちらをご一読の上、Twitter(X) @pmdao_official から活動の様子を見てみてください


この記事が良かったと思う方は、noteのスキと、お気持ちでコーヒーを奢っていただけると嬉しいです!


この記事が参加している募集

PMの仕事

仕事について話そう

この記事が気に入ったらサポートをしてみませんか?