キャディでPMMを立上げている笹口です。前職から現職にかけて7年ほど、toBを中心にプロダクトマネジメントをしてきました。
23年7月からCADDi DrawerというVertical SaaSの事業部に異動し、PMMの立上げに着手、今年1月にようやくチーム化したところです（といってもまだ私含め2人のチーム）

最初に、このテーマでnoteを書こうと思った3つのモチベーションについて。

①頂いた知見や学びをPay Forwardしたい
PMMの立上げに伴い、複数のSaaS PMM/PdMの皆様に大変貴重なヒアリングの機会を頂くことができました。また、デスクトップリサーチをして感じたのが、PMMの立上げに関する情報がまだまだ少ないということ。頂いた知見と学びをシェアすることで、今後PMMの立ち上げにトライされる方のお役に少しでも立てたらと思っています（末尾に参考記事のリンク集もまとめています）

②意外とPdMがPMMを立上げた事例が少ない
これは意外だったのですが、PdMがPMMを立上げた事例があまり見当たりませんでした。これってもしかしてアンチパターン…？という不安がよぎったりもしましたが、ひとまず私の事例を紹介することには意義がありそうだと感じています。PdM→PMMというキャリアの1つの選択肢としても見て頂けたら幸いです。

③仲間を見つけたい
24年1月にチーム化しましたが、全然人が足りていない＆やることや不確実性がまだまだ多すぎるので、一緒にキャディのPMMを作っていってくれる仲間を見つけたいと思っています。

ということで、もしキャディのPMMにご興味ありという方、気軽にDMお待ちしてます！PMMの立上げに関する壁打ちやご相談なども大歓迎です👇

なお、こちらはキャディの【うるう年キャディnote29連チャンリレー】企画で書いている記事です。今年って閏年なんですね。キャディやCADDi Drawerにご興味持って頂けた方は、是非他のnoteもお読み頂けると嬉しいです。

Step1 : PMM立上げの契機

そもそも、なぜPMMを立ち上げるのか。各社にヒアリングさせて頂いて見えてきた共通項は、Biz/Product双方の複雑性の上昇に伴って生じる様々な課題解決の必要性でした。

PMM導入背景の具体事例

まずは、各社にヒアリングさせて頂いた中で複数見られたPMMの導入背景とその役割について、いくつかのケースをご紹介したいと思います。

①プロダクト数増加、顧客属性増加によるフィードバックループの混線解消　　　
最も多く見られたのがこちらです。プロダクト数が増え、セールスやCS組織も拡大し、顧客層もエンタープライズからSMBまで多様化が進んだ結果として、各所からのVOCやフィードバックのループが混線し、Bizの「総意」が整理しづらくなってきます。必然、PdMが各所とのコミュニケーション/調整にかけるコストも大きくなるため、間に入ってインターフェースとして取りまとめるロールとしてPMMを配置し、フィードバックループを健全に回すことを目指すケースです。

②PdM、エンジニアの顧客解像度獲得の促進
組織が小さいうちは、PdMやエンジニアが直接顧客を訪問したり、セールスやCSと個別にやりとりすることで顧客解像度を高く保つことができますが、組織拡大に伴って徐々にそういったやり方が成立しづらくなってきます。そこで、PMMをPdMにとってのBizサイドのインターフェースとして配置し、適切な顧客解像度の収集や顧客接点の創出を促すケースです。このとき、PMMはPdM/エンジニアの顧客接点を奪うのではなく、むしろ促進する役割として機能することが望まれます。

③セールスインセンティブとプロダクト戦略のすり合わせ
マルチプロダクト化が進展すると、数字目標を持つセールスはより売りやすい、目標達成効率の高い機能を優先的に売り込むようになります。この動きは必ずしもプロダクト戦略と相容れないため、PMMを各プロダクトごとに配置し、プロダクトごとにセールスがそのプロダクトを売りやすいように営業同行をしたり、インナーマーケティングを打つなどのセールスイネーブルメントを担うケースです。

キャディの場合

CADDi DrawerはまだOne Productですが、プロダクト/組織が急速に拡大しており、顧客層はエンタープライズからSMBまで分化、さらには海外展開も推し進める中で、特にBizサイドの複雑性が増大しています。

