読了: 約 7 分
プロダクトマネージャー、プロジェクトマネージャーの違いはよく聞かれる。採用の現場、評価、育成などのタイミングでも定義を分けて求めるスキルや経験を整理する必要がある。プロダクトマネージャーとは改めてなんなのか整理しておきたい。
概要
これは何
- プロダクトマネージャーの役割、業務、存在する意味について整理したもの
誰向けの記事か
- プロダクトマネージャーになりたい方
- プロダクトマネージャーとして成長したい方
- プロダクトマネージャーを採用したい方
- プロダクトマネージャーとは何かの基本を理解したい方
- プロダクトマネージャーが何故必要なのかを理解したい方
この記事の目的
- プロダクトマネージャーの基本を理解できること
- 基本とは
- ミッション、役割、業務内容
- 求められること
- プロダクトマネージャーがいなくて発生する課題
プロダクトマネージャーのミッション
- プロダクトを通して、事業の売り上げ・収益を最大化させ、事業や会社を成長させること
色々な論点があるが、結局はこれに尽きる。
特にスタートアップシーンでは「プロダクトマネージャー=ミニCEO」と呼ばれるが、事業の0-1を立ち上げることができない、事業が伸ばせない、事業が成長しない、売り上げが伸びない/上がらないプロダクトのプロダクトマネージャーは存在する意味がなくなってしまう。事業や会社の成長エンジンとなりうる人がプロダクトマネージャーである。
プロダクトマネージャーの役割
ビジネス・テクニカル(開発)・ユーザー(顧客)の中間に存在
プロダクトオーナーとプロダクトマネージャーの違い
- 数名以上のPMがいる会社の場合
- プロダクトオーナー=事業責任者
- プロダクトビジョン・戦略の策定、管理
- プロダクトオーナーはプロダクトマネージャーのマネジメントを行う
- 場合によってはプロダクトマネージャーのプレイヤーとしても業務が求められる
- 小さい会社の場合(PM1-2名)
- プロダクトオーナー=事業責任者=プロダクトマネージャーを兼務
プロダクトマネージャーとプロジェクトマネージャーの違い
- 数名以上のPMがいる会社の場合
- プロジェクトマネージャー
- 進行管理、プロジェクト管理、予実管理、コミュニケーション設計などのプロジェクトをどのように回すのが事業によりインパクトを与える役割
- プロダクトマネージャー
- 開発、デザイン、分析、ユーザーの間にたち、総合的に思考
- プロダクトを成長させるための要求、要件をまとめて事業にインパクトを与える役割
- エンジニア、デザイナーにロジカルにwhat, why, howを説明できる
- howをエンジニア、デザイナーと一緒に詰めることができる
- プロジェクトマネージャー
- 小さい会社の場合(PM1-2名)
- ほぼ上記の役割・業務内容を兼務している
ポジションの定義と違いがなぜ発生するのか
色々な会社でポジションによる定義が変わるのは、会社にいるPM関連業務に従事する人のスキル・経験のカバー範囲が異なるためである。
人が増えるほどPMとして「どこが強みなのか」が肝で、事業成果を出すために分業化され、別れていく。プロダクトマネジメントトライアングルを見ても、プロダクトマネジメントの全てが完璧な人はほぼ存在しないため、上記のような分類でになっていくのが現状。
プロダクトマネージャーの具体的な業務・求められること
Why、Whatの解像度の高さ・言語化が大事
- 上段のWhy、Whatを詳細に詰めていくことがプロダクトマネージャーに求められていることである
- 何故か
- 機能やサービスを「何故作るのか、何を作るのか」が弱いとエンジニア・デザイナーが混乱し、ユーザー・顧客も使うのが不明になる
- 事業・会社・プロジェクトとして成立しなくなる
- 特にwhy
- 前提
- マーケティング・ブランディング的な思考・スキル・経験が求められる。
- 理由
- ここが弱いプロダクトマネージャーは作った機能やサービスのグロースイメージが弱い。
- 求められること
- 複眼で機能を考える。
- 競合のサービス・機能、ユーザー、自社の視点で機能やサービスを設計、企画し、実現へと導くことが何より求められている
- 前提
プロダクトマネージャーであれば下記のような部分の理解はしておいてほしいというのが経営・CPOの願いである。
要求を収集・整理すること
- what
- 自社他社の各ステークホルダー・ユーザー・顧客からの要求(要望・やりたいこと)を吸い上げる
- ユーザー・ビジネスを考えて、どのようにやっていくかの解像度を高める
- why
- ニーズ、要求がないものを作らないようにするため
- 想像でものを作らないようにするため
- how
- 画面設計図の作成
- 要求のwhat, whyを整理するためのテーブル・データベース作成
要件を収集・整理すること
- what
- 要求に対して、機能はどう実現すればいいかを整理すること
- why
- 機能をどう実現するかを整理していくために必要だから
- エンジニア、デザイナーとの機能の実現を話し合うために必要だから
- ビジネスにどのように実現すると要求が満たされるのかを確認・共有するために必要だから
- how
- ワイヤーフレーム作成、画面設計図
- システム要件の作成
システム要件に関してはコアな部分はエンジニア、デザイナーと詳細を詰めていくことになる。
データ分析
- what
- 何を、どう作って、結果どうなったかのデータを分析できること。
- データから示唆を出すこと、プロダクト・サービスのイシューを特定し、何をやるべきかを決定できること
- why
- 開発した機能・サービスのデータから次のアクションが決められないと顧客・ユーザー・市場の求められているものと異なるものを作ることになるから
- 適切な機能追加ができないから
- how
- SQL、python、R
- クエリ作成、ダッシュボード作成
- データ組織・体制の構築
デザイン
- what
- 要求に対しての要件がどのようにデザインされている、いくのかを判断・ジャッジしユーザーに求められるものを最終ジャッジすること
- デザイン業務を実際に行うより、要求・要件をデザイナーと整理、ワイヤーフレーム作成からデザインまでの落とし込みのプロセスに理解があること
- why
- どのように作られていくかに責任を持つのがプロダクトマネージャーであるから
- how
- ワイヤーフレーム作成
- Figma,sketch,adobe XDなどのデザインツールの利用
プロダクト品質の担保
- what
- リリース物がユーザーに触れる際の品質を担保する
- why
- 実装、デザインプロセスでの要求/要件のずれを把握してフィードバックするのがPdM業務であるから
- 要求を整理したPdMが一番品質に責任を持つべきであるから
- how
- テスト、Production環境での確認
- デザイナー、フロントエンド・マークアップエンジニアへの要求とフィードバック
- QA組織・体制構築
ソフトスキル
プロダクトマネージャー不在の場合の課題、起きること
ビジネスを機能やサービスに落とし込むことができず、ビジョンだけで利用されない
- 世の中のニーズ・課題を発見すること
- 他のポジション(営業、CS、マーケターなど)の人でもできる
- が、それをどう機能・サービスに落とし込めばいいのか(how)を設定するのがプロダクトマネージャーの業務である
- 世の中のニーズ(ユーザー)、ビジネス、開発を総合的に判断して、何を実現すればいいのかがわからない状態でよくわからないものができる可能性が高くなる
これが多くの企業で起きている。権限の強い営業上がりの経営者がプロダクトに意見して利用されないものを作り、崩壊していく・伸びないケースが多い上述してきたような観点でプロダクトマネジメントができていないから発生してしまう。
プロダクトマネージャーが採用がよりできなくなる
- 上述してきた通り、プロダクトマネージャーが不在だとプロダクトの品質を担保し、プロダクトによる結果を担保する人がいない
- プロダクトマネージャーはプロダクトの全てを持てるほど完璧な人は存在しないため、ほとんどの企業・サービスでプロダクトマネジメント業務を分割される
- ex: サービスごと、機能ごと
- プロダクトマネジメント業務を分割したいが、プロダクトマネージャーが不在の場合プロダクトマネジメントをどのようにやっているのか言語化できる人がいないケースが多い
- サービス設計、機能などの言語化・ドキュメント化をCTOが兼務しているケースもある
- プロダクトマネジメントを一からの整備に労力がかかるため、1人目のプロダクトマネージャーの採用が難しくなる
- 1人目のプロダクトマネージャーでこういったカオスを整理できるタイプの人は少ない
- タスク・イシュー的にはプロジェクトマネージャーの役割・業務
- 理由
- プロダクトマネージャーの趣向やスキルはプロダクトに向いており、これまでのプロジェクトを整理するのはあまり得意ではない・好きではないケースが多いからだ
- 1人目のプロダクトマネージャーでこういったカオスを整理できるタイプの人は少ない
結果、インターネットプロダクトの会社としての成長がしづらくなる。
終わり
プロダクトマネージャーの基本的な内容を書いたつもりだが、まだだいぶ不足している。私自身もプロダクトマネジメント兼務するプロダクト・事業がリリースされるので研磨していく。