感情タグBEST3
Posted by ブクログ
ロードマップは早めに公開し、関係者を早期に巻き込んでおくこと。
プロダクトマネジメントに必要と思われるあらゆることがまとまっている良書だと思う。ボリューミーすぎて、咀嚼できずにすり抜けていった内容も多いが、プロダクトマネージャー的な立場になったらバイブルとして手元に置いておきたい。しかし、求められるスキルが多くて高いなあ…
Posted by ブクログ
プロダクトマネジメントについてかなり体系化されている。ただやったことない人にとっては、難しいと思うので、ケーススタディだけ読むことをオススメする。
Posted by ブクログ
プロダクトマネージャの仕事内容や心構え、スキルの伸ばし方など広く浅く書かれた本。
プロダクトマネージャを目指す人にとっては、４００ページもある大作ですがバイブルとなる本でしょう。
超お勧め。
書ききれないほど多数のTIPSがあるが、ここではその中の心に深く残ったいくつかだけメモ。
・チームビルディングの一貫としてキックオフ時に何を大切にするチームであるか認識を合わせる
→やらないことを決めたり、機能、品質、締め切り、予算の優先度を決めたり。。。
・値付けに関してはユーザーが本来必要としている以上の機能があったとしても、ユーザーは必要としている機能の価格しか払わない。コスト積み上げ方式による価格は提供者の一方的な論理となってしまい、NG
→ほんまそれ！ コスト積み上げ方式になりがちであるが、どうやってこれを突破するか。。。
辞書的に使うべき本ですね！
今後何度もお世話になります！！
Posted by ブクログ
①キックオフミーティング
ビジョン、Core Why Whatを伝える
コンセプトの理解 インセプションデッキ
チームとのテクニック
ドキュメンテーション
プレゼンテーション
コーチング
ファシリテーション
a.ビジネス
歴史、地理、政治法律、経済、民族文化、哲学思想
統計
知的財産
b.技術
QA 品質を担保するために必要なすべての活動
狩野モデル
API,RPC
c.ux
ユーザーのためのデザインか？
デザインの意図がユーザーの期待通りか？
デザインがもつメッセージは適切か？
ドンノーマンのデザイン6原則
・統一感の4つの観点
美的統一感、機能性、内部性、外部性
ui ビジュアルの階層化
マーケティング
・AIDMA,AISAS
・アーンドメディア、オウンドメディア、ペイドメディア、オーガニックユーザー
Posted by ブクログ
「プロダクトマネージャーは知的総合格闘家」という言葉が刺さる。前職でPMをやっていた際に学んだことがおさらいでき、基本が網羅されている良著だと思う。
プロダクトマネージャーに求められる「計画力」について。ガントチャート作成や、リリースまでのマイルストーンを組み立てることは役割ではない。プロダクトマネージャーに必要なのは、中長期的なロードマップ作成や指標の立案など、プロダクトを着実に成功へ向かわせる力である。
Posted by ブクログ
「ソフトウェアプロダクトラインエンジニアリング」の「製品管理」の実践方法を理解するために読む本。
ケーススタディもあり理解しやすい。
ビジネスプランナーから、職場の便利ツール作成者まで幅広く活用できる知識。
分厚いが、明瞭でさらっと読める。
Posted by ブクログ
プロダクトマネジメントマネジメントとは何か、なぜ必要なのかなどが網羅的に示されている。
駆け出しのCSの人間が読んでもすごくわかりやすい。
経験を積んだら、また読み返したい本。
Posted by ブクログ
タイトルの通り、プロダクトマネジメントについて網羅的に書かれた本。
前半部分はプロダクトを作っていく上での骨組みとなるCore, Why, What, Howの4つの部分をどのように組み立てていき、運用していくかについて使えるフレームワークとともに詳しく説明している。
やはりプロダクトを作っていくということは仮説検証の作業を切り返していくに他ならないというとはとてもうなずけた。
自分も小さなものから少しずつこのような経験を活かして行ければいいなと思っている。
実際にプロダクトを作る機会があったらもう一度読みたい本。
Posted by ブクログ
プロダクトマネジメントを一から解説した本。自分は現在はプロダクトマネージャーという職種ではないと認識しているが、それでもこれを読むと何から何まで力不足に思えてきて酷く落ち込んでしまった。無駄に分厚いわけではなく、それだけの価値はある一冊。あまり職種に執着せずにプロジェクトマネージャーやエンジニアリングマネージャーだとしても読んでみるのが良いと思った。それにしても出来ていない事ばかりだ…
Posted by ブクログ
幅広くプロダクトマネジメントについてまとめられている本。プロダクトマネジメントの全体感がつかめるので最初に読むとよさそう。各フェーズで必要な検討をする際に使えるフレームワークも豊富に紹介されている。自分が担当している案件も今一度本内容に沿って整理したいと思う。
Posted by ブクログ
「すべて」。ずいぶんと思い切ったタイトルだが、そのタイトルで掻き立てられる高い期待値に十分応えてくれる、文字通り「すべて」が書かれた本ではなかろうか。
帯はさらにすごい。「世界水準のPMの英知はこの一冊で完璧に得られる」。でもまあそう言いたくなるのもわかる。
なにが全てか？
まず、要素として「全部入り」といえる。プロダクト自体、そしてプロダクトを作り上げる主体としての組織をも射程に収めている。
そして、解像度が適切だ。「プロダクトマネジメント」ど真ん中の要素は懇切丁寧に解説され、プロダクト開発には必要だが「プロダクトマネジメント」とは距離のあるソフトウェア開発手法などはポイントの解説にとどまっている。
プロダクトマネジメントを生業とするならばこれくらいでよい、逆にこれくらいはおさえておかなければならない、というポイントがよくわかる。
そして、血が通っている。物事を進めていく中で起こりうる問題、立ちはだかる障壁がかなり生生しく紹介されている。「あー、苦労したんだろうな」と共感必至である。
そう、ここで書かれている課題は、プロダクトマネジメントを進める中でぶつかるものなのだ。こうして本に記されているからこそ、我々は覚悟して歩むことができる。
Posted by ブクログ
会社で常に参照できるように買ってもらった。まさかの「だそくん」が真面目に図版として出て来た。まさに「すべて」といえる範囲の広さ。フレームワークを参照したいときに全て書いてある感じ。
Posted by ブクログ
枝葉の知識、スキルは実践しながら経験を積むしかないと思いますが、体系的かつ網羅的に学ぶには良書だと思います。初めてプロダクトマネジメントする方は、本書で形式知、実践して暗黙知を得ることをオススメします。
Posted by ブクログ
辞書的に使える良書。
今後も索引を引きながら要所要所を確認しつつ日々の業務に活かせそう。
プロダクトマネージャーの方には一家に一冊な本ではないだろうか。
Posted by ブクログ
プロダクトマネージャーが把握するべき分野は幅広く、必要とされる知識・見識も膨大。自身はプロダクトマネージャーは未経験だが、イチエンジニアとしてプロダクト開発を進めるに当たって一つ上の視座を得られた気がする。プロダクトマネージャーを経験する機会が来たら改めて読み直したい。
■参考になった点
・ユーザーと顧客の区別
・競合分析の際にWho/What/Howの３つを分析
・DACIとRACI
・アウトソースであっても参加メンバーには同じビジョンやミッションに沿って動くことを求める
Posted by ブクログ
モノ・コトを創るうえで、今どきの叡智を体系的に俯瞰できる本。
これだけ読んでも身につくことは期待出来ない。ただ、俯瞰して自分の知識の再確認にはとてもうまく纏まっている。また、自分がまだ知らない領域を把握するにも勝手が良い。
Posted by ブクログ
これが全部毎回できたら理想だよねと、現状との乖離に諦念も感じたりするけれど、全体的に体系だってよくまとまっている印象ですごく学びになる。定期的に読み返したり、必要なパートを適宜振り返りたい。専門的な詳細が詳しくという本ではないが、網羅的に知ることができるありがたいテキストという感じ。PMになってまだ1年に満たないが、自分なりの目指すPM像に近づけるよう、できることを少しずつ増やしていこうと思えた。
Posted by ブクログ
体系的にまとまっていてよかった、なんちゃら分析みたいな上辺のテクニカルな部分をだけを取り入れるのではなくって、根本部分の思想とか態度を学ぶのが正しい読み方だと思うのだけれど、現場でそういうふうに読まれているかというとそんな気はあまりしない
Posted by ブクログ
体系立ててまとまっているが、深みは無いところも多い。頭から尻尾まで書かれているので量も多い。知らない領域は勉強になるが知ってる領域では新たな知識はつかない。
Posted by ブクログ
まさにプロダクトマネジメントの教科書。網羅的に書かれていてとても勉強になる。一通り読んで後で自分が気になったところを見返し深掘りするというまさに教科書的に使える本だと思う。
Posted by ブクログ
上司に勧められて購入。「プロダクトマネジメント」とは何かを幅広い観点から解説している。わからない言葉があっても基礎知識を解説している章もあるので「まず何を知ればいいかわからない」という人にはおすすめ。ITサービスのプロダクトマネジメントに携わるようになって3年ほどになるが、もっと早くこの本に出会いたかった。
Posted by ブクログ
なんかタイトル負けしていると感じた本。
書いてある内容に否定はないんだけど、ネット記事で読んだなぁという感じも強く、全てと言われると益々という感じ。
プロダクトマネジメントの事を1mmも知らない人が読むといいのかな？それでも、この本だけでは厳しいかもしれないが。
Posted by ブクログ
プロダクトマネージャーの仕事に必要な領域はビジネス、UX、テクノロジーの３つである。ビジネスはプロダクトが市場でユーザーを獲得し、収益を上げることができるかを判断する領域。UXはユーザーが本当に求めているものを発見し、使われる形で提供するための領域。テクノロジーはその実現可能性を判断する領域である。
■プロダクトマネージャーに必要なスキル
・計画力
・実行力
・仮説検証力
・リスク管理力
・チーム構築力
・発想力
■North Star Metric
①NSMの改善がユーザー体験の向上とリンクしている
②ユーザーがプロダクトにどのくらい定着しているかを示す
③NSMを目指すことでx軸に時間、y軸に収益や成長目標を取ったグラフが長期的には右上方向に進む
④収益に結びつくための先行指標である
⑤組織内で理解してもらいやすい
例：Zoom
①音声画像が高品質なビデオ会議をどこよりも簡単に実施できる
②１週間あたりのミーティング数は新規ユーザーや既存ユーザーが増えるに従って大きく増える
③収益KGIを達成するためには有料ユーザーが増えなければならず、１週間あたりのミーティング数が増え続けると、有料ユーザー数も増えることにつながる
④１週間あたりのミーティング数が増えないことにはそもそも収益も増えない
⑤どのようなバックグラウンドの人でもわかりやすい
・NSMを達成するための主要因の例
NSM：会員の総閲覧時間
→ユーザーが記事を読んでくれる／ユーザーが記事を元にアクションする(プッシュ通知への反応、ユーザー間の議論やコメント)／ユーザーを引きつける豊富かつ良質なコンテンツの数
…PMMは一般的にマーケティング部門の中に存在し、プロダクトマネージャーとPMMが協働し、PMMが他のマーケティング部門のメンバーと議論をしてGTMの際の制約条件や考慮すべき点などを織り込む。
■デザイン６原則
①可視性
②フィードバック
③アフォーダンス
④マッピング
⑤制約
⑥統一感
■ビジュアル階層化の５つのポイント
①サイズと色
②近接性
③並び
④繰り返し
⑤コントラスト
ウォーターフォール開発ではプロダクトのCore、Why、Whatをあらかじめ定義してから、プロダクトのHowに取りかかる。一方でアジャイル開発では本書で解説してきたフローと同様にプロダクトのCoreからHowの階層を上下に行き来しながら仮説検証をすることができる。
■プロダクトマネージャーのためのセルフチェックリスト
□プロダクトが目指すべきビジョンをもっているか?
□自社独自の価値がはっきりしているか?
□市場をつくりあげる気概をもっているか?
□ユーザーとの対話の機会をもっているか?
□ユーザーのいっていることから、なぜそれが求められているかを深く考えているか?
□チームメンバーやステークホルダーとの関係に気を配っているか?
□関係者とは調整ではなく、相談・交渉・説得できているか?
□いわれたことであっても、自分が納得したうえで実行しているか?
□Noというべきときは、Noといえているか?
□プロダクトの方向性やターゲットユーザーを考えたうえで、競合を意識しているか?
□ユーザーのニーズに合わせてプロダクトを変容させているか?
□適正価格を見つけることにしかるべき時間をかけているか?
□優先度をつけているか?
□失敗を価値ある学びに変えられているか?
□データを活用しているか?
□直感に頼る前に時間の許す限り調べたか?
□ふりかえりを続けながら磨き上げているか?
□つねに学び続けているか?
2023/2/4追記
9.1 代表的な他の役割との責任分担
一般的にプロダクトマネージャーが所属するチームは2つある。1つはプロダクトマネージャー自身が率いるプロダクトをつくるプロダクトチーム、もう1つはプロダクトマネージャー自身が所属する機能型組織である(図表9-1)。つまり、プロダクトマネージャーは2つのチームとのコミュニケーションが必要になる。Chapter9では前半で、主にコミュニケーションを取る2つのチームメンバーとの役割分担について述べ、後半ではプロダクトマネージャーが所属する機能型組織における複数人のプロダクトマネージャーと分業について解説する。
9.1.1 ステークホルダーとの関係性
プロダクトマネージャーが仕事をするうえで重要なことは、ステークホルダーとの関係性である。プロダクトマネージャーがどの範囲の意思決定ができて、何を誰と相談して決定するのかをはじめに明らかにしておきたい。CEOなどの権限をもっている人から意思決定をする権限を譲り受けることを「権限を委譲される」という。
誰が何の権限をもっているのか、意思決定にどのように関与するのかを可視化するため、DACIという手法がある。決定する事項ごとに、推進者(Driver)、承認者 (Approver)、貢献者(Contributor)、報告先(Informed)の権限を誰がもっているのかをあらかじめ合意をしておくことで、その後のコミュニケーションがスムーズになる。意思決定プロセスを明確にすることで、承認者が不明確な状態なまま進み意思決定が遅くなることや、合議制によって凡庸な結論となること、さらにはステークホルダーによる予期せぬ介入を避けることができる。
図表9-2にDACIの記載例を示す。行に検討事項、列にステークホルダーを記している。ビジョンの策定はプロダクトマネージャーが事業責任者とプロダクトマーケティングマネージャー(PMM)の力を借りながら推進し、CEOに承認をもらうことを意味している。セグメントの選定に関してはCEOの承認を得ずとも、プロダクトマネージャーの権限で意思決定をすることができる。
基本的には1人の担当者は1つの役割に専念するのが鉄則となる。推進者(D)と承認者(A)はできれば別の担当者にし、レビューを得られる体制をつくることが好ましい。しかし実際の現場においては、1人の担当者が複数の役割を担うこともある。
図表9-2ではプロダクトマネージャーが「セグメント選定」にて、推進者(D)と承認者(A)を兼任することとした。とくに小さいチームにおいてはプロダクトマネージャーが自ら推進者(D)として手を動かし承認者(A)として決定をすることもある。
ただやはり、推進者(D)と承認者(A)が同一になることで、推進者以外のチェックがされていない意思決定となるため、重要な意思決定に関しては役割を兼任しないことが望ましい。
9.1.2 プロダクトチームとの関係性
役割の認識を合わせるべき相手は、ステークホルダーだけではない。プロダクトチームのメンバーにも極限を委譲する。チームメンバーの責任分担を明確にするために、RACIという手法が存在する。タスクごとに実行責任者(Responsible)、説明責任者(Accountable)、協業先(Consulted)、報告先(Informed)を決めておく手法である。
DACIは意思決定者を明示するツールであるのに対し、RACIはタスクを完了する責任をもつ人を可視化するためのツールであるといわれる。RACIには2種類の責任者がおり、タスクが完了するまで実行することに責任をもつのが実行責任者(R)、成果物をレビューして外部に対して成果物の説明責任を負うのが説明責任(A)である。基本的に成果物をレビューする説明責任者(A)は1人でなければならないといわれている。
図表9-3にRACIの記載例を示す。プロダクトマネージャーがバックログを作成し、説明責任(A)をもち、エンジニアのリーダーとエンジニアが協業(C)し、QA担当者に報告(I)する。
工数の見積りに関しては、受け取ったバックログを元にエンジニアがQA担当者と協力(C)しながら実行(R)し、その結果をエンジニアのリーダーがレビュー(A)することを表している。
RACIにはいくつもの派生物があり、実行責任者に加えて、実際の作業を行うサポート(Support)を追加したものや、アジャイル開発手法を用いる場合にファシリテーター(Facilitator)を追加したものなどがある。プロダクトや組織に合わせて最適なものを選んでほしい。
RACIを利用してプロダクトチーム内の責任分担を議論したら、プロダクトマネージャーはなぜその人がその権限をもっているのかをチームに説明し、役割が名前だけにならないようにサポートをする必要がある。誰が何を決めることができるのか、何をするときに誰を巻き込まなければいけないのかが明確になっていない組織は拡大しない。説明責任者(A)がいるにもかかわらず、実際にはプロダクトマネージャーがすべての説明責任を負ってしまうことがないように気をつけなければならない。
RACIやDACIを活用してタスク別に責任範囲を明確にすることも必要であるが、人と人との関係性そのものを意識しておくことも重要となる。プロダクトマネージャーはコミュニケーションを取る相手がとても多いため、関係者とのコミュニケーションを戦略的に実施するために、図表9-4のように関係者間の相関を図に表しておくとよい。
関係者間の相関図には自分と相手との現在の関係の強さと、今後の改善の方針を書き込んでおけば、後ほどふりかえるときに役に立つ。たとえば、10段階で相手との関係性を評価し括弧内に今後関係性を強めたい相手にはプラス、もう少し距離を取ってもよい相手にはマイナスの数値を記す。
あまり関係性が構築できていない相手とコミュニケーションを取ることにはハードルを感じるが、数値で可視化すると自らの背中を押す効果もある。可視化を定期的にふりかえりコミュニケーションを評価しておくことで、抜け漏れなくよい関係性を維持しやすくなる。
9.1.3 プロダクトマーケティングマネージャーとの関係性
プロダクトマーケティングマネージャー(PMM)は、ビジョン達成に向けてプロダクトが提案する価値に共感するユーザーを探し、プロダクトを届ける役割である。スタートアップではプロダクトマネージャーがPMMを兼任することもあるが、組織が大きくなると独立したPMMの必要性が増してくる。
図表9-5のようにPMMは一般的にマーケティング部門の中に存在し、プロダクトマネージャーと対等な関係である。マーケティング戦略を組み立てるときにプロダクトマネージャーとPMMが協同し、PMMが他のマーケティング部門のメンバーと議論をしてGTMの際の制約条件や考慮すべき点などを盛り込む。
大きな組織ではプロダクトマネージャーがマーケティング部門の一人ひとりとコミュニケーションしたり議論したりするのは時間がかかってしまうが、PMMが最適なGTM戦略の立案や実行のためにプロダクトマネージャーと伴走する。PMMはマーケットや競合分析を手がけ、PMFを見つける部分を助けたり、プロダクト施策を考察したりする。プロダクトマネージャーはしかるべきユーザー向けによいプロダクトをつくって棚に置くのが仕事であり、PMMはしかるべきユーザーにそのプロダクトを棚から取ってもらうよう仕かけるのが仕事である。
9.1.4 その他の機能型組織のマネージャーとの関係性
プロダクトチームに属するメンバーの機能型組織のマネージャーとの関係構築もプロダクトマネージャーにとっては重要な仕事となる。プロダクトマネージャーと機能型組織のマネージャーでは責任範囲の違いから判断軸が異なることがよく起きる。たとえば、機能型組織のマネージャーであるエンジニアリングマネージャーとプロダクトマネージャーの関係を見てみる。エンジニアリングマネージャーはエンジニアリング組織の健全な成長に責任をもつ存在である。エンジニア個人の成長を促し、組織の創造性と生産性を向上させる。プロダクトマネージャーはプロダクトの成功を追求するため、何か新しい機能を実装するときにもし似た機能の実装経験をもつエンジニアがいれば、これまでの経験を活かして担当してほしいと願うのが当然である。
しかしエンジニアリングマネージャーは、そのエンジニアには別の技術を学ぶ機会を与えたいと思っていることもある。将来のためにエンジニアに新しい技術を習得させることは必要だからである。また、成長の機会が乏しい組織だとエンジニアは魅力を感じず、離職してしまうリスクもある。このように、プロダクトの成功とエンジニアリング組織もしくはエンジニア個人の成長がトレードオフになることがある。プロダクトマネージャーとエンジニアリングマネージャーの利害が対立した場合は、話し合いにより解決することになるため、つね日頃から互いに良好な関係を築いておく必要がある。
機能型組織のマネージャーと良好な関係を築くためには、まずプロダクトキームのメンバーのみならず機能型組織のマネージャーに対しても、プロダクトのビジョンやミッションを含め、プロダクトのCoreを共有する。そのうえで、各メンバーが担う役割も事前に共有することが望ましい。RACIやDACIを用いているならば、それも共有するのがよい。これにより機能型組織のマネージャーは、自分の部下がどのような役割をどのような権限で進めることが期待されているかをより理解できるようになる。
機能型組織のマネージャーもプロダクトマネージャー同等に求められる役割の範囲が広い。大規模な組織では機能型組織のマネージャーが複数のプロダクトを見ることも多いため、プロダクトマネージャーがコミュニケーションを取るべき機能型組織のマネージャーも複数人になることもあり、互いに複数人対複数人の関係になる。プロダクトマネージャーは、つねに機能型組織のマネージャーに自身の担当プロダクトの重要性や優先度を伝え続けなければならない。
また、プロダクトチームのメンバーは必ずしも、そのプロダクトの仕事に100%専念できるとは限らない。その場合、プロダクトマネージャーはそのメンバーが担うことになっている仕事の概要やスケジュールを理解し、もし他の仕事との間で稼働の調整が必要になった場合には、関係するプロダクトマネージャーとそのメンバーの機能型組織におけるマネージャーとの間で解決を図るようにする。
このような調整は多く発生する。理想としては会社全体、機能型組織、プロダクトの優先度が一致していることが望ましいが、同じ成功を見据えていても立場が異なれば乖離が発生することもある。そのため、プロダクトの成功に向けてプロダクトチームのメンバーに期待することを調整する必要が出てくる。プロダクトマネージャーとしては自分の担当するプロダクトを優先してもらうように働きかけることを厭わなくてもよいが、プロダクトのCoreとして担当プロダクトの上位のプロダクトや事業、会社全体の利益を考える視座も必要である。
本当に自分の担当プロダクトを他の仕事よりも優先させるべきと考えるならば、プロダクトマネージャー間で優先順位を決定し、その結果をもとに機能型組織のマネージャーにかけ合ってよい。機能型組織の人数が足りない場合には、そのマネージャーとプロダクトマネージャーチームで議論をして折り合いをつける。ただしその場合にも、その根拠として事業や会社への貢献をしっかりと示す必要がある。職種によっては組織内での希少な人材はチーム間で奪い合いになることもあるだろう。自分のプロダクトさえよければよいという考えは問題外であるが、本当に自分のプロダクトを優先させるべきと考えられる局面においては、きちんとかけ合うことを躊躇してはならない。
プロダクトマネージャーと機能型組織のマネージャーが協力して行っていくべきことに、プロダクトチームメンバーの人事評価が挙げられる。プロダクトマネージャーが担当するプロダクトへの関わりが強く、稼働時間も多いメンバーの場合、そのメンバーの仕事ぶりや成果が一番見えているのはプロダクトマネージャーであることも多い。
プロダクトマネージャーはメンバーの貢献度を人事上の評価者となる機能型組織のマネージャーにも伝える必要がある。時には、プロダクトチームメンバーのパフォーマンス改善を両者で考えなければならないこともある。人事権は機能型組織のマネージャーがもち、人材育成や評価も担うことになるが、日々一緒に仕事をする機会が多いプロダクトマネージャーもメンバーの育成や評価に積極的に関わることが期待される。
9.2 プロダクトマネージャーの組織
9.2.1 プロダクトマネージャーの組織で プロダクトを分担する
PARTⅠで述べた通り、プロダクト志向をチーム全員がプロダクトを自分ごととして捉え、プロダクトをよくしていくことにこだわり抜くことだと定義した。プロダクト志向チームが機能していれば、企業規模の違いによってプロダクトマネージャーに求められることに大きな違いはない。最大の違いはプロダクトマネージャーの人数と、それによるスコープの大小である。
プロダクトは複数に分割をしたり、複数のプロダクトを1つのプロダクトとして扱ったりすることができる。小さい企業の場合、プロダクトマネージャー1人もしくは少人数であることも多い。1人のプロダクトマネージャーの担当する。スコープが広く、意思決定は1人もしくは数人(2～3人)で行う。範囲も広く、幅広いスキルが求められる。
社内に十分なリソースがなく、デザイナーやデータサイエンティストがいないなどプロダクトチームが不完全な場合もある。採用したくてもすぐにできるわけではないので、プロダクトマネージャーが職務を越えて、必要ならばその役を積極的に埋めていく必要がある。
創業間もないスタートアップの場合は創業者や創業メンバーが最初のプロダクトマネージャーであることも多い。そのあとを引き継ぐときには、彼らの意思決定プロセスを踏襲しながらも、たとえばプロダクトマネージャーがプロダクトに関する一部の意思決定を担うなど、創業者の負担を減らすことが求められることもある。プロダクトが大きくなり、関係するプロダクトや組織が増えてくると１人のプロダクトマネージャーがすべてを担当することが現実的でなくなる。そのため、プロダクトを分割し、複数のプロダクトマネージャーで協業する体制をつくる必要がある。
図表9-6のようにSNSのプロダクト群はSNS、メッセンジャー、および友達管理やユーザー設定として利用される共通基盤の大きく3つのプロダクトに分割することができる。このように分割する場合、少なくとも3人のプロダクトマネスージャーを置くことになる。プロダクトの成熟度やユーザー規模によっては、3つのプロダクトをより細分化して、100人以上のプロダクトマネージャーがプロダクトに関わっていることも珍しくない。
このような大規模なプロダクトである場合、プロダクト群全体のプロダクトマネージャーは1人ないしは少数人で担当し、プロダクト群全体の大きな方向性を決める。たとえば投稿機能やチャット機能といった個別の機能はプロダクト のプロダクトマネージャーではなく、別のプロダクトマネージャーが担当する。
このようにしてプロダクトマネジメントの組織ができあがり、1つのプロダクトであっても複数人で担当することができる。プロダクトチームに参加する人や役割も増え、それぞれが自分たちの報告経路をもつ。こうした中で複数人が担当しても意思決定の軸がずれないようにする必要がある。人が足りない場合は他部署と交渉して必要な期間、必要なだけの人員を用意するために調整が必要となる。人数が増えたことによる意思決定スピードの鈍化を避けるようにする、人が増えたことによる不要な雑務が増える状態をつくらないようにする、不要な仕事やプロセスは排除しミーティングばかりしないようにする、といったことに注意をして組織が大きくなったことの弊害が生まれないようにすることが大切である。
(1) 安易に役割で分割してはならない
1つのプロダクトに複数人のプロダクトマネージャーがいる場合、ビジネスに強い人や技術に強い人などさまざまな強みや弱みをもつ人がいるだろう。ロボティクスやセンサーなどを活用するプロダクトではハードウェアまで含めた技術領城の知識が求められ、医療や物流、建設、金融などその業界独自の知識が必要である。そのため、1人の担当者ですべてに通じることは難しい。そこで1つのプロダクトに対して、ビジネスに強い人と技術に強い人の2人のプロダクトマネージャーを置くこともある。
しかし、安易に複数人の分業体制を取ることはプロダクトの方向性に一貫性をもたせられなくなったり、プロダクトのさまざまな局面における迅速な意思決定が行えなかったり、リスクを取った大胆な施策が取れなくなる危険性がある。プロダクトの意志決定をするプロダクトマネージャーは必ず1人に定め、他のメンバーはサポート役(RACIのConsult＝協業先)に徹するべきである。
(2) プロダクトマネージャー間の責任範囲を明確化する
プロダクトマネージャー同士の責任範囲についてもDACIを用いて互いの責任範囲を明確にすることが重要である。しかし実際には、明確にプロダクトマネージャー間での仕事の境界が分割できないことがある。互いに境界の認識が合っていると思っていても、実は境界にあたるところを互いに相手が担当すると思ってることもある。境界が曖昧な領域があることを前提として、積極的に曖昧な領域の整理をするとよい。
そのために必要なのは情報共有である。とくに議題がなくてもプロダクトマネージャーで集まったり、lonlをしたりするのも一案である。もちろん忙しいプロダクトマネージャーにとって目的のないミーティングは避けたほうがよいので、たとえば週に一度ランチを一緒に取ることなどが考えられる。
また、大きなビジョンを実現するためには、複数のプロダクトマネージャーが自分の担当領域での成果を積み上げていくことも必要になってくる。大きなプロダクトやプロダクト群のビジョンに対して、各プロダクトマネージャーが自分の担当領域を通じてどのように貢献するかを可視化して、その達成を互いに喜ぶことができる関係構築も欠かせない。
(3) 意思決定のフローやドキュメントのルールを共通化する
プロダクトマネージャーが複数人いる場合、プロダクトを考える方法やプロダクトマネージャーの仕事の範囲の認識が違うことが起こりうる。もちろん、プロダクトマネージャーの強みに合わせて仕事の範囲を割りふるのはよいが、その前提となる意思決定のフローや、プロダクトチームとしてのドキュメント管理のルールなどは揃えておくとよい。
隣のプロダクトのことはまったく知らないといった状況にはせず、互いにプロダクトを成長させるためのツールやフローについても議論を重ねることができる関係が好ましい。
Posted by ブクログ
範囲を拡げ過ぎて総花的で表層的で焦点が不明瞭になっている。結果フレームワークとコンセプト紹介がただただ400ページ続いているようになっている。パーツパーツでは有益な情報が豊富なのでWhyとHowのプロダクトマネジメントに絞ってページ数をコンパクトにしたほうが良かった気がする。PMを志す人の指南書に成りえるポテンシャルがあっただけに残念。プロダクトマネージャーになりたい人にはお勧めしにくいがビジネスの読み物としては面白い。
