解決策の前に問題を書く
具体的な機能を提案する前に、顧客の問題とそれがなぜ重要かを平易な言葉で述べる――チームにまず問題について合意させることで、誰かがコードを書く前に間違った解決策を捕まえられる。
プロダクトマネージャーがホワイトボードに大胆なビジョンを描くというイメージは、ほとんど間違っている。仕事の大部分は地味な統合作業だ――アンケートや分析データを読み込み、エンジニアが読み違えようのないほど正確な文書を書き、意見の合わない何人もの人々を一つの計画にまとめることが本当の仕事である会議に座り続ける。
この分野で受け継がれる技術は、単一のツールというよりも習慣についてのものだ――良いアイデアであっても今は間違ったアイデアだから断る方法、実際のエンジニアとの接触に耐えられる仕様書の書き方、そして顧客が言うことより実際にすることをいつ信じるべきか。
What the work demands
優先順位付け90
文章によるコミュニケーション82
ステークホルダーへの影響力78
データ分析75
ユーザーリサーチ68
技術的な流暢さ58
優先順位付け
何を作らないかを決めることが日々の判断の中で最も影響力が大きい――ロードマップの大半は、プロダクトマネージャーが「今はやらない」と決めた良いアイデアの長いリストである。
文章によるコミュニケーション
仕様書、ロードマップの更新、事後検証報告は、その場にいなかった人々でも正しく行動できるほど正確でなければならない。
ステークホルダーへの影響力
エンジニアリング、デザイン、営業、経営陣に対してほぼ正式な権限を持たないまま同じ計画への合意を取り付けること――しばしば「権力なしで導く」と要約される。
データ分析
利用データや実験結果を、本物のシグナルとノイズを見分け、指標が本当に改善しているのか操作されているだけなのかを見極められるほど十分に読み解くこと。
ユーザーリサーチ
アンケートや営業チームの又聞きだけに頼るのではなく、顧客と直接話し、実際に製品を使う様子を観察すること。
技術的な流暢さ
必ずしも自分で構築できなくても、エンジニアとトレードオフについて実のある会話ができる程度に、基盤となるシステムの仕組みを理解していること。
A day in the life
- 8–9
受信箱、Slack、夜間の指標
一日の会議が始まる前に、メッセージに目を通し、夜間のダッシュボードで何か壊れていないか、想定外に動いていないかを確認する。
- 9–11
スタンドアップとチーム横断の同期
直属のプロダクトチームとの毎日のスタンドアップに加え、デザイン、エンジニアリングリーダー、依存関係のあるチームとの定例会議で作業の障害を取り除き、意見の相違を解消する。
- 11–13
集中作業:仕様書と分析
一日の中で最もしっかり守られた時間帯で、仕様書の作成・改訂、実験結果の分析、次の意思決定に向けた資料の準備に費やされる。
- 13–14
昼食
良い日には本当の休憩になるが、悪い日には長引いた会議が続けて入り消えてしまう。
- 14–18
ステークホルダーとの会議とレビュー
一日で最も会議の詰まった時間帯――ロードマップレビュー、デザインの批評、営業や顧客との電話、そして次四半期に実際に何が出荷されるかを決める交渉。
- 18–8
勤務時間外(おおむね)
私的な時間だが、ローンチ週や緊急の顧客対応があれば、正式な終業後もSlackでプロダクトマネージャーが呼び戻されることがある。
The know-how
Craft knowledge practitioners actually pass on — not motivation.
ユーザーに話しかけよ、アンケートだけに頼るな
アンケートは人々が欲しいと言うものを教えてくれるが、対面や画面共有で実際に誰かが製品を使おうとする様子を見ることは、彼らが言及することさえ思いつかなかった摩擦を明らかにする。
本当のリスクを検証する最小のものを出荷せよ
完全な機能を作る前に、最も間違っている可能性の高い仮説を検証する最小限のバージョンに切り詰める――時にはその裏側に何も存在しないうちからクリックを計測する単一のボタンだけということもある。
肩書きが与えない権威は自ら勝ち取れ
意見が対立したときには方向性を定め最終判断を下すが、その権威は肩書きに付いてくるものだと思い込むのではなく、準備と判断力によって勝ち取る――組織的な権力を持たないプロダクトマネージャーは、命令できるマネージャーよりも頻繁に正しくなければならない。
断るときは文書で、理由とともに
機能要望を黙って却下すると恨みを生む。なぜこちらでありあちらでないのか、なぜ今四半期なのかというトレードオフを一文で説明することで、「ノー」は人々が実際に議論したり受け入れたりできる決定に変わる。
誰も動かせない指標を疑え
提案された成功指標が過去の複数の努力にもかかわらず目に見えて変化していないなら、それが本当に正しい指標なのかを、その指標を動かすことに四半期のロードマップを賭ける前に問い直す。
Tools of the trade
分析プラットフォーム
Amplitude、Mixpanel、あるいは社内ダッシュボードといったツールは、生の利用ログをプロダクトマネージャーが実際に検討できるファネルやコホートへと変換する。
課題・ロードマップトラッカー
Jira、Linear、あるいは同様のツールは、アイデアの一覧を、エンジニアリング、デザイン、経営陣の全員が同時に見られる優先順位付けされた可視化バックログへと変える。
仕様書 / PRDテンプレート
問題、目標、要件、エッジケース、成功指標といった構造化された文書形式で、エンジニアが推測なしに構築できるほど仕様書を明瞭に保つ。
A/Bテストプラットフォーム
Optimizelyや社内の実験フレームワークといったツールは、チームが機能の2つのバージョンを異なるユーザーに出荷し、どちらが実際に優れているかを測定できるようにする。
AI草稿作成アシスタント
ChatGPTやClaudeといったツールは、仕様書の初稿を作成したり、ユーザーインタビューを要約したり、アンケート回答を統合したりすることが増えており、仕事を白紙からの入力よりも編集と判断へとシフトさせている。
How people fail at it
フィーチャーファクトリー症候群
実際に本物の問題を解決したかどうかではなく、出荷した機能の数で成功を測ること。忙しいロードマップと実際には改善しない製品を生み出す。
最も声の大きい顧客の要望通りに作る
ある一人の熱心な顧客の具体的な機能要望を代表的なニーズとして扱い、それが有意な割合のユーザーに共有された問題を反映しているかどうかを確認しないこと。
仕様書で「なぜ」を省略する
根底にある問題や目標を説明せずに詳細な要件のリストを書くと、現実が計画から必然的にずれたときに、エンジニアが良い判断を下せなくなる。
Keep exploring
More in Business & Finance
🚀
起業家
会社を興す人——機会を見出し、リスクを背負い、給料の支払いに責任を持つ。アッシリアの隊商金融業者からベンチャー支援の創業者まで。
AI-resistant 88 💹投資銀行家
企業に値を付け、資本を動かすディールメーカー——メディチ家のフィレンツェから今日のピッチブックまで続く商売で、巨額の金が動くときの信用に対価が支払われる。
AI-resistant 42 🧾会計士
帳簿の番人――文字そのものを生み出したほど古い技を受け継ぎ、いまはそれを自動化するために作られたソフトウェアと折り合いをつけている。
AI-resistant 35 📣マーケター
需要を生み出す専門職——ポンペイの壁の広告文やP&Gの1931年の「ブランドマン」覚書から、オークション主導のデジタル時代のフィードまで。
AI-resistant 38 💱経済学者
希少性を研究する学者――アダム・スミスのピン工場から中央銀行の意思決定室まで、どんなモデルも捉えきれないものを予測せよと求められ続けている。
AI-resistant 62