顧客の声は聞いている。
開発も進んでいる。
新機能も出している。
チームも忙しく動いている。
それなのに、プロダクトが決定的に強くなっている実感がない。
売上につながっているのかも曖昧。
顧客にとって本当に価値が増えたのかも、自信を持って言えない。
プロダクトの現場では、こうしたことが起きます。
しかも厄介なのは、誰もサボっていないことです。
むしろ全員、本気で頑張っている。
営業は顧客の声を拾ってくる。
CSは解約リスクを教えてくれる。
開発は難しい制約の中で実装してくれる。
それでも、プロダクトが前に進んでいる感じがしないことがある。
これは、実行力が足りないからではありません。
多くの場合、問題はもっと手前にあります。
何を解くべきかの解像度が足りない。
なぜそれを優先するのかの軸が弱い。
リリースの先にある成果まで設計できていない。
つまり、足りていないのは機能開発ではなく、
プロダクトマネジメントです。
プロダクトマネジメントは、要望を整理して機能を作る仕事だと思われがちです。
でも実際には、それだけではまったく足りません。
本質は、顧客課題・事業価値・実現可能性をつなぎながら、「何を作るべきか」を定め、組織を動かし、成果が出るまで意思決定し続けることです。
では、PdMは何を軸に考えるべきなのか。ここから、その考え方を整理していきます。
ある機能要望から始まる話
では、プロダクトが迷走するとき、PdMは何を見失っているのか。私はそれを、単なる実行力不足ではなく、「考え方のズレ」として捉えるべきだと思っています。
ここからは、プロダクトマネジメントを進めるうえで重要な考え方を、ひとつの機能要望を例に整理していきます。
たとえば、営業チームからこんな要望が来たとします。
「提案書をもっと早く作れるように、AIで自動生成できるようにしてほしい」
一見、筋の良い要望に見えます。
現場の困りごとがありそうですし、AIというテーマも分かりやすい。すぐに企画化したくなるかもしれません。でも、ここでそのまま動き出すと危うい。
なぜなら、この要望は課題ではなく、すでに解決策の形をしたリクエストだからです。
本当に解くべきなのは何か。
- 提案書作成に時間がかかることなのか
- 若手営業の提案品質が安定しないことなのか
- 提案準備に時間を取られ、顧客との対話時間が削られていることなのか
- そもそも受注率に効くボトルネックが別にあるのか
この問いを飛ばして機能に飛びつくと、「ちゃんと作ったのに、思ったほど使われない」「使われるけれど、事業成果にはつながらない」という状態が起きます。ここに、プロダクトマネジメントの難しさがあります。そしてこれこそが、プロダクトマネジメントの面白さでもあります。
プロダクトマネジメントにおける5つの考え方
1. 要望ではなく、課題を見る
プロダクトの現場には、毎日のように「こうしてほしい」が集まります。
- 営業からの要望
- CSからの改善依頼
- 顧客からの機能追加の声
- 経営からの新テーマ
- 開発からの技術的な改善提案
どれももっともらしく見えます。
でも、それらを順番に拾っていくだけでは、プロダクトは確実に複雑になります。だからこそ、PdMはまず要望をそのまま受け取らない。
見るべきなのは、要望の奥にある課題です。
- 「この機能が欲しい」の裏に、どんな業務上の詰まりがあるのか
- 「この画面を変えてほしい」の奥に、どんな意思決定の遅れがあるのか
- 「AIで自動化したい」の裏で、本当に削減したいのは何の負荷なのか
解決策ではなく、問題定義から始める。これが、プロダクトマネジメントの出発点です。
2. 局所最適ではなく、全体最適で考える
個別の要望は、それぞれ正しく見えます。
- 大口顧客からの依頼なら断りづらい
- 営業が今月の案件で必要と言えば優先したくなる
- CSが解約リスクを説明すれば無視できない
- 開発が技術負債の危険性を訴えれば、それも正しい
でも、それらを全部拾うと、プロダクトは一気に弱くなります。一つひとつの判断は正しくても、積み重なると一貫性が崩れる。UIは複雑になり、学習コストは上がり、開発速度も落ちる。
結果として、誰にとっても少しずつ使いづらいプロダクトになります。
PdMに必要なのは、一段高い視点です。
- これは一部顧客への最適化ではないか
- 長期の戦略と整合しているか
- 他のユーザー体験を壊さないか
- 将来の運用コストや複雑性を増やしすぎないか
プロダクトマネジメントとは、目の前の案件に反応する仕事ではなく、プロダクト全体の競争力を設計する仕事です。
3. リリースではなく、成果で考える
たとえば、検索機能を改善したとしても、本当に見るべきなのは「検索精度が上がったか」だけではありません。その改善によって、ユーザーが必要な情報にたどり着くまでの時間が短くなったのか。問い合わせ件数が減ったのか。継続利用につながったのか。
機能単体の出来ではなく、行動や成果の変化で見る必要があります。
現場では、気づくと「何を出したか」の話が中心になります。
- 何件の機能をリリースしたか
- ロードマップがどこまで進んだか
- 今月何本の改善を出したか
もちろん大事です。でも、それは活動量です。本当に見るべきなのは、その結果として何が変わったかです。
- 利用率は上がったのか
- 継続率は改善したのか
- 業務時間は減ったのか
- 受注率や商談化率に効いたのか
- ユーザーの意思決定は速くなったのか
PdMは、機能の納品責任者ではありません。価値創出の責任者です。
だから、リリースして終わりではなく、その先の成果まで追い切る必要があります。
4. 正解を当てるのではなく、仮説検証で進める
プロダクトマネジメントに、最初から完璧な正解はありません。
- 顧客の声を聞いても、未来は読めない
- データを見ても、答えが自動で出るわけではない
- 競合を見ても、自社に合う打ち手とは限らない
だから重要なのは、一発で正解を当てることではありません。
不確実性を減らしながら進むことです。
- この課題は本当に大きいのか
- この解決策で行けそうか
- この体験で使われるのか
- この価格で価値が成立するのか
そのために、小さく試し、観察し、学び、修正する。MVPはそのためにあります。
完成度より、学習速度。これが、強いPdMの基本姿勢です。
5. 何をやるか以上に、何をやらないかを決める
PdMの現場で本当に難しいのは、追加する判断より、捨てる判断です。
やりたいことは常に多い。顧客要望も尽きない。
営業にもCSにも経営にも、それぞれ正しい事情がある。
その中でPdMが担うのは、全部を満たすことではありません。
限られたリソースの中で、何に賭けるかを決めることです。
優先順位づけとは、単なるタスク整理ではありません。
やらないことを決める意思決定そのものです。
では、その考え方を実現するには何が必要か
プロダクトが迷走するとき、足りないのは気合いや開発速度ではなく、「何を解くべきか」を見極める考え方であることが多いです。
だからこそ、PdMには思考の型が必要になる。
次回は、この考え方を実務で成立させるために必要なスキル、つまり「良いPdMは何ができるのか」を整理してみたいと思います。
