見出し画像

プロダクトマネージャー(PdM)になるために #2_PdMの役割と多忙な理由

IT業界で引く手あまたのPdMについて学習しています。
顧客オリエンテッドな商品が不可欠、とはよく言われますがそのために企業・組織としてどうあるべきかを広く・緻密に学ぶことができています。
カスタマーサクセスのポリシーにも準じていて楽しいですね。(業務は死ぬほど大変みたいですが)
先に言ってしまいますが、この章ではPdMはめちゃくちゃ忙しいから覚悟しなさいよ!って警告がよく出てきます笑
だからこそ、必要不可欠な責務だとも感じる内容です。

前回は導入編でした

今回は、必要なスキルと組織についてです。
文字数:約3,800

以下のnoteから参考図書を決めました
Shoko Suzukiさん、ありがとうございます。
自分の備忘メモに近く、読み物としては最適ではないですがご容赦くださいすが、ちゃんとインプットとしてアウトプットします。

参考図書

② 成功するための組織と人

◼️Chapter9 優れた製品開発チームの10の原則

製品開発チームは職能横断型のチームでさまざまな専門技能と責任を持ち、製品への愛着を持つ
<1、使命感を持った開発チーム>
・報酬目当てのチームは作れと言われたものだけを作る
・使命感を持つことで顧客のための問題解決に全力を傾ける

<2、開発チームの構成>
・典型的なチーム構成は、1名のPdM、1名のデザイナー、2〜12名のエンジニア

<3、権限移譲と説明責任>
・プロダクトチームの基本理念は企業にとって困難な問題を解決するために存在すること

<4、規模>
・1チームの上限としては8〜12人のエンジニア
・ジェフ・ベゾスが提唱した2枚のピザルール(1チームはピザ2枚で賄える人数:5〜8人)の範囲にとどめる
・開発チームの規模よりも、適正なものを適正に作るために必要なスキルのバランス

<5、上下関係>
・一人ひとりが独自のスキルで業務貢献するためフラットな組織構造になる

<6、開発チームの協力>
・階層型組織でなく、真の意味で協力し合う関係

<7、開発チームがある場所>
・できる限り一ヶ所にまとめる
・少し古くさいスタイルとは承知しているが、一緒に座り時間を過ごすことで生まれる独特なエネルギーがある

<8、業務範囲>
・なすべき仕事の「種類」
・全てのプロジェクト、機能、バックオフィス、性能の実現、最適化、コンテンツ変更などありとあらゆることに対して責任を持つ
なすべき仕事の「範囲」
・現在では顧客が体験するものすべてが製品
・企業の成長と合わせて開発チームの数は増え、チームの切り分けは「ユーザー別」「ワークフロー」「デバイス」「アーキテクチャ」など色々あるが、この切り分けに完璧な方法はない

<9、継続期間>
・イノベーションのために、ある分野の十分な専門知識を得るには時間がかかる
・開発チームは特定のプロジェクトを遂行するだけに作るものではない
2、3ヶ月で解散するチームでは使命感を持ったチームを作るのは不可能

<10、自律性>
・権限移譲を感じ、顧客の問題解決する使命感を持つためには大きな自律性を与える必要がある
開発チーム間の依存を最小することが目的であり、チーム間の依存をなくすことは出来ないので、常に最小化に尽力する

・なぜ開発チームモデルはうまくいくのか
1、協調関係は人間関係の上に築かれる
2、イノベーションに専門知識は不可欠
3、チーム全体がビジネスの目標と背景を理解し、チーム全員が成果を自分のものと感じ、責任感を持っていること
・古いプロジェクト指向モデルではプロジェクト完了が終わりだが、開発チームモデルはプロダクトが顧客と企業のために役立つようになるまで休むことはない

INSPIRED
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P46〜54

■Chpter10 プロダクトマネージャー PdM

・PdMの仕事のやり方は基本的に3つあるが、成功につながるのはその中の1つだけ
1、PdMが全ての問題や判断をCEOに委ねる
→バックログ管理者に過ぎない
2、ステークホルダーを招集し議論で決着させる
→ロードマップ管理者に過ぎない
3、自分のすべき仕事をする
→この働き方を確信させることが本書の目的

PdMは非常に過酷な仕事であり、優れたスキルと能力が要求される
・PdMには
 *技術に関する高度な知識
 *ビジネス手腕
 *主要幹部との信頼関係
 *顧客に対する深い知識
 *製品への情熱 & チームへの敬意

がなければ間違いなく失敗する

