PMM（Product Marketing Manager）と協働するSaaSプロダクトマネジメント@PM Meetup by pmconf

第1回 PM Meetup by pmconf 〜ミニセッション大会〜にて、LTを行ってきました。
このnoteでは、その際のスライドの内容＋時間の都合で入れられなかった内容と、当日いただいた質問・質問への回答をご紹介します。

発表スライド

以下、内容を追いながら、情報を追加してお届けします。

SmartHRのPMチームの経緯と構成

SmartHRは、2015年11月に正式リリースされ、以降続々と様々な機能をリリースし続けてきました。（手前味噌ながら）驚くべきことに、１人目のPMが入社したのは2018年末です。また、PMM（Product Marketing Manager）が社内に誕生したのは2019年７月のこと。PM × PMM体制が出来て約１年、社内でもまだまだ模索中の段階です。

またPM不在時のプロダクト開発のコアを支えていたのは、社内の労務エキスパートの方です。労務人事サービスというプロダクト特性もあり、まさに「現場の課題を知り尽くすからこそ生み出せるモノづくり」だったと実感します。
企画がPM・PMMに移譲されてからは、社内に「人事労務研究所」を立ち上げ、新機能のレビューや、望ましい労務のあり方の提案・発信などを担ってくださっています。

PMの体制は「SmartHR本体」と「Plus Apps（モジュール化されたオプション機能）」で分かれており、本体を複数PMで、Plus Appsにはそれぞれ１名ずつPMがつく形で開発を進めています。

PMMって何？どうして必要なの？

PMM = Product Marketing Manager。その名の通り、プロダクトそのものではなく、マーケット戦略を中心に事業側の推進を担っています。より具体的には、

誕生した背景は、代表宮田のこちらの記事『「たらい」が2回まわったら新ポジションの合図』や、仕事の内容はWantedlyのこちらの記事『売れるプロダクトを考え、どう売るかを実現させる！PMM とは？』をご覧ください。

では、PMMはなぜ必要なのか。
それは、スーパーマンを求められがちなPM役割過多にあります。
プロダクトのビジョン、ロードマップ、リサーチ、企画検討、仕様作成、マーケット戦略、プライシング、KPI策定、効果検証、チームマネジメント…組織に寄りますが、挙げればキリがないでしょう。PMはミニCEOだ、という話もよく聞きます。一方、「プロダクト＝事業」と捉え、「プロダクト＝事業を推進し、その成功の責任を担う人」としてしまうと、とんでもない規模のプレイングマネージャーになってしまいます。

そこで、SmartHRでは、PMMとPMが協力して、事業とプロダクトを進めていく体制をとりました。具体的には、このような形で役割と責任の分担を行っています。

中規模以上の新機能の企画・開発を進める際は、まずPMMのリサーチから始まり、それぞれの過程に対して下の図のような関わり方をしていきます。

大切なのは、「企画」の過程の目線合わせです。市場のニーズをPMが的確につかみ、つくるものに反映するため、丁寧な認識共有が求められます。

また、過程の分担とともに重要なのがコミュニケーションの分担です。PMの役割過多の課題の１つである「関わる組織が多すぎてコミュニケーションコストが肥大化すること」の解消に繋がっています。

このように分担を行うことで、PMの具体的な役割は以下のように絞れてきます。 

【PMMと協働するPMの役割】​
・課題の発見と深堀り
・課題の優先順位付け
・要求とゴールの明確化
・仕様の検討
・プロダクトの提供
・他チームとの連携

中でも重要だと考えているのが、「課題の発見と深堀り」と「課題の優先順位付け」です。山のように寄せられる要望や市場のニーズすべてを同時に叶えられるはずがない現状に対し、プロダクトの成長方針やスピードは、課題の的確な把握と適切なスコーピングに左右されると言えるでしょう。

このように役割を分担することによる最大の価値は、
PMが提供価値(プロダクト)と価値を提供するチームに向き合い切れること
です。役割過多に悩まされているPMの方なら、おわかりいただけるのではないでしょうか？

to BにフィットしやすいPM × PMM体制

