TL;DR
- プロダクトマネージャーという肩書きに権威があるわけでは無い
- 仕事は他の人の助けをもってこそ達成できる
- 失敗を回避する事はできない、失敗から学び成長する
はじめに
本書はプロダクトマネジメントの基礎、戦略立案、ロードマッピング、リーダーシップ、ステークホルダーとのコミュニケーションなど、幅広いトピックを網羅しています。
各章にはまとめとチェックリストが用意されており、自分の達成項目を確認するためにも役立ちます。
目次
- 1章 プロダクトマネジメントの実践
- 2章 プロダクトマネジメントのCOREスキル
- 3章 好奇心をあらわにする
- 4章 過剰コミュニケーションの技術
- 5章 シニアステークホルダーと働く（ポーカーゲームをする）
- 6章 ユーザーに話しかける（あるいは「ポーカーって何？」）
- 7章 「ベストプラクティス」のワーストなところ
- 8章 アジャイルについての素晴らしくも残念な真実
- 9章 ドキュメントは無限に時間を浪費する（そう、ロードマップもドキュメント）
- 10章 ビジョン、ミッション、達成目標、戦略を始めとしたイケてる言葉たち
- 11章 「データ、舵を取れ！」
- 12章 優先順位づけ：すべてのよりどころ
- 13章 おうちでやってみよう：リモートワークの試練と困難
- 14章 プロダクトマネージャーのなかのマネージャー（プロダクトリーダーシップ編）
- 15章 良いときと悪いとき
- 16章 どんなことでも
1章 プロダクトマネジメントの実践
プロダクトマネージャーとして週に60時間も働いてはいけない
長時間労働しているプロダクトマネージャーを多く見てきたので予想外な一文でした。
チームが目標を達成できるようにタスクを優先付けすることが重要であり、労働時間はやはり短い方がいいのですね。
組織やチームごとに千差万別です。
プロダクトマネージャーという職種には固定の定義がなく、組織によって求められる役割が変わるということを認識することが大切です。
多くの異なる役割がありますが、どれも柔軟性が必要とされています。
2章 プロダクトマネジメントのCOREスキル
What, exactly, is a Product Manager? が有名のようですが、
この問いに対する答えはこの図だけで表現することはできません。この章ではコミュニケーション、組織化、リサーチ、実行の重要性に焦点を当てています。
www.mindtheproduct.com
3章 好奇心をあらわにする
プロダクトの失敗と個人的な失敗は分ける
というケーススタディがとても印象的でした。読み進める中で、何度もうなずいてしまいました。
4章 過剰コミュニケーションの技術
そこには「あのさ、新しいiPhoneアプリのApp Storeへの申請を今晩中にできる？」とありました。
混乱しました。緊急指示ってこと？ 優先度は高くないただのちょっとしたお願い？ 今すぐやってほしいってこと？”
上司からの急な指示は多くの人が悩むポイントではないでしょうか。
この章では、プロダクトマネジメントの分野における伝え方の重要性を端的に示しています。
プロダクトマネジメントでいちばん危険な言葉：「よさそう」
LGTMの時も言ってしまう「よさそう」ですが、
エンジニアリングマネージャーやプロダクトマネージャー（EMやPdM）を目指す人々にとっては、このような曖昧な表現は避けるべきです。
なぜなら、それはしばしば不確実性を招き、チームメンバー間の誤解を生む可能性があるからです。
5章 シニアステークホルダーと働く（ポーカーゲームをする）
ステークホルダーとの関係を保ちつつ、ユーザー主義を貫く事が主軸に書かれています。
いくつかのシナリオを想定したpros/consが登場するので、今の仕事ですぐに活用できるケースを見つける事ができるでしょう。
6章 ユーザーに話しかける（あるいは「ポーカーって何？」）
ステークホルダーとユーザーは違う
ハッとしました。チームによってはステークホルダーという単語の範囲にバラツキがある場合が多いので、ハッキリ認識合わせをするべき一文だと感じました。
また、ユーザーペルソナの落とし穴について書かれており、仕様を検討する上で重要な事がまとめられています。
7章 「ベストプラクティス」のワーストなところ
誇張を鵜呑みにしない
多くの場合、何かの登壇や技術ブログで発信される情報はとても耳障りの良い内容が多いです。
その情報を鵜呑みにするのではなく、発表している組織が作ったものを実際に触る事が真実に近いでしょう。
8章 アジャイルについての素晴らしくも残念な真実
ウォーターフォールからアジャイルに変わるときの期待値を設定する
上記のケーススタディは意思決定と会話する上で大事な要素に見えます。
多くのWeb系企業ではアジャイルを導入していますが、デッドラインももちろん存在する為、バランスが難しいと感じています。
この難しさについては、2011年10月8日にのスクウェア・エニックスCTO 橋本 善久 さんが公開されているPDFがとても勉強になりました。
ゲーム開発 プロジェクトマネジメント講座
ゲーム開発 プロジェクトマネジメント講座 141ページ
9章 ドキュメントは無限に時間を浪費する（そう、ロードマップもドキュメント）
私はPdMではありませんが、それでもドキュメントの作成・メンテに無限に時間を浪費した経験があります。
例えば、1年くらい殆どExcelやPowerPointやMiroしか触っていなかったんじゃないか？と感じる時期さえありました。
ドキュメントを完璧にする事を目指すのではなく、短い時間でぱぱっと書いていまう、それを繰り返す方が良いということです。
メニューは食事ではない
という言葉がまさにそれを表現していました。
10章 ビジョン、ミッション、達成目標、戦略を始めとしたイケてる言葉たち
この点については企業毎の特色が強くでるので難しいのですが、
優れた戦略はシンプルで明快だ
という一文に強く頷き、過去に経験した目標設定を少し振り返ってみました。
マトリクスでちょっと複雑な目標管理をしている現場などもありましたし、OKRとMBOを混在させて税制並の難解さをだしている現場もありました。
ただ、私が最も脳をクリアに目標を意識しつつ働けたのは、30名程度のスタートアップでゴールが明確な時だった事を思い出しました。
個人的にはOKRを用いた目標設定が好みです。
www.kaonavi.jp
11章 「データ、舵を取れ！」
データという概念の難しさと、データドリブンに基づいたプロダクトマネジメントの使いどろこについて説明しています。
データドリブンに全てを委ねることなく、優先順位や意思決定は変わらずに必要だという事がわかりました。
12章 優先順位づけ：すべてのよりどころ
会社のゴール、戦略、チームのゴール、プロダクトビジョン…etc
様々な観点での意思決定が必要である事が語られています。
手短に言えば、ベストを尽くすのです
この一文にある通り、一箇所をみていれば良いわけではないし、意思決定は常にトレードオフだと表現されています。
但し、過去に私が学んだ事として、意思決定は全てを見通した上で行われるわけではありません。
その時点での情報を元に最適にみえる解を出す事は十分に意思決定であり、将来振り返ってみて失敗だったとしてもそれはある程度仕方のない事です。
マネジメントに関わる人は、ある時点で過去の意思決定が失敗だと思ったとしても、当時の情報で十分に検討した結果であれば、それについてあまり悔やみすぎる必要はないと私は思っています。
13章 おうちでやってみよう：リモートワークの試練と困難
同期・非同期のコミュニケーションをいかに活用していくかについて勉強になりました。
準備と練習には3倍かける
同期コミュニケーションによる価値のある時間を作るためには、その3倍の時間をかけて用意する必要があると説かれています。
これは本当にその通りで、ラバーダッキング法を用いて自分のアイデアを反芻するのが大事になるでしょう。
https://ja.m.wikipedia.org/wiki/ラバーダック・デバッグ/ja.m.wikipedia.org
14章 プロダクトマネージャーのなかのマネージャー（プロダクトリーダーシップ編）
幹部に反射的に「はい」と応えることがいかにチームを壊滅させ、あなたを昇進させるか！
この章では、ケーススタディがいくつかありますが、そこに全てが詰まっています。
15章 良いときと悪いとき
キャリアにおいては、「良いとき」と「悪いとき」が入り混じってぼやけて、グレーな「大丈夫なとき」に見えることが何度もあるでしょう。
中には常に「良いとき」を過ごしているように見える人もいますが、そんな事はありません。
どんな人でもアップダウンがあり、モヤモヤしている時があるのだと思います。
16章 どんなことでも
プロダクトマネージャーを続けていく事で貴方自身も成長します。
失敗はつきものであり、恐れるのではなくそこから学ぶ必要がある事が締として書かれています。
おわりに
リーダーやEMにフォーカスした内容を求めている方は下記の一冊もオススメです。
簡単な差分を紹介すると下記の通りです。
- プロダクトマネージャーのしごと
- 製品の全体像と市場、チームの成功、ロードマップ作成や機能定義...etc
- エンジニアリングマネージャーのしごと
- 技術チームの効率と製品の技術的や、チームメンバーのキャリア成長とモチベーション維持...etc
