コトラ（広報チーム） 
プロダクトマネージャーは、利用者の課題を理解し、プロダクトの方向性を決め、開発から改善までを推進する仕事です。事業への影響が大きく、幅広い経験を積める一方で、責任の重さや調整業務の多さから「やめとけ」と言われることもあります。
ただし、プロダクトマネージャーが厳しい仕事かどうかは、本人の適性だけで決まるものではありません。役割や権限が整理されているか、開発体制が整っているか、利用者の声やデータを活用できるかなど、職場環境にも大きく左右されます。
本記事では、プロダクトマネージャーが「やめとけ」と言われる理由、向いている人の特徴、目指す前に確認したいポイントを解説します。
プロダクトマネージャーが「やめとけ」と言われる背景
本記事で扱うプロダクトマネージャーの定義
本記事で扱うプロダクトマネージャーとは、製品やサービスの価値を高めるために、企画、開発、公開、改善の全体に関わる役割を指します。一般的にはPdMと略されることもあります。
対象となるプロダクトは、アプリ、Webサービス、業務システム、ソフトウェア、家電などさまざまです。共通するのは、利用者に継続的な価値を提供し、必要に応じて改善を重ねていく点です。
プロダクトマネージャーは、利用者が抱える課題、市場の変化、事業上の目標、開発上の制約を踏まえ、「誰にどのような価値を届けるのか」「何を優先して開発するのか」を考えます。プロダクトを完成させるだけではなく、公開後に利用状況を確認し、改善を続けることも重要な役割です。
ただし、企業によって職務範囲は異なります。事業戦略や販売計画まで担う場合もあれば、開発チームと連携して機能の企画や優先順位付けを中心に担う場合もあります。求人や面接では、肩書きだけではなく、実際の責任範囲を確認することが必要です。
プロジェクトマネージャーとの役割の違い
プロダクトマネージャーと混同されやすい職種に、プロジェクトマネージャーがあります。どちらも複数の関係者と連携し、開発を進める役割ですが、主に考える対象が異なります。
プロダクトマネージャーは、プロダクトそのものの価値や成長に焦点を当てます。利用者にとって何が必要か、なぜその機能を作るのか、どのような順番で改善するのかを考える役割です。
一方、プロジェクトマネージャーは、決められた目標を実現するために、計画、進捗、予算、人員、品質などを管理します。いつまでに、どのような方法で、どのように完成させるかに重点を置く役割です。
- プロダクトマネージャーが主に考えること
- 何を作るのか
- なぜ作るのか
- 誰の課題を解決するのか
- プロダクトをどのように成長させるのか
- プロジェクトマネージャーが主に考えること
- いつまでに作るのか
- どのように進めるのか
- 人員や予算をどう配分するのか
- 品質や納期をどう守るのか
実際の職場では、両方の役割を一人が担うこともあります。特に少人数の組織では、プロダクトの方向性を考えながら、進捗管理や関係者との調整まで担うケースがあります。その場合は業務範囲が広くなりやすいため、負担や権限のバランスを確認することが重要です。
「やめとけ」は仕事そのものより職場環境に左右される
プロダクトマネージャーに対して「やめとけ」と言われる背景には、仕事の難しさだけではなく、組織の仕組みや働き方の問題があります。
たとえば、責任だけを求められる一方で、予算、人員、優先順位を決める権限がない職場では、プロダクトマネージャーは十分な成果を出しにくくなります。開発チームが慢性的に不足している、意思決定者が多すぎる、目標が頻繁に変わるといった環境でも、調整業務が増えやすくなります。
反対に、プロダクトの目標が明確であり、意思決定の流れや役割分担が整理されている職場では、プロダクトマネージャーは本来の業務に集中しやすくなります。利用者の声や利用データを確認できる環境も、適切な改善を進めるうえで重要です。
そのため、プロダクトマネージャーを目指す際は、職種そのものを避けるのではなく、自分に合う組織かどうかを見極める視点が必要です。
プロダクトマネージャーの主な仕事内容
プロダクトの目標と方向性を決める
プロダクトマネージャーは、プロダクトが目指す方向性を定めます。利用者にどのような価値を提供するのか、事業としてどのような成果を目指すのかを整理し、チームが判断する際の基準を作ります。
この際には、売上や利用者数だけではなく、利用継続率、問い合わせ件数、利用頻度など、プロダクトの状況を判断する指標を設定することもあります。目標があいまいなまま開発を進めると、機能を増やしても成果につながらない可能性があるためです。
方向性は一度決めたら変えないものではありません。市場、利用者のニーズ、競合の動き、技術的な制約などを踏まえ、必要に応じて見直します。
利用者や市場の課題を調べる
プロダクトマネージャーは、利用者が何に困っているのか、どのような場面で不便を感じているのかを調べます。利用者への聞き取り、アンケート、問い合わせ内容、営業担当やサポート担当からの情報、利用データなどを活用して課題を把握します。
重要なのは、要望をそのまま機能として実装することではありません。たとえば「入力を簡単にしてほしい」という声があった場合、入力項目の多さが問題なのか、操作方法が分かりにくいのか、入力するメリットを感じにくいのかを掘り下げる必要があります。
市場の変化や競合サービスも確認し、自社のプロダクトがどのような価値を提供できるかを考えます。利用者の視点と事業の視点を両立させることが求められます。
開発する機能の優先順位を決める
開発したい機能や改善案は、多くの場合、一度にすべて実現できません。開発に使える時間や人員には限りがあるため、プロダクトマネージャーは優先順位を決めます。
優先順位を考える際は、利用者への影響、事業への効果、開発に必要な工数、技術的な難しさ、既存機能との関係などを確認します。要望の多さだけで決めるのではなく、解決したい課題の大きさや、実現した場合の効果を比較することが必要です。
優先順位の決定には、必ずしも唯一の正解があるわけではありません。そのため、判断の理由を整理し、開発チームや関係者に説明できる状態にしておくことが重要です。
開発チームと関係者の意思をそろえる
プロダクト開発には、エンジニア、デザイナー、営業、マーケティング、カスタマーサポート、経営層など、多くの関係者が関わります。それぞれ見ている課題や優先したいことが異なるため、意見が分かれることもあります。
プロダクトマネージャーは、関係者の意見を集めるだけではなく、プロダクトの目的に沿って論点を整理し、チームの認識をそろえる役割を担います。エンジニアには実現したい背景や優先度を伝え、経営層には事業への影響を説明するなど、相手に応じた伝え方も必要です。
直接の部下を持たないプロダクトマネージャーも多いため、指示だけで動かすのではなく、目的への納得感を作り、協力を得ながら進める力が求められます。
公開後の結果を確認して改善する
プロダクトマネージャーの仕事は、機能を公開して終わりではありません。公開後には、利用者が実際に使っているか、想定した行動につながっているか、問い合わせや不満が増えていないかを確認します。
確認には、利用者数、継続率、利用回数、購入率などの数字に加え、レビュー、問い合わせ、営業現場の声なども役立ちます。数字だけでは利用者が感じている使いにくさを把握しきれず、利用者の声だけでは全体の傾向を見誤ることがあるためです。
結果を確認したうえで、仮説が正しかったかを振り返り、次の改善につなげます。このように、仮説、実行、確認、改善を繰り返すことが、プロダクトマネージャーの重要な仕事です。
プロダクトマネージャーはやめとけと言われる5つの理由
責任が重い一方で決定する権限が十分ではない
プロダクトマネージャーは、プロダクトの成果に責任を持つ立場です。しかし、実際には予算、人員、開発の優先順位、販売方針などを単独で決められないことも少なくありません。
たとえば、利用者の課題を解決するために必要な改善案があっても、開発人員が確保できない、経営判断で別の施策が優先される、営業上の要望を断れないといった状況が起こることがあります。それでも成果を求められると、責任と権限が一致せず、強い負担を感じやすくなります。
この問題を避けるには、プロダクトマネージャーがどこまで決定できるのか、誰が最終判断を行うのか、予算や人員の調整に関われるのかを事前に確認することが重要です。
関係者の意見を調整し続ける負担が大きい
プロダクトマネージャーは、さまざまな部署や立場の人と関わります。営業は顧客から受けた要望を早く反映したいと考え、開発チームは技術的な負債や品質を重視し、経営層は事業成果を求めることがあります。
これらの意見はすべて重要ですが、同時に満たせるとは限りません。プロダクトマネージャーは意見の違いを整理し、何を優先し、何を見送るかを決める必要があります。判断に納得してもらえない場合には、説明や調整を重ねることになります。
人との対話や合意形成にやりがいを感じる人には魅力的な仕事ですが、一人で集中して作業を完結させたい人にとっては、負担が大きく感じられる可能性があります。
正解のない優先順位付けを求められる
プロダクト開発では、すべての課題を同時に解決することはできません。新機能の追加、既存機能の改善、不具合対応、技術基盤の整備など、重要な仕事が並行して発生します。
そのなかでプロダクトマネージャーは、限られた開発資源をどこに使うかを判断します。しかし、将来の利用者の反応や市場の変化を完全に予測することはできません。判断の結果がすぐに出ないこともあり、後から見れば別の選択肢が良かったと分かる場合もあります。
不確実な状況でも、集められる情報をもとに仮説を立て、判断し、結果から学ぶ姿勢が求められます。明確な正解が出るまで決められない人は、ストレスを感じやすい仕事です。
成果が数字や個人の実績として見えにくい
プロダクトマネージャーは、チームの成果を支える役割です。プロダクトが成長したとしても、その成果はエンジニア、デザイナー、営業、マーケティング、サポートなど、多くの人の働きによって生まれます。
そのため、個人の貢献を明確に示しにくい場合があります。特に、改善の効果が数か月後に現れるプロダクトでは、自分の判断がどの程度成果につながったかを評価しづらいこともあります。
一方で、目標設定や評価基準が明確な組織では、プロダクトマネージャーの貢献も評価されやすくなります。プロダクトの目標、担当範囲、成果の見方が整理されているかは、働きやすさに大きく関わります。
幅広い知識と学び続ける姿勢が必要になる
プロダクトマネージャーには、利用者理解、事業、開発、デザイン、データ分析、販売、運用など、幅広い領域への理解が求められます。すべてを専門家レベルで身につける必要はありませんが、それぞれの専門家と会話し、判断につなげられる知識は必要です。
また、技術、市場、利用者の行動、競合環境は変化します。過去に有効だった方法が、そのまま通用し続けるとは限りません。新しい情報を集め、必要な知識を学び、考え方を更新する姿勢が必要です。
学び続けることを負担と感じる人には厳しい面がありますが、変化のなかで成長したい人にとっては、知識と経験の幅を広げられる仕事でもあります。
「やめとけ」と感じやすい職場の特徴と見極め方
プロダクトの目標や責任範囲があいまい
プロダクトの目標が明確でない職場では、何を優先すべきかが分からなくなります。売上を伸ばすのか、利用者を増やすのか、継続率を高めるのか、業務効率を改善するのかによって、必要な施策は異なります。
また、プロダクトマネージャー、開発責任者、事業責任者、営業責任者の役割分担があいまいだと、同じ判断を複数の人が行ったり、逆に誰も決めなかったりする問題が起こります。
求人情報や面接では、担当するプロダクトの目標、プロダクトマネージャーの責任範囲、他職種との役割分担を確認しましょう。
意思決定者が多く判断に時間がかかる
関係者が多いこと自体は悪いことではありません。しかし、少しの変更でも複数の会議や承認が必要で、最終判断者が分からない状態では、開発や改善のスピードが落ちます。
利用者の課題や市場の変化に対応するには、一定の速さで仮説を試し、結果を確認することが必要です。判断が遅い組織では、プロダクトマネージャーが調整に追われ、本来行うべき利用者理解や改善検討に時間を使えなくなる場合があります。
面接では、機能の優先順位やロードマップを誰が決めるのか、通常どの程度の期間で意思決定されるのかを聞くと、組織の進め方を把握しやすくなります。
開発体制や人員が目標に見合っていない
高い目標を掲げていても、開発人員、予算、技術基盤、デザインや品質確認の体制が不足していれば、実現は難しくなります。プロダクトマネージャーだけが努力しても、必要な資源がなければ改善を進められません。
特に、一人のプロダクトマネージャーが複数のプロダクトを担当している、開発チームが他案件と兼務している、保守対応だけで手一杯になっている場合は注意が必要です。
組織の人数だけではなく、担当プロダクト数、開発チームの構成、外部委託の有無、今後の採用計画などを確認し、目標と体制のバランスを見ましょう。
利用者の声やデータを確認できない
プロダクトの改善には、利用者が実際にどう使っているかを把握することが欠かせません。しかし、利用データが取得されていない、データを見る仕組みがない、利用者への聞き取りができないといった環境では、判断が担当者の感覚や社内の声に偏りやすくなります。
もちろん、すべての判断を数字だけで行えるわけではありません。ただし、利用者の行動や意見を確認する手段があることで、仮説の精度を高め、改善の効果を検証しやすくなります。
面接では、どのような利用データを見られるのか、利用者の意見をどう集めているのか、公開後の効果検証をどのように行っているのかを確認しましょう。
面接や面談で確認したい役割・権限・評価基準
プロダクトマネージャーへの転職では、仕事内容の魅力だけではなく、働く環境を具体的に確認することが重要です。特に以下の点を確認すると、入社後のミスマッチを減らしやすくなります。
- 担当するプロダクトと利用者の種類
- プロダクトが現在抱えている課題
- プロダクトマネージャーに期待される成果
- 機能の優先順位やロードマップを決める流れ
- 予算、人員、開発計画にどこまで関われるか
- 開発チーム、デザイナー、営業などとの役割分担
- 利用者の声や利用データを確認する方法
- 評価基準と、成果をどのように測るか
- 現在の開発体制と今後の採用計画
- 直近で起きた大きな方針変更と、その対応方法
質問への回答が具体的であるほど、組織として役割や進め方を整理している可能性が高いと考えられます。
それでもプロダクトマネージャーを目指すメリットとやりがい
利用者の課題解決に一貫して関われる
プロダクトマネージャーは、利用者の困りごとを見つける段階から、解決策の検討、開発、公開後の改善まで関わります。自分が立てた仮説がプロダクトの機能となり、利用者の行動や体験の変化につながる点は、大きなやりがいです。
たとえば、利用者への聞き取りや問い合わせ内容から課題を見つけ、改善案を考え、チームと協力して公開し、その後に利用者の負担が減ったことを確認できれば、仕事の成果を実感できます。
部分的な業務だけではなく、課題解決の全体に関わりたい人にとって、魅力のある役割です。
事業やプロダクトの成長に大きく貢献できる
プロダクトは、企業の事業や利用者との接点に直結する存在です。プロダクトマネージャーの判断は、利用者数、継続利用、売上、問い合わせ件数、業務効率などに影響を与える可能性があります。
すべての成果を一人で生み出すわけではありませんが、どの課題に取り組むか、どの機能を優先するか、どのように価値を伝えるかを考えることで、事業の成長に大きく関われます。
自分の仕事を通じて、プロダクトや事業が前進する実感を得たい人にとっては、責任の大きさがやりがいにつながります。
多様な職種と協力する力が身に付く
プロダクトマネージャーは、エンジニア、デザイナー、営業、マーケティング、サポート、経営層などと協力します。それぞれの専門性や制約を理解し、共通の目的に向けて進める経験を積める点が特徴です。
この経験を通じて、相手の立場を踏まえて説明する力、意見の違いを整理する力、判断材料を分かりやすく共有する力が身に付きます。これらは特定の業界や職種に限らず、幅広い仕事で活かせる力です。
将来的には、複数のプロダクトを統括する立場や、事業責任者、プロダクト組織の責任者などを目指す道もあります。
自分の仮説が成果につながる手応えを得られる
プロダクトマネージャーは、利用者の課題やデータをもとに仮説を立て、改善を行い、結果を確認します。公開後に利用率が上がる、離脱が減る、問い合わせが減る、利用者の反応が良くなるなど、仮説が成果につながったときには大きな手応えがあります。
もちろん、すべての仮説が成功するわけではありません。しかし、成果が出なかった場合でも、理由を考え、次の改善に活かせます。失敗を学びに変えながら、プロダクトをより良くしていく過程に面白さを感じる人には向いています。
プロダクトマネージャーに向いている人の特徴
利用者や事業の課題を深く考えられる人
プロダクトマネージャーには、利用者の表面的な要望だけではなく、その背景にある困りごとを考える力が求められます。利用者が何を言っているかだけではなく、なぜその要望が出ているのか、どのような状況で困っているのかを掘り下げる姿勢が重要です。
同時に、利用者にとって便利な機能であっても、事業として継続できるか、開発にかかる負担に見合うかを考える必要があります。利用者の価値と事業の成果を両方考えることに関心がある人は、適性を発揮しやすいでしょう。
立場の異なる人の意見を整理して伝えられる人
プロダクト開発では、関係者ごとに重視する点が異なります。技術、使いやすさ、販売、収益性、品質、スケジュールなど、どれも重要な要素です。
プロダクトマネージャーに向いているのは、意見の対立を避けるだけではなく、それぞれの意見の背景を理解し、目的に沿って整理できる人です。誰かの意見を一方的に通すのではなく、何を優先し、何を後回しにするのかを分かりやすく説明できる力が求められます。
人前で話すことが得意でなくても、相手の話を聞き、論点を整理し、必要な情報を伝えることができれば強みになります。
不確実な状況でも優先順位を決められる人
プロダクトマネージャーは、情報が十分でない状態でも判断を求められることがあります。市場の反応、利用者の行動、開発の見積もりなどには不確実な要素があるためです。
そのため、完璧な情報がそろうまで待つのではなく、現時点で分かることを整理し、仮説を立て、優先順位を決められる人が向いています。判断後に新しい情報が出た場合は、固執せずに見直す柔軟さも必要です。
決断すること自体を目的にするのではなく、利用者や事業にとってより良い選択をするために、判断を続けられる人が適しています。
数字と利用者の声の両方から判断できる人
プロダクトマネージャーには、数字を見る力と、利用者の声を理解する力の両方が求められます。利用者数、継続率、利用頻度などの数字は、プロダクト全体の傾向を把握するために役立ちます。
一方で、数字だけでは、利用者がなぜ困っているのか、どこで迷っているのか、どのような感情を持っているのかまでは分かりません。聞き取りや問い合わせ内容、レビューなどから、数字の背景を考える必要があります。
高度な分析技術が最初から必要というわけではありません。数字を避けず、利用者の声と合わせて改善の仮説を立てようとする姿勢が重要です。
失敗から学び、粘り強く改善を続けられる人
プロダクト開発では、時間をかけて作った機能が使われない、利用者の反応が予想と異なる、開発途中で方針を変える必要があるといったことが起こります。
こうした結果を個人の失敗として終わらせず、どの仮説が外れたのか、何を見落としていたのかを振り返り、次の改善に活かせる人はプロダクトマネージャーに向いています。
プロダクトの成長には時間がかかる場合もあります。短期的な結果だけに左右されず、必要な改善を積み重ねられる粘り強さが求められます。
プロダクトマネージャーを目指す前に準備したいこと
自分が担いたい役割とキャリアの目的を明確にする
プロダクトマネージャーを目指す前に、なぜその仕事をしたいのかを整理しましょう。年収や肩書きだけを目的にすると、責任の重さや調整業務の多さに苦しむ可能性があります。
たとえば、利用者の課題解決に関わりたい、プロダクトの方向性を考えたい、事業づくりに近い仕事がしたい、開発とビジネスの間に立ちたいなど、自分が興味を持てる部分を明確にすることが大切です。
また、企画、利用者調査、開発推進、データ分析、販売戦略などのうち、どの領域を強みにしたいのかを考えると、必要な経験や応募先の選び方が具体的になります。
小さな改善業務から課題発見と提案を経験する
未経験からプロダクトマネージャーを目指す場合、最初から大きなプロダクトの責任者になる必要はありません。現職でできる小さな改善から、課題発見と提案の経験を積むことが有効です。
たとえば、問い合わせ内容を整理して改善案を出す、利用者や営業担当への聞き取りを行う、業務フローの課題を見つける、数値の変化を確認して施策を提案するといった経験が考えられます。
重要なのは、作業をこなした事実だけではなく、どのような課題を見つけ、どのような根拠で提案し、どのような結果になったかを説明できることです。
開発・営業・企画など関連職種への理解を深める
プロダクトマネージャーは、多様な職種と協力して仕事を進めます。そのため、開発、デザイン、営業、マーケティング、カスタマーサポートなどの仕事への理解を深めることが重要です。
エンジニア出身であれば、利用者調査や事業面への理解を広げることが課題になる場合があります。営業やマーケティング出身であれば、開発の進め方や技術的な制約を学ぶことが役立ちます。
すべての領域を一人で担える必要はありません。専門家の考え方を理解し、適切に相談しながら判断できる状態を目指しましょう。
応募先のプロダクト組織と働き方を比較する
同じプロダクトマネージャーという肩書きでも、会社によって仕事内容は大きく異なります。新規事業の立ち上げが中心の職場もあれば、既存プロダクトの改善が中心の職場もあります。開発に近い役割、事業企画に近い役割、販売や市場投入に近い役割など、求められる仕事もさまざまです。
応募先を比較する際は、プロダクトの成長段階、担当範囲、開発体制、意思決定の方法、利用者との距離、評価基準を確認しましょう。
また、新しいプロダクトを立ち上げる仕事では、不確実な状況で仮説を試す力が求められます。既存プロダクトを成長させる仕事では、利用データを見ながら地道に改善を続ける力が求められます。自分がどちらの環境で力を発揮しやすいかを考えることも大切です。
現職で役割を変える選択肢も検討する
プロダクトマネージャーを目指す方法は、転職だけではありません。現職にプロダクトやサービスがある場合は、社内で関連業務に関わる機会を探す方法もあります。
たとえば、利用者調査、機能改善の検討、開発チームとの調整、業務システムの改善提案、データ確認などに関わることで、プロダクトマネジメントに近い経験を積めます。すでに業界や利用者を理解している点は、社内で役割を広げる際の強みになります。
プロダクトマネージャーは、責任も調整も多い仕事です。しかし、利用者の課題解決やプロダクトの成長に強い関心があり、不確実な状況でも学びながら改善を続けられる人にとっては、大きなやりがいを得られる仕事でもあります。職種名だけで判断せず、役割、権限、組織体制を見極め、自分に合う環境を選ぶことが重要です。
