プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド

はじめに

なぜ本書を書いたのか？：プロダクトマネージャーとしての初日

プロダクトマネージャーとして初日を迎えるにあたって、私はこれ以上はできないと思うくらい準備を重ねてきたつもりでした。ユーザー体験の基本原則を予習し、プログラミングスキルを磨き、ソフトウェア開発の方法論を学ぶなど、熱心に取り組んできました。アジャイル開発宣言を暗記し、MVPや漸進的な開発といった言葉をいつもの会話のなかで使えるようになっていました。新しい職場の上司はプロダクトマネージャーではありませんでしたが、プロダクトマネージャーと一緒に働いた経験がたくさんあり、プロダクトマネージャーがどんな人たちなのかを知っていました。自席の片づけを終えて、その上司に、付け焼き刃で大量の本を読破した若者らしく、鼻息荒く話しかけました。

「この仕事にガッツリ取り組めることにワクワクしているんです。最新版のプロダクトロードマップはどこにありますか？ 四半期のゴールとKPIは何ですか？ ユーザーニーズをより深く理解したくなったら誰と話したらよいですか？」

彼は疲れた顔で「君は賢いんだから」と大きく息をつき、「自分で考えてください」と言いました。

これは望んだ回答からはかけ離れたものでしたが、プロダクトマネジメントについて重要なことを教えてくれました。実際の現場でアドバイスをもらうのは非常に難しい、ということです。ありとあらゆる本を読み、ありとあらゆる「ベストプラクティス」を学んだのに、デスクに戻って感じたのは「いったい一日何をしたらいいんだ？」でした。ロードマップがなかったら、どうやってロードマップを管理すればいいのでしょうか？ プロダクト開発のプロセスがなかったら、どうやってプロセスを監督すればいいのでしょうか？

キャリアの初期には、この多くは開発ペースが速く職務定義が緩いせいで起きることで、スタートアップで働くのにはつきものだと思っていました。でも、さまざまな規模や種類の組織にコンサルティングやトレーニングを提供するようになって、同じようなパターンを目にしました。プロセス重視のエンタープライズ企業であっても、プロダクトマネジメントの実際の仕事は、合間時間や陰で行われているようでした。プロダクトのアイデアは、計画会議ではなくコーヒーブレイク中にさかんに議論されていました。厳格に規定された大規模アジャイルフレームワークは、抜け目ない政治で骨抜きにされていました。整ったフレームワークとプロセスより、雑多な人間同士のコミュニケーションが支配的でした。そして、私がプロダクトマネージャーの初日に感じた疑問は、組織の大小、最先端のスタートアップか動きの遅いエンタープライズ企業、新任か経験豊富かに関係なく、どんなプロダクトマネージャーでも、いまだに誰もが一度は抱くものでした。 ...