Drawerへの異動当初にCPOの白井から伝えられたのは、サポートやナレッジマネジメントに関する課題意識と、PdMが徐々にリソースを割きづらくなってきていた新領域のリサーチ及び課題整理にイニシアティブを取って欲しいということでした。背景には、事業成長に連動してProduct組織として検討すべき新たな課題が増えていたことや、機能数の増加に相関して社内外の情報流通課題が大きくなってきていたことなどがありました。

これらの課題に対し、実は最初からPMMを立ち上げようと決めていたわけではなく、あくまでPMMというロールが一つの解決策になりそうだという感覚で、プロジェクトを進める傍らでPMMに関する情報収集を始めました。

ここからしばらくは、自分の役割をなんと呼ぶべきか自分でもわからずモヤモヤする時期が続きます。しかし名づけは強力なので、仮に一度PMMと名付けてしまってからやっぱり違いました、という状況は絶対に避けたいという思いがあり、半年近くこのモヤモヤとは付き合っていくことになります。

なお、当時はProduct Opsもアリだなと思い並行して調べていました。今でもPMMのスコープと重複する部分が多いと思っています。

Step2 : 位置取りを決める

デスクトップリサーチと各社へのヒアリングを通じて少しずつ自らの役割も体系化していきたかったのですが、各社のPMMの役割について一定のパターンは見えたものの、PMMというロールに画一的な定義や役割はなさそうだ、ということがわかってきました。

PMM = BizサイドのProduct軸での取りまとめ役？

一番多かったのは「PdMと対を成す、BizサイドをProduct軸で取りまとめるという位置づけ」です。

こちらのパターンを採用されている会社で有名なのはやはりSmartHRさんやSansanさんかと思います。記事も多く出されているので、よく参考にさせて頂きました。しかしながらこのパターンを採用されているのはSaaSとしてキャディよりも進んだSTEPにいる会社さんが多く、プロダクト数なども踏まえるとキャディには少し早すぎるモデルという印象を持ちました。

PMM = 開発フローにおけるProductionの前後を担う役？

次に着目したのが、「開発フローにおけるProductionの前後を担うという位置づけ」です。読み込んでいた海外の記事の中にいくつか見られたパターンでした。

こちらはプロダクト開発を3つのステップに分け、それぞれに必要な機能やテーマが整理されたモデルです。このうち、真ん中のTECHNICAL＝開発のステップを挟んだ前後のステップに、PMMが介在する価値がありそうだと感じました。

また、まだまだ組織が流動的なフェーズなので、組織や機能の観点で整理するよりも、比較的普遍性が高い開発工程のどのステップを担うかという観点で整理した方が、足元の課題にも柔軟に対応できるのでよさそうだと考えました。そこで、まずはこちらの定義を参考にしつつ、自分の役割を以下の2つの領域と定義しました。

Research&DiscoveryとGoToMarket

まずは開発フローを大きく3つの工程に分け、Productionを挟んだ前工程をResearch&Discovery、後工程をGoToMarketと呼ぶことにしました。これがキャディのPMM最初のスコープ定義です。

Research&Discoveryとは、「期中に生じる重要なテーマにタイムリーに取り組み、リサーチなどの一次対応をボトルネック化せず明確な意思決定をリードする」ことを目的とした取組みです。PdMが最初から動くような課題であれば問題ありませんが、手が足りずに着手できないが重要性が高いものであったり、複数のPdMが関わるようなスコープの広い課題を中心に対応しています。

GoToMarketは、「PdMと連携し、機能の価値を最大・最速に然るべきユーザーに届ける」ことを目的とした取組みであると定義しています。チャネルごとに適切なコミュニケーションプランを検討したり、新機能のリリース方式をPdMと議論して決めたりしています。

合わせてPMMが見るKPIも整理したかったのですが、各社へのヒアリングから得られた学びの1つに「PMMは流動性が高い遊軍的な動きをしていることが多い」というものがあったため、この時はまだそこまでは決めませんでした。

実際にPMMを設置していたが何らかの理由で他部署と統廃合した事例が複数みられたため、PMMのスコープは一旦定めるが、その中で何に優先順位を置くかは固定せず、Q単位に見直していく方針としました。

PMMが一次情報を占有しないというポリシー

PMMとしてスコープを決めて動き出す際に強く意識したのがこちらのポリシーです。元々長らくPdMとしてやってきた手前、そもそもPdMが必要な情報を全て集め、意思決定を一元的に行えていれば、それがプロダクトのアウトカムを最大化する上で最良な状態であるという意識がありました。

