見出し画像

PM入門者の『はじめの一歩』〜プロダクトマネージャーとして最低限の振る舞いとは?〜

 こんにちは、estieでVP of Productsを務めているtakuya__kuboです。

昨年に引き続きアドベントカレンダーで個人noteを書かせていただきます。

この記事はプロダクトマネージャー Advent Calendar 2024 の25日目の投稿になります。

はじめに

今年もPM業界に少しでも貢献できる内容をお届けしようと考え、テーマを選びました。

昨年は、「プロダクトマネージャー(以下PM)の不足」という課題に焦点を当ててブログを書きました(昨年の記事はこちら)。あれから1年が経ち、PMを採用・育成する環境は少しずつ変化していると考えています。

市場データや実務の実感を総合すると、PMの採用数は確実に増加しています。たとえば、求人市場では「未経験OK」のPMポジションが増え、さまざまな職種や業界からのキャリアチェンジも進んでいます。弊社estieでも、今年初めて未経験のPMを採用しました。この流れ自体はPM業界にとって非常に歓迎すべきものです。しかし、未経験からPMへのコンバートが増える中で、別の課題が浮上しているのも事実です。

その課題とは、「新たにPMになった方がどう成長すればいいのか」という問いです。特に、多くの書籍や記事などで「理想のPM像」が多く語られる一方で、現場で求められる「最低限の振る舞い」は明確でないため、PM入門者がそのギャップに苦しんでいる現状があります。

スタートアップの1人目PMや会社で初めての未経験PMの採用など、PMとしてのロールモデルや十分な学習環境がないなども想定されます。

本記事では、「PM入門者が最低限PMとして振舞えている状態」についての解像度を上げていきたいと思います。特に、細かいスキルセットではなく、PM入門者が最初に身に付けるべき振る舞いとその在り方にフォーカスして解説します。

この振る舞いを理解し実践することで、PM入門者が挫折せずにSmall winを獲得し、成長できる土台を作ることができるはずです。


PM入門者に求められる最低限の振る舞い:3つの柱

PM入門者が「最低限PMとして振舞えている」と言える状態は、「チームがプロダクトマネジメントを遂行できている状態かどうか」で判断できると考えています。

今年、別の記事で小説風にプロダクトマネージャーを学び直すという記事を書く機会がありましたが、そちらに書かせてもらった通りプロダクトマネージャーはひとりでプロダクトマネジメントをするのではなく、チームで行います。

その意味で最初のステップは「自分がプロダクトマネジメントを上手くできているかどうか」ではなく、「チームがプロダクトマネジメントをできているかどうか」に焦点を当てるのが良いと思います。

ただ、この抽象度ではなかなか具体的な振る舞いに進めることが難しいため、もう少しブレイクダウンをしていきます。

PM入門者がチームでプロダクトマネジメントを進める上で必要なのは、以下の3つだと考えています。

  1. 「叩かれ台」を作る:議論を引き起こし、チームを動かす。

  2. ステークホルダーと連携する:関係者間の調整役となり、進行を円滑にする。

  3. 優先順位をつける:限られたリソースで最大の成果を出す。

この3つは、PMとして初期段階で取り組むべき基本中の基本です。

PMはさまざまなハードスキルやテクニカルスキルが求められるものの、通常のソフトウェア開発においては、その職務遂行においてデザイナーやエンジニアほど技術領域の専門性は求められません。

翻っていえば、その専門的な職能を持つメンバーのポテンシャルを最大限開放していくための企画的な業務や障壁排除の役割を負います。

その意味で、この3つの柱とも言える振る舞いを行うことで、チームのポテンシャル開放を実現することが可能になります。

以下で、それぞれの振る舞いを深掘りし、具体的な方法も交えながら解説していきます。


1. 「叩かれ台」を作る:議論を引き起こし、チームを動かす

なぜ「叩かれ台」が重要なのか?

プロダクト開発において、PMの役割は「完璧な答えを出すこと」ではありません。もちろん一撃で答を出してしまうスーパーPMもいるでしょうが、そんな方はなかなかいません。むしろ不確実性が非常に多い状態では、自分の考える初期解は誤っていることがほとんどです。

そのような不確実性を伴う中でチームが進むべき方向を見つけ出すための議論を促進することが大切です。そのために必要なのが「叩かれ台」となる仮説やプロトタイプと言えます。

叩かれ台を用意することで、次のようなメリットがあります。

  1. 不確実性の解消

    • プロダクト開発では、「どう進めるべきか」が曖昧なまま進行することが多いです。叩かれ台を提示することで、不明点が具体化され、チームの議論が活性化します。

  2. チームの主体性を引き出す

    • PMがすべてを決めるのではなく、たたき台を基にメンバーが意見を出し合うことで、チームのエンゲージメントが高まります。

  3. 合意形成を促進する

    • 仮説やプロトタイプを用いた議論は、最終的な合意形成をスムーズにします。


「叩かれ台」の在り方と実践例

叩かれ台は、「これを元に話し合おう」と思わせるものであれば、形式や完成度を問いません。正直30%の完成度があれば十分だと思います。

