見出し画像
Photo by chiyoizmo

PdMの介在価値ってなんだろう？

吉岡 太郎

はじめに

本記事は、プロダクトマネージャー Advent Calendar 2024 12/5公開記事になります。
初めましての人は初めまして、吉岡と申します。直近4年ほどPdMを担当しています。それ以前は開発ディレクターだったり、データエンジニアだったり、IA（UXデザイナー）などを経験してきました。

昨年に引き続きこちらのアドカレに参加させていただきました。去年はPdMのキャリアデザインの考え方について記事をまとめました。

今年のテーマをどうしようかと悩んでいたのですが、今年はPdMの介在価値について自分が思うところをまとめようと思います。

一般的に言われているPdMの役割

SmartHRのPdMとPMMの役割分担の図が非常にわかりやすいのでよく参考にさせていただいているのですが、PdMは「課題解決のために何を作るか考え、価値提供に責任を持つ」、PMMは「事業成長のために何をどう売るかに責任を持つ」と端的に整理されていてわかりやすいです。

また、SanSan(BillOne)とLoglassの事例もわかりやすいです。SanSanはBillOneの事例なのですが、その中で触れられているのが、プロダクトの価値向上に向き合いながら、マーケットの成長スピードに沿った事業戦略を一人で考えるのは限界だという話でした。

物量も大変だと思いますが、プロダクトの価値向上と事業戦略は場合によってはトレードオフの関係になることもあるので、そういう意味で分けた方が良いと私も思います。

でも昔のPdMはプロダクトのリードもビジネスのリードも一人でやるという感じだったんですよね。こちらのトライアングルの図を見たことある人も多いと思います。2017年当時の記事ですが、PdM = MiniCEO的なニュアンスが強く、当時はこれらの記事を読んで自分ではPdMは務まらないな、と思ったものでした。事業責任者の経験が不足していたためです。

もちろん今でもゼロイチで事業立ち上げ検証するフェーズ、フィットジャーニーの初期フェーズであれば、PdM（あるいはBizDev）が一人でやる形になると思います。PMMが活躍するのはGTM以降本領発揮という感じだと思います。

まとめると、今のPdMは「プロダクトの価値提供の方向性を決め、価値向上に責務を持つポジション」といえると思います。

PdMがいないプロダクト運営について考えてみる

つぎに、PdMの介在価値をあぶり出すために、PdM不在な状態でのプロダクト運営で起きがちなバッドストーリーについて考えてみます。

運営メンバーとしてはBiz(PO兼務)とCSとTech(EMとエンジニア数名)とUI デザイナーでの運営イメージです。

このメンバーだけでもプロダクトを作って運営することは可能だと思います。ただ、往々にして以下のようなことが起きてしまうのではないでしょうか？

  1. BizやCSからクライアントフィードバックがEMに共有される。

  2. EMが開発目線でフィードバックを選別しつつ対応するが、個別フィードバックに対応した開発を行ってしまう。

  3. いつまでも対応しないフィードバックに対して、クライアントからのクレームが来て、CSがあわててEMに共有する。

  4. そのフィードバックに対応するにはかなり重い開発になるため、結局開発しない。

  5. クレームを出していたクライアントがチャーンしていく。

  6. その間も開発が軽めの個別フィードバック開発を続けていく。

  7. その結果、誰も使わないような機能が大量に載って、つかいづらくなってしまったプロダクトが残される。

このような絵に描いたようなバッドストーリーが存在するかどうか分かりませんが、これに近い話は目にしたことある方いらっしゃるのではないでしょうか？

あと、7の状態でもPOがBizメンバーをしっかりマネジメントして売り抜けば売上は上がってプロダクトは存続するし、売り抜けなかったらプロダクトはクローズすることになると思います。

以下の図のように、売上を左右する変数は無数にあり、様々なビジネス活動の結果なしえるものです。
つまり、プロダクトの売上（アカウント課金なら課金ユーザー増）に対してあまりPdMの介在価値を見いだせないと思います。
特にSLGのプロダクトほどそうです。売上に直結する活動はBizの比重が高いです。

ただ、以下のようにPLGの場合は一定プロダクト側でも売上増に関与できる部分が出てきます。ただ、売上を増やす事業都合の開発とユーザーのファン化を促す価値提供はトレードオフになることが多いので、そこは慎重になってほしいと思います。

売上に直接貢献するのではなく、ユーザーペインを取り除き、ファン化を促すのがプロダクト開発メンバーの目指すところであるとしたときに、PdMの介在価値はどういったものになるのでしょうか？

PdMの介在価値について考える

このプロダクト運営にPdMがいたとしたらどうなるか？以下書いていきます。

ユーザーフィードバックだけに寄らないプロダクト開発の実現

上記のプロダクトはそもそもプロダクトロードマップに沿った開発を行っていません。
PdMはプロダクトのMVVを策定し、それを実現するためのロードマップを策定し、ロードマップから直近実現するマイルストーンに向けたプロダクトOKRを策定し、クォーターごとのプロダクトOKRに落とし込む。
と言う一連の作業をプロダクト運営メンバーとディスカッションしながら行っていきます。

これをすることで、そのプロダクトが対峙するターゲットユーザーが抱えている課題の解消、そこに向けたプロダクト価値提供を明らかにすることができ、チームメンバーの目線を合わせることができます。