この状態を保ちづらくなってきたからこそPMMの立上げを試みているわけですが、かといってPdMが担うべきプロダクトのアウトカム最大化というミッションの重要性は揺るぎません。

PMMを立ち上げる上で、PdMがよりミッション達成に向かいやすい環境を作ることこそが重要だと考え、「PMMが一次情報を占有するつもりはない、むしろ自分をスルーして顧客訪問など好きに行ってもらって構わないし、PMMのサポートが必要なら遠慮なく言ってほしい」というスタンスを積極的に示すようにしました。

Not PdMという意識、アンラーニングの必要性

PdMがPMMを立ち上げる際のトラップの1つが、PdMのタスクまで無意識に手を付けようとしてしまうことです（自戒を込めて）。

Research&Discoveryのアクションとして開発着手手前の課題整理に取り組んでいますが、一度よかれと思ってエンジニアと打合せを行い、PRDに近いOUTPUTを出そうとしてしまったことがありました。これはもうProductionのステップなので、PMMのスコープを逸脱したアクションだったと反省しています。

そこからは腹を括ってアンラーニングしようと決め、自分はNot PdMであると宣言。エンジニアではなく、基本的に各領域のPdMと会話することを意識するようにしました。今のところこれでうまく回っています。

STEP3 : 3カ月～半年で持つイニシアティブを決める

スコープを決めることができたので、改めて直近優先的に取り組むアイテムの検討を行いました。まずDrawerの各部署のリーダー層にヒアリングを行って課題をリストアップし、自身のリソースやケイパビリティも考慮に入れつつ目標まで落とし込みました。参考までに、最初の3カ月で実行した具体的な取り組みのいくつかをご紹介します。

1. リリースプランニングの型化

まずは、GoToMarketの土台であるリリースプランニングのプロセス、会議体等の整備を行いました。当時は今より顧客数が少なかったこともあり、リリースはとにかくスピード優先で、各所で属人的な個人技によってリリースコミュニケーションが行われていました。

これに対し、まずはリリースコミュニケーションに関わるチャネルを一覧化してそれぞれのオーナーを明確にし、オーナーを集めた会議体を設置。なるべく柔らかい段階からリリース予定についてPdMと目線合わせをしながら、隔週のサイクルでリリースプランニングを行えるプロセスを構築しました。

2. サービスマネジメントの仕組み化

STEP1で触れたサポートやナレッジマネジメントに関する課題意識に対しての取組みです。問合せへ対応の生産性向上からデータの蓄積、プロダクトへの連携やナレッジマネジメントまでを包含した情報流通フローを構築することを目指し、まずは関連部署をまたいだグランドデザインを作るところからはじめました。具体的な仕組みづくりまで最初の3カ月では終わらず、今期いよいよ形にする段階に入っています。

インテイクフローの構築やナレッジマネジメントの仕組みづくりなど、結構力を入れて取り組んでいるので、いつか成果をシェアできたら嬉しいなと思っています。

3. イシュー整理と開発への連携

Research&Discoveryのメインアクションとして、いくつかのイシュー整理に取り組みました。なかなか言えないことが多くもどかしいのですが、特に加速が著しかった海外展開に関して法務と連携して各国の法規制に対応する要件を整理したり、PdMと連携してヒアリングやリサーチを実施したりといった活動などを行っています。BtoB SaaSの海外展開は色々とやることが多いので、いつかこのあたりの知見もまとめてシェアできたらと思っています。

4. PMMロールの定義と組織化

スコープは定めたものの、依然周囲からは笹口って何する人なの？がよくわからない状態に変わりはなかったため、ドキュメントを書いて認知を醸成しつつ、人員計画を引いてPMMの組織化を試みました。

正直馬力的に一人体制の限界を感じることが多々あり、あれもこれもやりたい…けど手が足りない…嗚呼…となっていたため、リソース増強は不可避の課題でした。ということで、STEP4に続きます。

STEP4 : チーム化と役割の更新

今年1月、無事チーム化することになり、晴れて正式にPMMを名乗るようになりました。リソースに至ってはなんと倍増（1→2）！当たり前ですが、やれることが一気に増えて非常にワクワクしています。ちなみに明日はそんなニューメンバーである色平さんがnoteリレーの担当なので、そちらも乞うご期待です！