<主な責任>
・責任は明快で可能性を評価し、何を作って顧客に届けるかを判断すること
難しいことは、プロダクトバックログに書かれたことが作るに値することか確かめること
・全てのビジネスは顧客に依存しており、顧客が買うものがプロダクトである
・プロダクトが成功するのは開発チーム全員がすべきことだが、失敗の責任は全てPdMにある

重要な責任①:顧客に関する深い知識
・PdMは顧客の専門家で、顧客が抱える問題、悩み、欲望、考え方、仕事のやり方、購入までの意思決定方法まで知る必要がある
・プロダクトについても専門家でなければならない

重要な責任②:データに関する深い知識
・データの扱いと分析力が必要(定量・定性的な両輪のスキルが必要)
・PdMは30分ほど分析ツールからそれまでの24時間で起きたことを把握する

重要な責任③:自社ビジネスへの深い知識
最も難しいと考える要素はビジネスとその仕組みの理解
・ビジネスの中でプロダクトが果たす役割を理解すること
・成功するためには、ステークホルダーが課す制約を理解していると納得させることが必要で、その制約に矛盾しないソリューションの実現に専念していると思ってもらうこと

重要な責任④:市場と業界についての深い知識
・競合だけでなくテクノロジー、顧客の行動と期待など理解する
他の多くの製品から形成されるエコシステムにうまく適応し、そこに付加価値を付け加える

<求められる人間性>
・飛び抜けて頭が良く創造的で粘り強い人
頭が良いとは、知的好奇心にあふれ、新しい技術をすぐに習得し顧客の問題を解決し、心を掴み、新しいビジネスモデルを作ること
製品に対する愛情と顧客の問題を解決したい熱意は教えてもらうものではない。この熱意があるかどうかが大きな判断軸になる
PdMはとんでもない量の仕事で、家に仕事を持って帰ることになる
PdMには大変な準備が必要

<PdMのプロフィール>
・本書では具体的なバイネームを複数挙げて事例を紹介する
・これらの事例で伝えたい4つのこと

1、PdMはほかの仕事と決定的に違う
・デザイナー、PMとも明らかに異なる
・PdMの役割に一番近いのはCEOだが、CEOと異なりPdMに部下は居ない

2、ビジネスのあらゆる側面を深く理解していなければいけない
・プロダクトの定義だけでなく、ビジネスの成果も確実にする
・経営のスキルを全て身に付けている必要もなく、プロダクトがビジネスに与える影響を理解し実現のためにあらゆるステークホルダーと協力しなければならない

3、成功したソリューションがユーザーや顧客や販売部門からもたらされたものではない
・偉大なプロダクトはデザイナーやエンジニアと連携して、ユーザーや顧客が抱える実際の問題をビジネスのニーズに合う形で解決する
・ユーザー自身が心を奪われる解決策が実現できると思っていなかった

4、真のリーダーシップは偉大なプロダクト開発者とただの良いプロダクト開発者を分ける大きな要素
・偉大なプロダクト開発者を目指すなら恐れずにリーダーシップをとろう

INSPIRED
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P56〜66

◼️Chapter10_2 プロダクトマネージャー(PdM)とプロダクトオーナー(PO)

POとはアジャイル開発チームでプロダクトバックログに責任を持つ人の役割の名前
・製品企業においてPdMが同時にPOであることが欠かせない
・PdMとPOを分けてしまうとビジネスと顧客に対する新しい価値を革新し、絶えず創造する能力が開発チームから失われる
POの責任はPdMの責任の一部に過ぎないため、PdMが兼務することが重要

<PdMに必要な2つの科目>
1、コンピュータプログラミング入門
・HTML以外ならどんな言語でも良い
・エンジニアやデザイナーとより深い話をするためで、また実現技術の力をもっとよく理解できる

2、企業会計、財務入門
・コンピュータ言語と合わせてビジネス言語の習得も必要

INSPIRED
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P67〜69

<②成功するための組織と人の所感>

この本を読み始めるまで、PdMはぼんやり理解していたつもりでしたがそれがPM(Project Manager)のレベルであったと気付くことができました。

ほぼCEOに近い責任を負いながら、部下はなく孤独であり、関係者をうまく調整していく。
ただ違うことは違うとしっかり言わなければならない。

「かなり重い責務だし、ただただ忙しいそう」というのが最初の感想です。
ただプロダクトへの熱意と顧客の課題を誰よりも解決したい熱意、これがあれば、充分にやりがいのある職種だともポジティブに感じました。


この記事が気に入ったらサポートをしてみませんか?