結果として、チームメンバー間のコンセンサスが取れることで、チーミングも良くなりますし、プロダクト開発の結果として提供される価値がターゲットユーザー全体が求めているものに変換されていきます。上記のように一部のユーザーだけが嬉しい機能開発にはならないわけです。

ユーザーフィードバックマネジメントの改善

上記ではユーザーフィードバックがBizからTechに直で流れていましたが、PdMがいる場合以下のようなフローになります。

  1. BizやCSからクライアントフィードバックの一次受けとしてPdMが担当する。

  2. フィードバックはFlyleなどのユーザーフィードバック管理ツールで一元管理され、どういう傾向のフィードバックが多いかモニタリングする。

  3. プロダクトの成長に繋がり、かつ広いユーザーの課題を解決するフィードバックから優先順をつけて、PRDを作成する。

このようなフローになることで、結果的に無駄な機能開発をTechにさせず、使われない機能だらけのプロダクトにすることを防ぐことができます。

クライアントコミュニケーションの改善

この話はto B SaaS に限った話かも知れませんが、一部のクライアントからかなり強めの機能要求が上がってきたとします。

  1. そのクライアント担当CSだけではなくPdMもインタビューに同行して、現場のペインを直にキャッチアップする。

  2. 大体がそのクライアント特有の課題だったりするので、いきなりPRDを書いて開発に落とすのではなく、課題の解決策を数案考えて、ペーパープロトタイピングをする。

  3. それを持ち寄って再度クライアントとディスカッションする。そうすると、問題の根源がもっと深いところにある、と言うことが見えてきたりもするし、ディスカッションを行うことで、クライアントと一緒に企画を考えるという目線併せができる。

  4. このあたりからUIデザイナーにも入ってもらい、モックのデザインを作成して、オンラインMTGでクライアントに対してユーザーテストを実施する

  5. 実現可能な案に落とし込むことができたら、なるべく他のクライアントの状況でも価値になる機能のみをPRDに落とし込んで、開発に回す

自分だったらこのようなやり方で、一部のユーザーの強めのニーズも最大公約数的な価値に変換したり、クライアントと目線合わせすることで、次回の契約更新につなぐ努力をします。

こんなに検証に付き合ってくれるクライアントはいないと思われた方、ここで想定しているクライアントそういうクライアントではないです。
強めのニーズをプロダクト側にフィードバックするクライアントほど、裏を返すとプロダクトのことを考えてくれているクライアントなのです。
ですので、かなり検証に付き合ってくれます、今までの経験上ですけど。

まとめると、クライアントコミュニケーションの改善によるチャーン防止と偏ったニーズの機能開発を抑制する。という介在価値に繋がると思います。

プロダクト開発優先順のマネジメント

こちらは、EMがいれば開発目線での優先順マネジメントが行われます。上記の例もそれを想定しています。

ただ、PdMがそこに介在することで、プロダクトOKRに沿った開発だったり、かなり多くのユーザーからのフィードバックに対応するためのPRDだったり、その機能がリリースされるとユーザーが価値を感じ契約更新に繋がる開発が中心になっていきます。
もちろんバグ修正など開発的に優先度を上げて対応しないといけないものの優先度は下げてはいけません。

PdMとEMでディスカッションしながらプロダクトバックログをマネジメントすることで、プロダクト価値優先と開発優先の両立を目指すことができるわけです。

終わりに

いかがでしょうか、PdMの介在価値について感じていただけたら幸いです。
おそらく良いPdMがいるプロダクトは以下のような局面でプラスになるのだと思います。

  • 定量/定性分析によるターゲットユーザーがもつ課題の探索、ファクトあつめ

  • プロダクトのMVVに基づいたその課題の解決方法の起案・仮説立て

  • ターゲットユーザーに対する仮説検証

  • 必要なものだけを開発し、無駄な開発をさせない。ユーザビリティも向上する。

  • プロダクトバックログの優先順に秩序をもたらし、必要な開発から開発できるような環境づくり

  • プロダクトOKR運用によるプロダクトチーム全体のチーミング

これらの活動が結果どこに繋がっていくかというと

  • クライアントニーズの的確なキャッチアップ・アウトプットによる、Lovable Productの実現

  • そこに向かってチームメンバーの目線が合った状態でプロダクト運営ができるチーミングの実現

なのではないかな、と思います。

さらにその結果、ユーザー増に繋がって売上に貢献したり、チャーンレートが減ると言うところに貢献できると思います。。。

ですが、その効果はかなりタイムラグがありますし、BizやCS、Techやデザイナーの価値提供の方がもっとダイレクトに響くと思います。

もし、PdMの評価を売上ベースやチャーンレートベースだけで評価していたらそれは辞めた方が良いと思います。そこに繋がるもっと大切な活動を彼らは行っているからです。

PdMの評価軸は

  1. プロダクトOKRに基づいてプロダクト運営することでLovable Productに近づけられているか？

  2. プロダクト運営メンバー同士お互いを尊重しあい、プロダクト育成することを通したチーミング向上に寄与できているかどうか？

なのではないかなと思います。

私がお話ししたかった内容は以上になります。

2025年も良いプロダクトになるよう頑張ってプロダクト運営していきましょう！

いいなと思ったら応援しよう！