『世界水準のPMの英知はこの1冊で完璧に得られる』←圧倒的な帯
『プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで』を読んだので感想です。最近著者の及川卓也さんらの講演を聞く貴重な機会ができたので、これは事前に読まねば！と早速ポチったのでした。
内容はタイトルそのまま、日本ではPMと言ったらまだまだ「プロジェクト」マネジャーを指すシーンが多いところ、「プロダクト」マネージャーの方に関わる諸々を完全網羅した教科書的な入門書となっています。
- 『世界水準のPMの英知はこの1冊で完璧に得られる』←圧倒的な帯
- ■PART Ⅰ プロダクトの成功
- Chapter 1 プロダクトの成功とは
- Chapter 2 プロダクトマネージャーの役割
- Chapter 3 プロダクトマネージャーの仕事とスキルの全体像
- ■PART Ⅱ プロダクトを育てる
- Chapter 4 プロダクトの4階層
- Chapter 5 プロダクトのCore
- Chapter 6 プロダクトのWhy
- Chapter 7 プロダクトのWhat
- Chapter 8 プロダクトのHow
- ■PART Ⅲ ステークホルダーをまとめ、プロダクトチームを率いる
- Chapter 9 プロダクトマネージャーを取り巻くチーム
- Chapter 10 チームとステークホルダーを率いる
- Chapter 11 チームでプロダクトをつくるためのテクニック
■PART Ⅰ プロダクトの成功
Chapter 1 プロダクトの成功とは
- プロダクトを通して作り出したい未来の世界観のビジョン、ユーザーがそれを使い続けて価値があると感じてもらうこと、事業収益があること。これが成功だと定義して論じる章。
- なぜユーザや顧客がそのプロダクトを使うのか説明できるものが「価値仮説」、これの強力なやつを見つけること→
PMF: Product Market Fit - プロダクトにもステージごとに成功の目標が別だ...として、ベンチャーなどの文脈でよくみる0→1、1→10、10→100の話も出てきます。
Chapter 2 プロダクトマネージャーの役割
- プロダクトを育てること、そしてステークスホルダーをまとめてプロダクトチームを率いることの２つが仕事。
人材採用権や資金調達は単独ではできないが「ミニCEO」である、CEOのようにプロダクトの成功を自分ごととして成し遂げる情熱や強い興味、好奇心を持つ役職である、という解説がアツい。 - 仕事に必要な領域はビジネス、UX、テクノロジーの3つである。
- たとえばあるSNSプロダクトもユーザ価値によって分割できる。イイネ機能とメッセージングなど。このようにプロダクト群の中にプロダクトがあり、小さなプロダクトを新人のPdMがやったりするのもあり。
- 狭義のプロダクトは開発部署だけが作るもの。広義のプロダクトはそこに営業、OR、カスタマーサポート、マーケティングも入る。
- プロジェクトは開始時期と終了時期が定義された活動だが、プロダクトには終了時期がない。プロダクト成長の中の個々のイテレーション的なまとまりがプロジェクトであるように、プロダクトはプロジェクトを内包する概念である。
- チーム全員がプロダクトを愛し、担当領域以外にプロダクト全体の事を考えるのが「プロダクト志向」のチーム。
僕の働いている世界ではPMといったらプロマネなんですが、日本ではプロジェクトマネージャー(マネジメント)がPM、プロダクトマネージャーの方はPdMという呼び方がもう一般化しているかと思います。
欧米ではもうプロダクトマネージャーがデフォルトのPM、プロジェクトマネージャーがJをつけてPJMだそうですね。これは知りませんでした...! (このエントリではプロダクトマネージャーのほうをPdMと書いています)
Chapter 3 プロダクトマネージャーの仕事とスキルの全体像
- プロダクトを網羅的に検討するための4階層として、Core、Why、What、Howの4階層がある。
- プロダクトマネージャーに必要なスキルは発想力、計画力、実行力、仮説検証力、リスク管理力、チーム構築力。
■PART Ⅱ プロダクトを育てる
Chapter 4 プロダクトの4階層
- プロダクトの
Coreはミッションとビジョン、事業戦略。 - プロダクトの
Whyは誰をどんな状態にしたいか、なぜよそでなく自社がするのか。 - ユーザとは別に、その価値にお金を払う人を「顧客」と定義。
- プロダクトの
Whatがそのプロダクトによる解決策。ユーザー体験、ビジネスモデル、ロードマップ - プロダクトの
Howがどう実現するか。ユーザーインターフェース、設計と実装、Go To Marketなど - リリース前にユーザにインタビューを実施して仮説を検証したり。
- 方針の可視化には有名な「リーンキャンバス」を使い、大まかなマイルストーンを決めると良い。
- 心構えとして、仮説が正しかったかの検証が大事。最初から詳細すぎる計画は決めない方がよい。
- 実用最小限の製品である
MVP: Minimum Viable Productを作って検証。 - 新しいアイデアを発想する際には、互いに足を引っ張り合ったり、批判のみに留まったり、自分のしたいことを押し付けたり、結論を急ぎすぎたりしないように。アイデア発想の枠組みはいろいろあり、これらを活用すると良い。
リーンキャンバスなどなど、こうしたプロダクト開発やアジャイルの文脈でよく見るワードも登場します。この４階層を同じチームで最初から考えて開発していったら、なんだかワクワクするだろうな～と思いました。
Chapter 5 プロダクトのCore
- プロダクトの世界観を設定する。ある程度抽象的に、エモーショナルな要素を。本書ではミッションとビジョンのビジョンを世界観とする。
- プロダクトの大切なものランキングを作る。ユーザの継続率やバグ許容、残業時間上限なども。
- 会社に全社戦略があり、その中に個々の事業戦略がある。そのプロダクトが戦うドメインでの勝ち筋を描くこと。
ケーススタディで出版社がBtoCプロダクトを新規に考える例が紹介されており、「人々の可能性を広げる」ミッションで「誰もが活躍できる未来を切り開く」ビジョンをベースに検討が進んでかなり本格的です。
また「大切なものランキング」2位に週の残業8Hまで、6位に週の残業2Hまでがあって、そうかリリース前は月32時間残業位は行くのね……とつい計算してしまいました。
Chapter 6 プロダクトのWhy
- 誰をどんな状態にしたいかで、「バリュー・プロポジションキャンパス(VPC)」というフレームワークあり。四角と丸の図でプロダクトがもたらすバリューと、カスタマーのプロフィールを深掘りしていく。
- なぜ自社がするのかでは、外部環境の分析にPEST分析とファイブフォース分析。自社の強みと弱みの分析にSWOT分析。競合分析にSTP分析。
- ユーザーが困っているペイン、そのプロダクトで解決できるであろうゲインを分析していくには実際のインタビュー。これもテクニックがいろいろあり大事。
- 最後にプロダクトのCoreも含め、Refineしていく。
前章から続くケーススタディが非常にリアルで、ユーザのタイプに合わせたお勧めの本や著者情報をプッシュしていくようなプロダクトができていきそうなのですが、とてもしっかり分析しています。
セグメンテーション、ターゲティング、ポジショニングの３つでSTP分析なのですがこの本自体のポジショニングもちゃんと図で示されていて、深いのではなく広い知識、上級ではなく初学者向けに広くエリアを取った本なのが見て取れます。ちゃんと考えて本を書いているのだなあと思ったり。
Chapter 7 プロダクトのWhat
- ユーザー体験が
UX: User Experience。だいたいUIよりも大きい粒度。週末にオサレカフェで音楽を聴きながらカフェラテを飲む体験自体がUX。点ではなく線で考える。 - ぺルソナを作ってユーザーを知り、ユーザーのゴールを知って分析する。
- プロダクトや体験に関する暗黙の前提を「メンタルモデル」と呼ぶ。
- 時系列に沿ったユーザーの体験をまとめたのが「カスタマージャーニーマップ」。
- 何を作るのかでは「ビジネスモデルキャンパス」で考えていく。
- ユーザインタビューでユーザビリティを確認する時は、5人やるだけで80%の気づきは得られるとのこと。
- その後はロードマップを策定し、リリースまでのマイルストーンを可視化。評価支障としてはKPIとKGIがある。
- プロダクトに特化した指標としては最近
NSM: North Star Metric、「プロダクトのコアとなる価値がユーザーに届いているかを知る単一の指標」。北極星を表す比喩表現から。あのZoomの具体例あり。 - 最後はより抽象度の高い階層、Whyと含めてRefineしていく。
最後のケーススタディではA子さんのペルソナを設定して本節に登場する様々な図を使って検討、サービスのロードマップも決まりリーンキャンバスの図も埋まり、かなりサービスが具体的になってきます。
どうでもいいですが、ペルソナのA子さんが都内アパート独り暮らし大手IT企業プロダクトマネージャー職で、31歳で年収700万なのが高～！と思いました(笑)。プロダクトマネージャーは花形職ですね!!
Chapter 8 プロダクトのHow
- プロダクトに求められる機能や仕組みのリストを「プロダクトバックログ」としてまとめ、ユーザーストーリーマッピングを元に優先度を決めていく。
- 品質基準もPdMが判断していく。
- プロダクトバックログアイテムの見積。ウォーターフォール的な思想ではつい人月単位の絶対見積をしてしまいがちだが、人と切り離してどんなチームで実施するかで変動する相対見積の方がよい。
- チームが一定期間(1スプリント)に実施可能な予測値をベロシティ。
- 見積の総和/ベロシティで期間が出せる。
- 個々のアイテムはストーリーポイント単位で、フィボナッチ数列で数字を出す。
- S・M・Lサイズの３種類で出すやり方もある。
- プロダクトをユーザーに提供する仕組みの諸々をまとめて
GTM: Go To Market。プライバシーと利用規約、価格設定、マーケティングなど。 - リリース時はプロダクトヘルスチェックのダッシュボードを使い、障害に備えると良い。障害時も優先度をP0～P4まで観点を決め、対応するか決めていく。
- 無事リリースしたら全員で祝い、感謝を伝え、正式報告。そしてCoreからHowまでの４階層の仮説検証を見直しながら進めていく。
ケーススタディでは当初予定よりも機能を削って無事サービスがリリースされていきます。ここでスケジュール通りに進行してリリースするより、解像度を上げて再度の仮説検証が反映され、小さい改善していくことを心掛けよ...とあります。
自分もウォーターフォール的な人日や人月の見積はよくするし、スケジュール遵守が第一と考えてしまうので、やっぱりこのへんは根本から考え方を変えないとなあと思いました。
PartIIは実際の企業例にAppleやカメラのコダックやLINE、悪い例として2019年のリクナビDMPフォローの事例も出てきて非常に現実的です。
■PART Ⅲ ステークホルダーをまとめ、プロダクトチームを率いる
Chapter 9 プロダクトマネージャーを取り巻くチーム
- ステークスホルダーとして事業責任者、PMM、CEO。これらとの意思決定を可視化する表で
推進者/承認者/貢献者/報告者でDACIという手法がある。 - プロダクトチーム内では実行責任者/説明責任者/協業先/報告先で可視化する表で
RACIがある。こちらはタスクを完了する責任を持つ人を可視化する。 PMM: Product Marketing Managerでプロダクトの価値に共感するユーザーを探し、プロダクトを届ける役割。マーケティング組織の中にいたり、PdMと並走する。- エンジニアリング組織の健全な成長に責任を持つのがエンジニアリングマネージャー。こちらは機能型組織のマネージャーで、PdMとも協力して当たっていく。
- 大規模なプロダクトになると全体のPdM、その中の機能の個別のPdMを持たせたり。１つの機能の中で、役割で分割して安易に複数人の分業でPdMするのは危険。
- 他者を率いる手段としてあるのが、
信頼/情熱/共感/論理/権力/報酬。このうち権力と報酬はCEOなどが持つもので、PdMは持たない。 - 内発的動機付けが興味や好奇心に基づくもの。外発的動機付けが報酬・地位など。マイナス方向は命令・懲罰。PdMは主に内発的動機付けを意識する。
- PdMが影響力を行使する武器は信頼/情熱/共感/論理。相手の立場に立ち、こちらからの要求を明確にし、相手を理解し、相手が求めるものを満たす形で依頼をすると良い。
リーダーシップの話で「情熱」や「共感」が武器にあります。日本の従来型のお堅いプロマネの本なんかだと出てこないのでこのへんは新鮮です。
Chapter 10 チームとステークホルダーを率いる
- 開発拠点が複数ある時は情報の非対称性が生じないように。
- 可視化にはチャットツールを使ったり、成果物は全員が閲覧できる場所に置いたり、ロードマップも共有したり、KPIも表示したり。
- チームビルディングもPdMの仕事。心理的安全性をはぐくんでいく。認知共有を進め、PdMが自分の弱みを見せるのも厭わず、チームの成長のために中長期的な学習を取り入れる。
- 基本は社内メンバーで内製化だが、どうしてもアウトソースする際は注意。
- DACIの意思決定を明確化。
- ドキュメントのクォリティ。暗黙の前提や社内用語に注意。またどこまで情報を出すかも慎重に。
- 実際の担当者に直接話せない場合はコミュニケーション密度を上げる。
- チームの発展段階には
形成期/混乱期/統一期/機能期/散会期がある。「タックマンモデル」 - 最初はキックオフミーティングをして全体像を共有、チームメンバーが互いを知るようにし、合意を得る。
- プロダクトコンセプトを共有するキックオフでは、アジャイルでよくみる「インセプションデッキ」を作ると良い。
- 開発をどのように進行するかのキックオフも必要。
- チーム共通の目標の指標として
OKRがある。目標のObjectivesと主要結果のKey Results。 - プロジェクトが終了したら振り返りを。
KPTやYWTなど手法が各種。
プロダクト開発のアウトソーシングはお勧めしないとはっきり書いてあるのが素晴らしい。従来型の日本企業はこのへん変わらないとですねえ...
チームやプロダクトに名前を付けるのも愛着が出てお勧めという話でOSの例が載っていて面白いです。Windows OSの開発コードは地名かスキーリゾート縛りなんですねえ。Windows CEはもはや存在自体がマイナーなのでウィスキー縛りとは知らなかった……
Android OSがお菓子の名前、Mac OSが動物なのは有名ですね。正確にはMac OSはネコ科の動物かカリフォルニアの地名のどちらかだそうです。そうかYosemiteだけ地名ですね。
Chapter 11 チームでプロダクトをつくるためのテクニック
- ドキュメンテーションの要素では、プロダクトビジョンステートメント、プロダクト戦略、プロダクトコンセプト、ロードマップ、要件の５つ。プロダクトの4階層と連動している。
- チームメンバーの目標到達のための支援として「コーチング」スキル。相手の言葉を聞く「傾聴」が大事。「リフレクティブリスニング」など
- PdMは業務のコミュニケ―ションの比率が高いのでミーティングを制するのが大事。ファシリテーションスキルを高める。
- 一方、ミーティングはチームメンバの時間を奪う行為でもあるので価値のある使い方を。
- プレゼンテーションも大事。まず練習。プロダクトのストーリーテリングをするとよい。
- 交渉のネゴシエーションスキルも。
よいストーリーテリングの例としてはAppleのWWDCのスライド、Apple Watchの話が例に上げられています。
前半のPART I～IIIがここまで。後半のPART IV～VIまでは次の記事に続きますよ～
