PMがいなくてもプロダクトが成長していく世界とは
はじめに
プロダクトマネージャーは責任が大きく、やりがいがある一方で「自分がいないとプロダクトの成長が止まる」というプレッシャーに追われがちです。
組織として、PMなしでもプロダクトを継続的に成長させるにはどうすべきかを考えていきます。
多くの組織が抱える課題
多くの組織の課題としてBizサイド、Devサイドのコミュニケーションや期待値、納得感の問題というのがあると思います。
Bizサイド
- エンジニアリング、開発フローなどがわからず、バックログの管理をするのが難しい。大きな工数がかかる
- 期待してくれているほど開発者がオーナーシップ持ってくれない
- エンジニアからの事業、プロダクトに対して前のめりな提案がなくて、何かモヤモヤする
- 開発速度が妥当かどうか、わからない。何か遅いと感じる
Devサイド
- 事業、プロダクトとして何が価値で、どうなったら成功なのかがわからない
- なぜ、いつまでに開発するのかが腹落ちしてなくて、納得感がない
この手の問題は、２０人ほどのスタートアップから、１００人超えの企業まで本当にどこにいっても起きているな、、、と感じています。
こういう時に大体PMをDevの手前にロードバランサー的に置くことで一時的には解決します。
ですが、組織間のコミュニケーションのマイナスを０にする期待に対して、PMというロールを置いただけで、一時的に問題が解決しても、組織全体のケイパビリティとしては何も変わっていないという問題があります。 （そして大体PMが孤独で誰も苦労をわかってくれないため疲れて退職する、、、）
この問題に対して、組織として対応していくためにはどうすればいいか考えていきます。
PMなしでも回る組織にしていくためには
最初はPMに集約しますが、徐々にBiz,Dev含めた１つのチームとして課題発見〜機能リリースまでを継続的に行えるようになることが大事です。
これをしないと、待っているのはPMを挟まないと何も進まない、PMがボトルネックになる世界です。
前提として、そこそこコミュニケーションが取れている組織だと、PMがいなくても、
- プロダクト開発の優先度を決める
- なぜそれをやるのかを説明して納得感を醸成する
ともに５０〜６０点くらいは取ることができると思います （時々、優先度や期待値調整がずれて炎上したり。納得感のないまま開発が進んでコンディション悪化したりする）
PMが入ると基本的にここを１００点に持っていくことができます。
ただ、ずっと１００点を取り続けてもボトルネックになってしまうので、PMは自分なしでも、チームとして９５点くらいは取れるように持っていく取り組みをすべきだと思っています。
この辺りはチームを育てる、ピープルマネジメントのマネージャーとかとも共通する概念の気がしています。
マネジャーも同じで「私がいないと回らない」とか言っているうちは二流、いることでチームや組織の何かを一段上げるとようやく一流
— ohbarye aka 広島の粗大ゴミ (@ohbarye) 2019年4月24日
で、更にその上に、いなくなったあとに一段上がった状態をキープするように仕組みづくりや教育が出来てたら超一流という感じする
具体的に何をする？
シンプルなのですが、即効性があり効果的なのはとにかくステークホルダー間の対話を促すということ
雑に飲み会やイベントとかやったところで、求めている対話は生まれないので ゴールをプロダクトのWhy,Whatについて透明度高く議論できると置きます。
チームには
- マーケ得意な人
- P/L引くの得意な人
- 業務フロー詳しい人
- ユーザーインサイト引き出す人
など、色々な専門性を持った人がいるかと思います。 その中でプロダクトって特にToC向けとかだと、対話する場所としてちょうどいいんですよね。皆興味あるし、理解しやすく、意見も出しやすい。
これを実現するために、最初はPMが間に入って
Devに対しては
- ビジネスKPI
- プロダクトKPI
- ユーザーインタビュー
- ドッグフーディング
- CS、運用のフィードバック
といったビジネス、ユーザーの状況を
Bizに対しては
といったエンジニアリングを伝えていきます。
この時にただ事実を話す。データを見せるのではなく、PM主導でそれぞれの立場に合わせて翻訳した上で、解釈を付けて話すのが重要です。
そして互いに理解する取っ掛かりを作って、対話を促していきます。 （これをやるにはビジネス、ユーザー、エンジニアリングを広く理解している必要があり、結局プロダクトマネジメントトライアングルは大事ということですね）
プロダクトマネジメントトライアングルと各社の PM の職責と JD – Taka Umada – Medium
色々な組織の問題を見たり、聞いたりしていると、ユーザー、事業状況に詳しい人が知らない人を情報格差でマウンティングしやすい構造、それに伴って同じチーム内にも関わらず、発注者と受注者のような関係になってしまっていることが多いと感じます。
この状況から、それぞれが専門分野を持ちつつも、プロダクトのWhat,Whyという場所では、共通言語で会話していくようにしていきます
最終的な決定権はPMが持ちますが、PMの意見、決定に対しても立場問わずオープンに議論していけるようになったらゴールは近いです。
コツとしては１回で伝えようとせず、根気強く対話していくこと。 メインの業務の中で関わらない知識なので、内容よりもとにかく頻度が大事です。
上記以外にも
- Biz,PM,Devの関係の質が高く、期待値が合っている
- 事業上、どこに集中するかが明確になっている
- 開発リソースの配分が事業戦略に最適化されている
- プロダクトの成功が定義され、定性、定量で測定できている
…etc （それぞれが重厚なテーマなので、また個別で書いていきたい）
などの条件を揃えることができれば、PMなしでもプロダクト改善は進んでいくと思います。 プロダクト改善施策に関して、１００点は難しいとしても９５点くらいの決断は移譲してチームでやれるかなと思っています。
上記を私はプロダクトを改善するエンジンと捉えていて、PMはプロダクトだけでなく、このエンジンを作っていくことこそ重要だなと思います。
※注意
上記は事業が安定してきて、それなりに会社としてリソースに余裕ができてきた時の話です。 事業フェーズが進んでいくにつれて、１つ１つのプロダクト改善施策が事業、会社に与えるリスクは小さくなっていきます。
スタートアップなど、フェイズによってはプロダクトのWhatにおいて、１００点取り続けないと死ぬみたいな世界もあるかと思うので、そういうところは別かなと
チームに移譲できたら、PMいらなくない？
そんなことはないです。そもそも事業の注力領域やチーム編成も結構なスピードで変わっていく中で、上記をキープし続けるのが非常に難しい。 部分的、一時的にできるようになってから、完全に根付かせるまでは長い時間がかかるので、継続して取り組む必要があります。
そして何よりPMの役割って、すごく抽象化すると変化の仕掛けを作ることだと思っています。
プロダクトマネージャーはどう評価されるべき？元Google PM対談｜河合敬一×及川卓也 | キャリアハック
ビジネス、テクノロジー、ユーザーを俯瞰して見た時にそれなりの規模の組織、プロダクトって成熟してきているように見えても、どこかに局所的な１０倍の成長余地がまだきっとあるはずで、それを発見するのにPMのリソース使うべきだなと思います。
もう少し体系立てるとPMの施策には大きく
- バケツの穴を塞ぐ
- バケツそのものを大きくする
という２つの種類があると思っています。
（下記に非常によくまとめてくれている）
PMって何してんの？ プロダクト開発の４ステップ｜つるちゃん｜note
この中でチームが自律して行えるようにしていくのは、バケツの穴を塞ぐことまでで、バケツそのものを大きくするのは、何かしらの発想の転換、きっかけが必要だと思っています。
それは
みたいに、不確実性が高いところに腰を据えて一定時間かける必要があるなと
そういったところに常に自分のリソースを一定貼れるように、組織やフローなどを整えてプロダクトを改善するエンジンを作っていくべきなんだと思います。