PMMチームとしては、PdMと一緒に毎朝30分のDaily Check-inを行いつつ、週2回の1on1を定例MTG代わりにしてコミュニケーションを取っています。基本はオンラインコミュニケーションが中心です。

さて、チーム化したことで（今後のリソース増強も見据えて）やれることも増えるので、ここまでの取組みの成果も踏まえてPMMのスコープとPdMとの役割分担を更新しました。

Communication Hubを加えた3つの領域

ver1.0で定義したResearch&DiscoveryとGoToMarketは維持しつつ、新たにCommunication Hub between Biz&Productというスコープを追加しました。これは「Biz-Product間で相反するアクションや意思決定が行われないよう是正することで、Productにとって過剰な借金を抑制し、PL最大化とBS最大化を両立する適切な投資を促す」ことを目的とした取組みです。

過剰な借金、という表現を個人的には重視しています。急成長フェーズのSaaSプロダクトが負債を背負わずにスケールしていくことはほぼ不可能ですが、どの程度の負債であれば許容可能と判断するかは非常に難しい問題です。当然PMMだけで判断できるものではありませんが、PMMはポジション的に課題を早期に検知しやすいため、適切にCPOはじめProduct組織の意思決定に繋げ、ともに考えることが重要な役割だと捉えています。

他にも、Communication Hubとして機能することで、例えば開発ロードマップ上は対応しないという意思決定がなされている機能であるにもかかわらず、それを必須条件とされる顧客に対して営業が受注を取りに行ってしまうといった事態も防ぎたいですし、Productとしてなぜその機能に対応できないかといった説明も十分に果たしていきたいと考えています。

PdMとの役割分担

PdMとの役割分担に関しては、「一次情報を占有しないというポリシー」にも記載したとおり、基本的に「PdMはプロダクトのアウトカム最大化に向けてやるべきと思うことをこちらを気にせず好きにやってくれ」という考え方がベースにあります。プロダクトのアウトカム最大化に責任を持つのはPdMであり、開発優先度の意思決定を行うのもPdMです。

PMMは、Productに軸足を置きつつ、Bizサイドからアウトカム最大化に向けた動きを最大限レバレッジする役割だと考えています。Production Enablementという表現が近いかもしれません。加えてCommunication Hubの定義にもあるとおり、「PL最大化とBS最大化を両立する適切な投資を促す」ことに重きを置いているので、短期的なPLの最大化にも最大限取り組みます。

Research&Discoveryのスコープでは、開発要否の意思決定を経てロードマップに追加されるなどしてPdMがボールを持つか、開発しない意思決定が明確になされるまでは基本的にPMMがボールを持ちます。また、複数のPdMの管掌領域にまたがるような課題の整理もPMMが一旦ボールを持ち、各PdMがボールを持てるフェーズまでもっていきます。中には直接PdMが最初からボールを持つケースもありますが、そこまでPMMで管理することはありません。

GoToMarketでは、PL最大化の観点から最善の意思決定は何かを考えてPdMと議論します。例えば、ある新機能についてオプションとするのか標準機能としてリリースするのかといった議題があります。事業数字を達成するためのPL最大化の観点からはアップセルに繋がるオプションが望ましいですが、プロダクトの資産価値を高めるBS最大化の観点からは標準機能とすべきといった具合に意見が分かれることが往々にしてあります。PMMはPdMのスタンスを最大限尊重しながら、PLの最大化という軸足からも最適解を模索します。

PMMがやらないこと = DONTs

基本的にスコープアウトすることは最小限に留めたいですが、自らの役割を明確化するためにもDONTsの言語化は大事だと思っており、今後も更新していきます。

• 対象領域にPdMがいる場合、極力PdMとコミュニケーションし、エンジニアとの直接コミュニケーションは最小限にする

• Productとして対応可否を判断をしない

• 大きな運用リソースが必要な施策を打つ場合、リソース獲得や体制構築まで含めてオーナーシップを持てないならやらない

これらが現状PMMが機能するために置いている最小限の制約です。1つ目と2つ目はNot PdMであるということをブレークダウンしたものであり、プロダクトに関する意思決定はPdMのものであるということを明文化しています。3つ目はチームの台所事情を踏まえたDONTsで、基本的に自チームで大きな運用を持つことが現時点では難しいため、他チームのリソースを割いてもよいほど重要性が高い施策か、採用でのリソース獲得が見込める施策以外は実現しづらいという制約を言語化したものです。やるならとことんやりますし、中途半端なものはやらないことを意図しています。