ただし、以下のポイントを意識しながら実践することが重要です

  • 仮説を立てる
    「この新機能でユーザーの離脱率を10%削減できるのでは?」など、プロダクト目標を実現していくための仮説を立てることからたたき台はスタートします。

  • シンプルで具体的であること
    たとえば、PRDを書くにしても、システム図や、ラフなデザインモック、その他フレームワーク図など、視覚的に理解しやすいものが理想的です。

  • 批判を恐れないこと
    たたき台は不完全でOK。「これだと何が足りないか?」という観点を見つけ出すのが目的であり、仮説の不確かな部分を洗い出し、新たなアイデアや視点を見つけ出しましょう。


2. ステークホルダーと連携する:全体を見渡し、関係者を巻き込む

なぜステークホルダー連携が重要なのか?

プロダクト開発は、PMだけでは完結しません。営業、マーケティング、経営陣、さらには顧客など、多くのステークホルダーが関わります。PMは、これらの関係者を繋ぎ、全体を円滑に進める「ハブ」の役割を果たす必要があります。

チームのポテンシャルを引き出す上で、最も泥臭く、手間がかかる一方で重要なのがこの連携の要素です。

例えば、ステークホルダー連携を怠ると、以下の問題が生じます:

  • 期待値のズレ:関係者が想定していた結果と実際の進捗にギャップが生じる。

  • 意思決定の遅延:必要な情報が共有されないことで判断が遅れる。

  • プロダクト価値の低下:関係者のフィードバックが反映されないことで、ユーザーにとっての価値が下がる。


ステークホルダー連携の在り方と実践例

  • 期待値をすり合わせ認識の齟齬の発生を防ぐ
    できることとできないことを明確にし、不必要な期待を防ぐことが重要です。機能の効果やリリース期日の想定、その確度を適切に設定し、事前に合意します。

  • 透明性を保つために進捗を可視化する
    タスク管理ツールなどで進捗の可視化、大まかなリードタイムや進捗を関係者全員が見られる場を作ります。また、定期的な報告や進捗共有を行い、関係者が状況を正しく把握できるようにします。特に経営層やビジネスチームとのすり合わせは、変更が起きるたびに細かく連携し、ネガティブサプライズが起きないようにすることが大切です。

  • 信頼関係を築き、フィードバックが循環する仕組みを作る
    PMはこの信頼関係が何より大切と言えます。信頼関係なきPMはチームを動かせません。細かなコミュニケーションとSmall winを重ねる中でその信頼を積み重ねていきます。また、関係部署とのチェックポイントを設けるなど、ビジネスチームと仕様についてあらかじめすり合わせを行うなど、フィードバックの場を作ることでステークホルダーからのTrustを獲得することが出来ます。


3. 優先順位をつける:限られたリソースで成果を最大化する

なぜ優先順位づけが重要なのか?

当たり前のことですが企業の持つリソースには限りがあります。時間、予算、人材を効率的に配分するためには、PMがタスクの優先順位を明確にし、チームが迷わず動ける状態を作ることが欠かせません。

エピックやバックログの優先順位はそのプロダクトを担当するPMが持つ一番大きな権限です。最適な優先順位を導き出す振る舞いはチームのポテンシャル最大化に最も効果があると言えます。


優先順位づけの在り方

  • ゴールを基準に判断し、インパクトを作る
    その四半期や半期におけるプロダクト目標を定め、その大目的に最も効果のある判断を行います。プロダクト目標に最も寄与するエピックやストーリーは何かを決めることが、インパクトへつながります。

  • 時間軸やインパクトの大きさを起点に、Discipline(規律)を設定する
    緊急性に追われ短期的な判断を行うのではなく、長期的な価値を見据えた優先順位を考えることが重要です。バラバラと意思決定を行うのではなく、一貫した意思決定を行うためのDiscipline(規律)を決めることだと言い換えられます。例えば、開発の種類としても、新規のユーザー価値創出、既存価値の強化、技術的負債の解消、ユーザビリティ負債の解消、技術的チャレンジやラーニングなど、ラベルをつけながら何をどの比率で取り組むかを決めていきます。

  • 「やらないこと」を決め、再開の時も定める
    取り組まないタスクを選ぶ際には、当然ながら取り組まないことで発生しうる「ダウンサイド」を考慮する必要があります。それらのダウンサイドを考慮に入れながらも、覚悟を持ってやらないことを決めるのが重要です。一方、やらないと決めつつ、「何が起きたら再度検討するのか」を明確にすることで気持ちよく先送りすることが可能になります。


まとめ

ここまでPM入門者の「はじめの一歩」について述べてきました。
キャリアの先を見据え理想のPM像を追うのは重要ですが、Small winをきちんと踏むことで、自信をもってPMとしての道を歩んでほしいという願いがあります。

本ブログを読むと、「意外と自分はPMとしてやれているな」と思うこともあったのではないでしょうか。

この「最低限の振る舞い」を土台に、次のステップに自信を持って進んでいただけることを心から願っています。


以上、年末のブログでした!
もしこの件に関してご興味ある方いたら、takuya__kuboまでご連絡ください!それでは、よいお年を。また来年もよろしくお願いいたします。


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