分担のありがたさを噛み締めながら、１つの疑問が頭をよぎります。「これってtoCでも機能する体制なんだろうか」。個人の意見としては、toCでPMMを導入するには、役割や責任の分担にひと工夫必要だと考えています。

それは、toCとtoBで、検証・成長サイクルが異なるから。

toC、特にユーザー数を多く抱えるWEBサービスやネイティブアプリであれば、機能をとにかく小さく出して、数字からインサイトを得て検証を進めることができます。一方SaaSの場合、売上改善にはマーケティングや営業の要素が大きく関わり、さらにユーザーが毎日使う業務システムとなれば、小さな違和感が命取りになることもあります。toBの複雑で有機的な成長サイクルを保ち加速するには、プロダクト⇔事業での役割分担がハマりやすいですが、プロダクトリリースと事業成長がより密接に絡み合うtoCのプロダクトにおいては、分担の境界はまた異なるポイントに引かれる方が望ましいのではないでしょうか。

役割分担による、求められるスキルの変化

私は、2020年１月に、toCのWEBサービスの会社からSmartHRに転職しました。前職の頃のコミュニケーションラインや担っていた役割は以下の図のようになります。今回の転職は、以下の３つの変化を伴いました。
・toC → toBへ
・１人でプロダクトと事業を見るPMからPM×PMM体制へ
・未経験の労務人事業界へ

この３つの変化により生まれたスキルの過不足を可視化すると、下の図のようになります。（※スキルチャートは、『プロダクトマネージャーに必要なテクニカルスキルを定義してみた話。』を参考にさせていただきました！）

ご覧の通り、PM×PMMの分担体制では、６角形の右上側「創る力」に必要性が寄り、その分求められる能力が高いことがわかると思います。このギャップを解消するため、転職してからは、業務モデリングやシステムの論理設計、情報設計、OOUIなど、ユーザーの要望を正しく仕様化する力の獲得に改めて取り組み続けています。

今後の課題

SmartHRが誕生して約４年半、またPM×PMM体制をつくって約１年。プロダクトと事業の成長スピードを支えるため、組織の規模は驚くスピード（この半年で約80人もの入社！）で拡大しています。市場も目まぐるしく変化を続け、競合追従によるコモディティ化の足音も迫ってきました。

プロダクトが飛躍的な成長を続けるためには、ユーザーと市場の声を聞き最速で、最善の価値を届け続けることが何よりも重要です。

現在私たちは、Productboardというツールでニーズや要望の集約と活用を行っていますが、残念ながらすべての声をプロダクトに反映しきれるわけではありません。

プロダクトが成長し続けるには、前半で挙げた「SaaSの有機モデル」が保たれ、より加速することが望まれます。そこには、セールスやカスタマーサクセス、サポートからのユーザーの困った声や、「市場」ではなくリアルな実体としての顧客の姿が欠かせません。プロダクトが、セールスやカスタマーサクセス、サポートからの信頼を失うことは、顧客の信頼を失うことにほかなりません。そのためには、顧客の前線に立ってくれるチームが「要望を挙げたら叶う」と実感できることや、「実態に沿った戦略やツールが届く」と安心できることが不可欠でしょう。

現在はとても幸いなことに、会社全体として「プロダクトは全員でつくるもの」という文化が根付いており、要望・FBの自発的な提供が生まれ続けています。しかし、半年で30%もの人数が増える急拡大組織において、既存の“信頼” や “自律性”だけにあぐらをかくわけには決していかないでしょう。
今後は、この相互供給を加速するための仕組みを必要としています。

Q&Aコーナー

ここまでが、当日の発表＋αの内容でした。ここからは、参加者の方々からいただいた質問と回答をご紹介します。Discordのチャットで猛スピードで答えており、やや思考不足な回答が見え隠れしますが、どうぞご了承ください。笑

Q. 売上というKGIはPMMが持つんでしょうか。それとも別の方、事業責任者でしょうか。それに伴う上下関係みたいなものはPMMとPMの間にありますか？

A.まさに、売上側はPMMのミッションになります。ですが、上下はなく、完全にフラットな位置関係で一緒にやっています！

