プロダクトマネジメントの良書「INSPIRED」からの学び[読書メモ]
昨年末、PM(プロダクトマネジメント)について学び直そうとして手にした本がこちら。
なるほど祭りでした。
ハイライト(マーカーで線引く)したとこに絞って読み返したら、またも学びが多かったのでnoteにしてみます。
作るのが大変だからこそ
私は心に誓った。ユーザーや顧客の求める製品であるとわからないかぎり、二度とあんなに必死になって仕事をしない。
なんかもう、この一文に詰まってるなと。
PMの重要な介在価値のひとつは「つくる価値があるかを見定めること」だと言えそうです。
完璧なアイディアなんて生まれない
第1の真実は、少なくとも私たちのアイデアの半分はうまくいかないということだ。あるアイデアがうまくいかないのには多くの理由がある。最もよくあるのは、顧客が私たちほどそのアイデアに心を躍らせないことだ。
(中略)
第2の不都合な真実が待っている。可能性があることが証明されたアイデアでさえ、ビジネス上必要な価値を持つところまで実装を進めるには、通常いくつかのイテレーションが必要だということだ。
つい良いアイディアがうかぶと、全てうまくいくと思ってしまうし、思いたくなる。
でもそのうちの半分はロクでもないし、一発ですんなり実装できんぞという話。
戒めねば…。
馴染みのあるスケジュールの立て方に
大きな落とし穴があった
古いウォーターフォールプロセスの最大の欠点は、今も昔もすべてのリスクが最後に来る点である。つまり顧客実証がおこなわれるのが遅すぎるのだ。
通常というか、まだ広く市民権をもつスケジュールの立て方は「企画→デザイン→開発→検証→リリース→ユーザーテスト」といったウォーターフォールプロセス型。(ウォーターフォール = 滝)
もっと早い段階でモックアップなどをつかって顧客にヒアリングして反応を伺うと、もしかすると塩反応に早く気づけるよという話。
PMは学ぶべきことが
すごくとてもたくさん多い(語彙力)
まとめると、あなたが開発チームにもたらさなければならない重要なことは4つある。
(1)顧客に関する深い知識
(2)データに関する深い知識
(3)自分たちのビジネスとステークホルダーに関する深い知識
(4)市場と業界に関する深い知識
う、うそぉ…。
😇
ついアウトプット(成果物)に目が行きがちだけど
本書の重要なテーマの1つは、アウトプットではなくアウトカムに焦点を当てることだ。よくある製品開発ロードマップはアウトプットに関するものであることに注意してほしい。しかし、優れたチームに求められるのは業績を出すこと。
ロードマップを書いていると、たしかに「こんな機能を作ります」といったアウトプット(成果物)について言及しがち。
だけど、結局アウトプットは手段であってどんな業績や効果(アウトカム)を生み出せるかが大事だという話。
実に、耳が痛い。
競合を意識してしまうけど
ライバルではなく、顧客のことだけを考える。
あまりにも多くの企業が、手ごわいライバルに〜(以下略)
競合がたくさん溢れる時期もあるだろうけど、顧客のことを一番考えてる製品が長い目で見れば選ばれるから、バタついたらあかんぞ、と。
この話がとても好きです。
PMは4つのリスクに目を見張る
・顧客はこれを買ったり、これを使うことを選んでくれるだろうか?(価値のリスク)
・ユーザーはこれの使い方がわかるだろうか?(ユーザビリティーのリスク)
・私たちはこれを作れるだろうか?(実現可能性のリスク)
・このソリューションは私たちのビジネスに貢献するだろうか?(事業実現性のリスク)
いろんな検討事項がPMの頭の中にうずまきがちだけど、特にこの4つの問いが大事なんだという筆者の言葉が、頭の中をシンプルにしてくれます。
***
ここに書かれていることは、なるほどと思えることばかりだったと同時に「言うは易く行うは難し」なことばかりでした。
まずは、4つのリスクを忘れず意識することから始めてみます。
(うー、はやくSmartHRのPMとして活躍したい…)
おわり
サポートいただけたら、嬉しくて本屋に行くと思います・・・笑