9/5にオライリー・ジャパンより出版された「プロダクトマネージャーのしごと」を読み終えました。
特に印象に残った個所を中心に感想をまとめておきます。
なぜ読んだのか
私はエンジニアでありPdMではありませんが、何か新しいプロダクトや機能を開発する際に「うん、正しい方向に向かっている」と自信をもって開発を進められるように、プロダクトマネージメントの分野も積極的に学習しています。またエンジニアとPdMは親和性の高い職種だと考えています。自身の市場価値を高めるためにもPdMとしての知見も身につけてやろうと企んでいます。
ざっくり感想
当初はPdMがよく使ってそうなフレームワーク(BMC等)とかロードマップの書き方みたいなものが学べることを期待していましたが、そうではなくPdMとして重要なマインド、心構えみたいな内容が多く書かれています。むしろフレームワークは「有用なフィクション」として、ロードマップは「チームが会話をするきっかけとなるドキュメント」として表現されています。フレームワークを使いこなせるとか、見栄えの良いロードマップや資料が作成できる、といったスキルはPdMに必ずしも必要なものではないのだなあと本書を読んで実感しました。
特に印象に残った点・実践したい点
4章 過剰コミュニケーションの技術
- 「良いPdMは当たり前のことを必要以上に明確に説明しようとする。悪いPdMは当たり前のことを絶対に説明しない。」
→自分の「当たり前」が他人にとっても「当たり前」とは限らないため。「当たり前」は時にコミュニケーションにおいて大惨事を引き起こす可能性がある。
6章 ユーザーに話しかける
-
ユーザーリサーチでは一般論ではなく具体的な例をヒアリングする。（その方が答えてもらいやすい）
✕：普段ランチで何を食べますか？一番好きな食べ物は何ですか？
〇：最後に食べた食事について細かく教えてください。 -
ペルソナ活用のコツ
- ペルソナはリサーチに基づいて設定すること。 そうしなければステレオタイプのペルソナが出来上がる。
- ペルソナは定期的に見直す。マーケットも人も時と共に変化していく。
- ペルソナを明確にすることで、ターゲットでないユーザーを明確にする。
7章 「ベストプラクティス」のワーストなところ
- 他社での成功事例が自社でも成功するとは限らない。
- フレームワークやモデルは有用なフィクションとして活用すべき。成功を保証するものではない。
8章 アジャイルについての素晴らしくも残念な真実
- アジャイルの本質は「コラボレーションする、デリバリーする、内省する、改善する」の4点。
→思考停止で「アジャイルだから～しなければならない」と考えること自体がそもそもアジャイルに違反している。 - アジャイルな取り組み（デイリースタンドアップ等）が上手くいっているかどうかを判断するためには以下の質問を考えるとよい。
- その取り組みの目的は何か？
- その取り組みの目的の達成度を10段階で表すと？
9章 ドキュメントは無限に時間を浪費する
- ロードマップのREADMEを作成して、ロードマップに対するチームの共通理解を作る。
- 最高のドキュメントは不完全。（あえて議論するきっかけを残す）
- 最初のドラフトは原則1ページ、また1時間以内に作成すること。
→私の経験的にも、詳細まで丁寧に書いた長編のドキュメントよりも、本当に伝えたいことだけ書いたシンプルなドキュメントの方が圧倒的に読んでもらいやすい。 - 人にテンプレートを埋めるように依頼する前に最低三回は自分で埋める。
10章 ビジョン、ミッション、達成目標、戦略を始めとしたイケてる言葉たち
- アウトプットとアウトカムのシーソー（アウトカムを具体的に決めれば、アウトプットは柔軟に決定できるようになる。）
- 戦略と日々の職務実行はつながりのあるものでなければならない。（日々の業務の意思決定に役立つものでなければならない。）
- 優れた戦略はシンプルで明快。パワーポイントを使って延々と説明する必要のないもの。
- 優れた戦略の特徴
- 「ユーザーは誰？」「解決したい課題は何？」「私たちがその課題を解決するのにふさわしい会社である理由は？」といった単純な質問に答えられるもの。
- チーム全員が暗唱できる1,2行のもの。
- 「何を作らないか」を決めるときに役立つもの。
- しばらくすると古臭く思えてくる。(定期的な見直しが必要)
12章 優先順位づけ：すべてのよりどころ
- 引き算の解決策
→機能、機能性を引き算(削除)することがユーザーやビジネスにとって付加価値になる場合もある。
以上です。次は前職で出向先子会社→親会社に復帰するときに、出向先の上司からもらった「ジョブ理論」を読みたいと思います！