Q. 従来、PDMもPMMも両方兼任していたPMからは役割、権限が減ってしまうことへのネガティブ感情ってありませんか？個人的に役割わけることに大賛成なのですが、ビジネス系出身のPdMからはこのような感情もありそうだと気になっています。

A. 私自身は、むしろ全方位であることによって中途半端なコミットが増えてしまうことが辛かったので、とてもやりやすいです。
ですが仰るとおり、向き不向きがある（要望の優先順位付けがビジネス主導でやりきれないフラストレーションを感じる人もいるのでは）と思います。

Q. ユーザーの生の声をどうやって聞いているか教えて下さい！
- リサーチ目的があるときのみインタビューを行っているのか、それとも具体的な目的がなくとも定期的にインタビューを設定していますか（定期的であれば頻度も教えて下さい!）？
- 既存ユーザーにインタビューをする場合、どのようにリクルーティングを行っていますか？

A. 現在はリサーチ目的のみしか行っていませんが、今後は定期的にやっていきたい！という話が挙がってきています。
リクルーティングは、現在は課題ベースでカスタマーサクセスチームに依頼をし、「解決しようとしていること」への課題感が強いユーザーさまのピックアップとアサインをお願いしています。

Q. PMMとPdMの持つKPIはどのように設計してますか？
例えば、PdMが特定KPI持つとそのKPIにヒットしづらい要望を実装するスピードは落ちるのような構造になってしまいそうなのですが、どう解消してるのでしょうか。

A. PdMは、定常的なKPIを現状は敢えて持っていません。
事業の方針とプロダクトロードマップを、経営陣にPdM・PMMを交えて検討することで、PdMの優先順位づけがビジネスとズレないような進め方をしています。

Q. PMMはリサーチ、PdMは開発、といったスライドがあったかと思いますが、ここは結構厳密に役割が分かれているのでしょうか？

A. マーケット調査はPMMが行いますが、課題の詳細特定のためのインタビューは一緒に行ったりしています。元々PdM出身のPMMもいるので、個々人のスキルと課題に合わせてかなり柔軟に動いている状況です。

Q. 複数のPMM & PdMで、どのように領域を分割されていますか？PdM とPMMは１対１対応のような役割分担でしょうか？組織が大きくなるにつれて、複数のPdM ＆ 複数PMM間での役割分担が難しいなと感じています。

A. 「SmartHR本体」と、「Plus Apps（モジュール化されたオプション機能）」でやり方が分かれています。本体の方は複数PMがチーム体制＋PMMが１名で、Plus Appsの方は１対１対応の体制で取り組んでいます。
仰る通り、複数PdM＆複数PMM間のコミュニケーションは、まさに今後出てくる課題と思われるので、試行錯誤が求められると考えています！

Q. ありがとうございました！社内にはPMMがいなく、PM&PMMみたいな状況です。PMMはトップダウンで配置された感じでしょうか？ボトムアップでPMMの担当を作るためのよい進め方あれば、助言いただきたいです！

A. PM＆PMM、わかります…！最初はトップダウンのアイディアでしたが、実際に誕生するにあたっては担う本人含め、社内検討の結果生まれたものです。ボトムアップで、ということであれば、課題やメリットの可視化をするとともに、もし可能であればPM同士で小さな役割分担をするなど、事例をつくってしまうのも良いのではないでしょうか？

Q. ありがとうございました。ちょうどマーケティング関係の仕事をし始めた所なので大変参考になりました。初歩的な質問ですみませんがPMM不在でPdMだけだと色々な面で問題が発生してしまう感じでしょうか？

A. 問題は、以下の２点が大きいと考えています。
- やることとコミュニケーションの対象が多すぎて、どれも不十分になってしまう
- 結果として開発スピードも事業成長スピードも落としてしまう
SaaSビジネスはリプレイスコストが非常に高いので、成長スピードを落とさないための選択をした、と捉えています。

Q. お話しありがとうございました。サポートからの要望の管理が気になるのですが、カスタマーサポートからの要望はどのように管理されていますか？サポートやサクセスは別途要望をあげる流れでしょうか。それともサクセスで要望を集約しproductboardで管理などされていますか？

A. チームを問わず、直接記入する形でProductboardを運用しています。SmartHRは労務人事サービスなので、社内の労務チームから「ここをカイゼンしてほしい！」という起票がなされることもよくあります！

