「プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける」を読んだ
「プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける」を読んだので感想を書きます。
https://www.oreilly.co.jp/books/9784873119250/
プロダクトマネジメント
どんな本?
原題の「Escaping the Build Trap」の通り、いかにビルドトラップを避けるかについて書かれた本です。ビルドトラップが何かについては冒頭で、
ビルドトラップとは、組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況のことです。実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状況です。
と説明されています。
ビルドトラップを避けて顧客に価値を提供できるプロダクトを作るために、
- プロダクトマネージャーとはどうあるべきか?(第二部)
- どう戦略を設定するか?(第三部)
- どうやって顧客の問題を解決するか?(第四部)
- 組織はどうあるべきか?(第五部)
を順に解説しています。
気になった点
ビルドトラップという単語
この本といえばやはりこの単語でしょう。 リリースすることが目的になってしまっている状態や、顧客の抱える問題を理解する前にソリューションを考えてしまう状態を「ビルドトラップ」という一言で表せるようになったことは大きいと思います。
プロダクトマネージャーはミニCEOではない
よく「プロダクトマネージャーはミニCEOである」という説明がされているのを目にしますが、この本では明確にそれを否定していてちょっと意外でした。 プロダクトマネージャーはCEOほど多くの権限を持たないことに加え、どうプロダクトを作るか指示するのではなく「なぜ」それを作るのかの方向性を伝える役割だからのようです。
スクラム(厳密にはプロダクトオーナー )への批判
スクラムガイドで定義されているプロダクトオーナーの責任がプロダクトバックログの管理に終始していることに触れた後、以下のように書いています。
このようなプロダクトマネジメントのバックグラウンドがなくても、スクラムにおけるプロダクトオーナーの役割として動くことはできるかもしれません。しかし、適切なものを作っているかどうかを確認することはできません。
また、Scaled Agile Framework (SAFe)も批判しています。 SAFeにおけるプロダクトオーナーはプロダクトマネージャー(SAFeではプロダクトマネージャーはプロダクトオーナーのマネージャー)から渡されたバックログアイテムを開発するだけで、顧客の問題をよく理解しておらず、効果的なソリューションを作ることはできないと述べています。
確かにスクラムガイドには役割としてどう振る舞うかしか書かれておらず、定義された役割のみをこなしていればプロダクトがうまくいくというわけではないため、ちゃんとプロダクトマネジメントも学ぶべきだということかなと受け取りました。
戦略を策定・展開する
良い戦略とは計画のことではありません。戦略とは意思決定を下すのに役立つフレームワークのことです。
組織のリーダー層は何を作るべきか事細かに指示するのではなく、 組織のレイヤーごとに戦略(ビジョン・戦略的意図・プロダクトイニシアティブ)を展開し、それぞれをアラインメントすることで目指す方向性を合わせるべきだと述べています。
実際どうプロダクト開発を進めていくかを議論していると人によって目指す方向がバラバラなことはよくあるので、 そういった場合は組織レベルの戦略(ビジョン・戦略的意図)に立ち返ってプロダクトの戦略(プロダクトイニシアティブ)を決めるとよいのかなと思いました。
プロダクトのカタ
プロダクトのカタとは作るべき適切なソリューションを明らかにするプロセスのことです。
プロダクトのカタに沿っていくつかの質問について考えることで、顧客の抱える問題がわかっていない、ソリューションの良いアイデアが既にあるのに不要な実験をしてしまうことを防ぐことができます。 プロダクトのカタは今後実践していきたいと思いました。
最後に
プロダクトマネジメントに関する本を読んだのは初めてでしたが、簡潔かつ端的に書かれているので非常に読みやすかったです。 プロダクトマネージャーとして働いている人だけでなく、何らかの形でプロダクトに関わっている人であれば是非とも読んでもらいたいと思いました。