はじめに

皆さん、「プロダクトマネージャーのしごと」読みましたか？（唐突）

Amazon で入荷待ちになっていたり、X（Twitter）でもちょっと話題になっていたり。
この記事では、エンジニア（私）が読んでみた感想を思うままに書いていこうと思います。

読もうと思ったきっかけとしては、話題になっているというものもありましたが、
下記の理由から読み始めました。

キャリアの方向性として PdM に近い部分を目指したいと思っている
エンジニアとして今の会社でしか働いたことがないので社外のことも知りたい

先に結論を言うと、「プロダクトマネージャーの仕事は結局分からん」 です。
が、学びはたくさんあったので、そちらを記載できればと思います。
※全ての章を書くと膨大になるので特に個人的に印象に残った部分に焦点を当てています。

プロダクトマネージャーに必要な「CORE」スキル

読んでいくうちに、職種問わず身につけておいても良いのではと思いましたが
プロダクトマネージャーの職種柄上、特に重要だと思われるスキルです。

CORE スキルとは？

Communication：ステークホルダーとコミュニケーションをする
Organize：持続的に成功するチームを組織化する
Research：プロダクトのユーザーのニーズとゴールをリサーチする
Execute：プロダクトチームがゴールに到達するための日々のタスクを実行する

それぞれについて解説していきます。

Communication

行動指針は、心地よさよりも明確さ。
様々なステークホルダーと関わるプロダクトマネージャーだからこそ、より求められるのかなと。
ダメな例としてあがっていたのが、「何となく良さそう」、
イケてる言葉や印象的な発言をすること。

やらない理由、やる理由、どこを目指しているのかなどをステークホルダーに
いい感じに伝えるのではなく、明確に伝える必要、責任がプロダクトマネージャーにはあります。
もちろん時には心地悪い会話も必要で、
それこそが認識のズレを発見し改善するチャンスになるとのことでした。

Organize

行動指針は、自らを不要とせよ。
戦略だけでなく、実行まで行うプロダクトマネージャーだからこそ
個人の努力を評価されるようにではなく、自分自身が不要になるような組織化が必要です。

「もし 1 ヶ月自分が休暇をとってもチームは滞ることがないか？」
「今何をしているのか？それはなぜ？」とチームメンバー全員に聞いて、その回答に一貫性があるか

など自分自身へ問いかけることで評価を行います。

Research

行動指針は、ユーザーの現実に生きよ。
プロジェクトの納期を守ること、損益計算書の計算をすること、バックログの管理などは、
会社やプロダクトマネージャーにとっては重要なことでも、ユーザーには全く重要ではないです。
ユーザーとプロダクトがどのように適合しているのかを知ること、
その現実世界に生きることで、やるべきことの道筋が見えてきます。

Execute

行動指針は、すべてはの努力は、アウトカムのために。
チームが届ける責任の持つアウトカム全てに優先順位をつけ、実行責任を持つこと。
自分がやるほどじゃない仕事、自分がやるには難しすぎる仕事などはなく、
組織やチームが成功する助けになることなら何でもやる意思を持つこと。

ハードスキルについて

CORE スキルはソフトスキルについて言及されていましたが、
ここではハードスキルについて。
プロダクトマネージャーは、エンジニアやデザイナーなどの技術者の知見があった方がいいのか？
という質問への 1 つの回答にはなるのかなと思います。

結論、技術面でエキスパートになることが重要ではなく、
技術について探索や学ぶことに抵抗感がないことが重要とのことでした。

本書の中では、
「自分はエンジニアではないので、そういうのは分からない」と言わないでください。
とあり、好奇心が解決?のための 1 つの鍵になっていました。
守りの姿勢に入らず、好奇心を広げること。
エンジニアやデザイナーと一緒に働いているのであれば
その人たちの仕事に興味を持つこと、そこからがスタートになりそうです。

こういった点では、エンジニアやデザイナーからプロダクトマネージャーになった方は
比較的興味を持ちやすいのかなと思いました。

魔法にとびつかない

複数の章に渡って、印象に残っていたのがこちら。
ロードマップ、ペルソナ、ドキュメントなどが完成したとしても、
その時点でプロダクトに変化はないこと。
これらを完成させることに、時間や労力を費やすのではなく、
あくまでもコミュニケーションの手段として、
スピード感を持って進めていく方がプロダクトに変化は起こります。
だからこそ、小さく始めて改善していくこと。
本書の中では「ペライチ（紙 1 枚）」からが推奨されていました。

ベストプラクティスやフレームワークは、そのまま実行したら上手くいくものではないので、
有用なフィクションとして、自分に役に立つ部分だけ使っていくこと。

終わりに（感想）

「プロダクトマネージャーの仕事は結局分からん」

結局どの部分を担うのか、何をするのかは会社ごとに変わってくるのと、
やるべき各仕事には正解がなく曖昧さが残るものが多いので、
これがプロダクトマネージャーの仕事だというのは難しいということだという結論です。
ただあえて上げるとすると、「何でもやる」。
これがプロダクトマネージャーなのかなと。

加えて、書籍で書かれていたのは、
権限も権威もないこと、
他の人の助けがなければ何もできないこと。

こう並べるとエンジニアの方が
プロダクトマネージャーと比較すると、アウトプットが明確だとは思います。
「プロダクトマネージャーは、大変なだけでは、、」 と一瞬よぎったりもしたのが本音です。

ただ変に「これがプロダクトマネージャーのしごとです！」と明確にあるよりも
よりリアルなのかなとは思いました。

最後に、印象に残ったフレーズを。
「チームと組織の非公式大使」
アウトプットが明確ではないので、
気づけば一緒に働いているエンジニアやデザイナーが楽しく成果を出せている、
自分が考えた機能でユーザーの役にたっている。
そう考えると、プロダクトマネージャーのしごともおもしろいのかなと思います。

参考文献