これからの方向性について

最後に、今後の展望と方向性についてまとめたいと思います。

良いプロダクトを作って世界を良い方向に変えたい

まず、PdMからPMMへと役割を変えたものの、結局のところ私がやりたいことは変わっていません。良いプロダクトを作って、それを世に出すことで産業課題を解きたいですし、ユーザーにとって少しでも多くの幸せを届けたいと願っています。今回の役割の変化は、そんなゴールに向けてのアプローチの変化でしかありません。

PdMというロールの重要性や意義は今でも疑っていませんが、長らくPdMを続けてきた中で、同時にPdMだからこその難しさを感じる局面もありました。PMMとして、そんな課題感を打破したいという思いもあります。

昨年、Airbnbのブライアンチェスキーが、PM=PdMをなくしてApple-StyleのPMM路線に変更すると発言して話題になりました。プロダクト開発のToBeは常に移り変わっています。トレンドは常に追っていきたいです。

ちなみに、本件について私はこちらのオカダさんのツイートに大変共感しました。自分なりに、PdMというロールの再定義に取り組んでいるのかもしれません。

今後はいわゆるPMMの役割に近づいていくはず

STEP1で触れたように、現時点でキャディがPMMを導入する理由はProductサイドよりBizサイドの複雑性にあります。しかしながら、今後プロダクトも増えていくでしょうし、Productサイドの複雑性も増大していくことが予想されます。そうなってくると、先輩SaaS企業の皆様が取り組んでこられた取り組みの多くを、キャディでも実践していかねばならなくなるでしょう。

例えばセールスイネーブルメント的な取り組みです。今はPMMのスコープに入れていませんが、営業販促資料の作成やセールストークの磨き込み、メッセージングの統一といったアクションはより重要になってくると思います。また、プロダクトが増えてくればプロダクトマーケティング観点で担うべき施策も多くなるはずです。カスタマーサクセスの横串機能もより重要になり、企画機能と連携したカスタマーマーケティングのような施策も必要になってくるでしょう。

そしてもちろん、これらをグローバルな体制で実行していかなくてはいけません。ここがキャディの刺激的なところですね。私自身も何をすればいいのかまだはっきりとはわかっていません。一緒に考えましょう。

少なくとも、ここまでの8カ月間は今後PMMが本領発揮していくための土台作りが中心だったと感じています。1年後、2年後には全く違った景色が広がっているはずです。楽しみだ。

是非一緒に働きましょう！

ということで、最後に仲間を大募集して終わりにしたいと思います！選考でよく聞かれるポイントを簡単にまとめてみました。

• PMMとしての実務経験、プロダクト開発の経験はMustではありません。もちろんあれば大歓迎！

• 全員そうでなくてよいですが、セールスやMK、CSなどBizサイドでの何らかの実務経験、専門性をお持ちの方にJOIN頂けると嬉しいなと思っています

• 英語ができると活躍の幅がぐっと広がります。が、できなくても問題はありません。やることはたくさんあります

• 入社後に十分キャッチアップできますが、SaaSビジネスに関する基礎的な知識がある方が立ち上がりが早いです

• これもよく聞かれますが、製造業経験は不問です。入社後に1カ月程度の十分なオンボーディングコンテンツを用意しています。現組織でも製造業未経験者の方が相対的に多いと思います

そして何よりも、キャディのミッションに共感頂けること。これが一番大事だと思っています。当然ながら入社後に色々なことにキャッチアップすることで醸成されていくものですが、CADDi Drawerを、そしてキャディをスケールさせたいという熱意をもって頂ける方と一緒に働けたらとても幸せです。

そして、大変恥ずかしながらまだPMMの募集ページが用意できていないため、面談/面接をご希望の方はPdMやオープンポジションからアプライ頂き、PMM希望である旨お伝え頂ければ幸いです。カジュアル面談からのご相談も大歓迎です！是非お話しましょう！

最後までお読み頂き、ありがとうございました。思ったよりも長くなってしまいましたが、よければスキをポチっとして頂けるともっと嬉しいです！

[参考] PMMの立上げに役立つリンク集