オススメ度 ★★★★☆ ４／５
すぐれた製品の背後には必ず製品開発チームを率いて、顧客の抱える課題を解決する人間がいる、という著者の持つ信念をもとに、プロダクトマネジメントという役割について語る。
僕自身はデザイナーであるが、比較的プロダクトマネジメントという役割に近い位置におり、プロダクトマネジメントという役割を詳しく知ることはキャリアにおいてプラスになると考えて本書にたどりついた。
まず、序盤では、ロードマップを作って製品を開発する方法を「製品開発が失敗する方法」として否定しており、リーンやアジャイル型の開発を推奨している。しかし、多くの開発チームがリーンやアジャイルの考え方を十分に活かしきれていないとしている。
2.製品の定義とデザインは、順を追ってではなく、協調させながら同時に実行される。
3.大切なのは機能を実装することではなく、問題解決をすることである。
ロードマップのデメリットは、開発チームの目を機能の実装に向けさせてしまう点がよくないのだという。本書では、ロードマップに変わるものとして、
ビジネスの目標
を挙げている。
本書を読んで知ったのは、プロダクトマネージャーが備えなければならない知識の多さ、そして注意しなければならない領域の広さである。本書ではプロダクトマネージャーが備えるべき資質・知識として
・データに関する深い知識
・自分のビジネスについての深い知識
・市場と業界についての深い知識
・頭が良く、創造的で、粘り強いこと
を挙げている。
中盤では、成功するためのプロセスとして、目標管理のためのOKRや、製品発見のための、プロトタイプやユーザーインタビューなどを説明している、それぞれが単独で一冊の本になりそうな分野を非常にコンパクトにまとまっていて、全体を網羅的に知りたい人にはちょうどいいのではないだろうか。
すぐに取り入れたいとおもった手法は、製品開発チームに顧客の利益に集中させる方法として書かれている。ワーキングバックワードプロセスと呼ばれるもので、架空のプレスリリースを考えるというものである。プレスリリースとして人々の注目を集めるためには、その製品がどのように顧客の生活を向上するかを簡潔に伝えなければならない。ワーキングバックワードプロセスとは、架空のプレスリリースを作って、製品開発チームに実現したいことを共通認識させるためのものである。同様の目的としてカスタマーレターという手法も紹介しているが、どちらも、目的が曖昧になったり、機能実装だけにフォーカスして、解決すべき課題を忘れがちな開発プロセスにおいて、明日からぜひとりいれたいと思った。
各章の間に挟まれているプロダクトマネージャーの物語として、AppleのiTunesやAdobeのCreative Cloudを率いた話も面白かった。
全体的に、翻訳がわかりにくくて読みにくい部分はあったが、プロダクトマネジメントについて包括的に説明している良書といえるだろう。機会があれば繰り返し読んでしっかり内容を理解したいと思った。