追加Q. >直接記入する形でProductboardを運用しています
私の経験だと、利用者の要望をそのまま文字にしていると、本質の課題が見えてこないことがありますPMMまたはPMが書き直してProductBoardに書いているのですか？それとも一旦、直接要望を書き出して、後で整理（実際のソリューションを検討）する感じでしょうか？

A. 仰るとおり、生煮えだったり、課題が見えづらい起票もやはり存在します。そのため、PMMが目を通して起票者に詳細化を依頼したり、再度ヒアリングをしてもらうなどのことも実際に起こっています。
慣れで解消していく部分も多々あるので、試行錯誤している最中です。

Q. 弊社でもPMMとPdMの両輪で進めようとしたばかりで、お互い手探りでやってきていたのでとても参考になりました。
ちなみにPMMとPdMのコミュニケーションは、週どれくらいの頻度で実施されていらっしゃいますか？また、どんな内容をお話していらっしゃいますか？
私は毎週製品全体の活動進捗を確認する場と、お互いの業務状況をシェアする場を設けて、企画時は別途詰めて一緒に話すようにしています。
ただ、これだと普段はお互い素な関係性なのでそれで良いものなのかどうなのかと……

A. PMM・PdM全体のコミュニケーションは週に１度行っていて、またプロダクト別では、プロジェクトのフェーズにも寄りますが頻繁にやり取りをしています。
理想論ですが、「背中を預ける」ようにきちんと信頼と目的共有ができていたら、一定疎結合でも大丈夫なのかもしれない、と感じていますがいかがでしょうか…？

Q. PMMと言うよりも、単純な質問なんですが、Productboardを使用して感じる、メリットとデメリットを知りたいです。　運用上気をつけるべき点はありますか？

A. Product Boardの良さは、
- 要望のタグ付け、グルーピングができる
　→ 時折やってくるけれど、実は多い要望に気がつける
- タグ付け、グルーピングはチケット内のテキストにインラインで行える
　→ １枚のチケットに複数の要望があっても、クロスで情報整理が行える
- JIRAのチケットと紐付けて要望の進捗管理が行える
あたりかなぁと思っています。運用上気をつけるべき点は、JIRAのチケットが進行してもProductBoard側にはFBが返らないので、そこは手動になる点でしょうか…パッと思いつくのは、このような内容です。

Q. お客様からいただいた要望が解決された場合、開発側からお客様へのアナウンスはどのようなフローで行っているのでしょうか？
PMMとPdMの役割分担によって、お客様に情報が届くまでに1つレイヤーが増えるイメージがあるのですが、なにか工夫されていることはありますか？

A. 毎日、PMMが「今日のリリース」を取りまとめてSlackに全社周知してくれています。また、特に大きなリリースは週次の全社MTGで口頭でもアナウンスを行うようにしています。お客様へは、このアナウンスを起点として顧客コミュニケーションチームから要望元のユーザーへ案内してもらったり、「カイゼン・新機能のお知らせ」ページへの掲載などでお届けしています。

以上です！たくさんのご質問や意見が伺えて、オフライン以上に充実したイベント登壇の時間でした。運営の皆さんにも、心からの感謝を！

PMを募集しています！

SmartHRではPMを募集しています！
「SmartHRってもう完成したプロダクトでしょ？入ってやることあるの？」という声をよく伺います。
声を大にして言います。　　「めちゃくちゃたくさんあります！」
大事なことなのでもう一度。「めちゃくちゃたくさんあります！」
ユーザー規模の急成長への対応はもちろん、まだ何度も生まれ変われるくらい、やりたいこと・やるべきことが山積みです。

HR領域はまだまだ課題だらけですが、企業の中で最も人と向き合う「人事」の方たちを支える課題を解決するPMの仕事はとてもやりがいがありますし、前人未到の課題に挑戦できる、とてもチャレンジングな環境です。
興味を持たれた方がいましたら、まずはカジュアルにお話をしてみませんか？

ありがとうございました！

それでは、長文をここまで読んでいただき、ありがとうございました。
またどこかのイベントでお会いできるのを、楽しみにしています。