コトラ（広報チーム） 
コンサルタントからPdMへの転職では、課題設定力、分析力、関係者を動かす力など、すでに保有している強みを正しく言語化することが重要です。一方で、プロダクトを長期的に成長させる仕事には、ユーザー理解、開発チームとの協働、リリース後の改善といった新たなスキルも求められます。
特に戦略・総合・ITコンサルタントは、構造的に考え、複雑な利害関係を整理し、意思決定を支援してきた経験を持つため、PdMとの親和性は高いといえます。ただし、コンサルで成果を出した経験をそのまま伝えるだけでは、PdMとしての再現性が伝わりにくい場合があります。本記事では、コンサル経験をPdM転職で活かすための棚卸し方法、不足しやすいスキルの補い方、選考と入社後に向けた準備を解説します。
コンサルからPdMを目指す前に理解したい役割と適性
PdMが担うプロダクトの価値づくりと意思決定
PdMは、プロダクトを通じて誰のどのような課題を解決するのかを定義し、事業として継続的に価値を届けるための意思決定を担う役割です。市場やユーザーの状況を把握し、何を作るか、何を作らないか、どの順番で取り組むかを決めます。
仕事の範囲は企業や組織の規模によって異なりますが、一般的にはユーザー調査、課題の整理、プロダクト戦略や中長期の計画づくり、機能の優先順位付け、開発チームとの連携、リリース後の効果検証まで関わります。重要なのは、要望を集めて開発に渡すことではなく、限られた開発資源をどこに使えばユーザー価値と事業成果を高められるかを判断することです。
PdMには、ビジネス、ユーザー、開発の3つの観点を行き来する力が求められます。売上や事業目標だけを見ても、ユーザーの困りごとだけを見ても、持続的に成長するプロダクトにはつながりません。複数の条件を踏まえ、完全な正解がない中で意思決定することがPdMの中核業務です。
コンサルタントとPdMで異なる責任範囲と仕事の進め方
コンサルタントとPdMは、課題を整理し、関係者と合意しながら前に進める点では共通しています。しかし、責任の対象と時間軸には違いがあります。コンサルタントは、顧客企業の課題に対して分析、提案、実行支援を行うことが中心です。一方でPdMは、自社プロダクトの成長と成果に継続的な責任を持ちます。
コンサルでは、プロジェクトの目的、期間、成果物が比較的明確に定められているケースが多いでしょう。PdMは、リリースが終わっても仕事が完了しません。リリース後に利用状況やユーザーの反応を確認し、仮説が外れていれば改善し、場合によっては機能を見直す、あるいは終了する判断も必要です。
また、コンサルタントは提案内容の実行を支援する立場になりやすいのに対し、PdMは日々の優先順位や仕様の判断を自ら引き受けます。経営、営業、カスタマーサポート、デザイナー、エンジニアなどから異なる要望が寄せられる中で、プロダクト全体にとって最適な判断を続ける必要があります。
戦略・総合・ITコンサルの経験が活きやすい場面
戦略コンサルタントの経験は、市場分析、競合分析、事業戦略、成長シナリオの設計などで活かしやすい強みです。プロダクトの方向性を考える際に、顧客価値だけでなく市場性や収益性も含めて整理できるため、事業とプロダクトをつなぐ役割で力を発揮できます。
総合コンサルタントは、業務改革、組織変革、システム導入などの経験を持つことが多く、複数部門の利害を調整しながらプロジェクトを推進する力が強みになります。特に、業務が複雑な法人向けプロダクトでは、顧客の現場業務を理解し、利用定着まで見据えた設計ができることが評価されやすいでしょう。
ITコンサルタントは、要件定義、システム設計、開発プロジェクトの管理、データ活用などの経験を活かせます。エンジニアとの会話や開発の進め方に一定の理解があるため、技術的な制約を踏まえた優先順位付けや、実現可能な仕様への落とし込みで強みを出しやすいといえます。
ただし、いずれの出身でも、顧客企業の担当者を主な相手にしてきた場合は、実際の利用者の行動や感情を直接理解する経験が不足していることがあります。強みを活かしながら、ユーザー理解の不足を補う姿勢が重要です。
未経験からPdMを目指しやすい人の特徴
未経験からPdMを目指しやすいのは、正解がない問題に対して、自ら仮説を置き、周囲を巻き込みながら試行錯誤できる人です。分析や提案が得意でも、結論を出すために情報が十分にそろうまで動けない場合、変化の速いプロダクト開発では苦労する可能性があります。
また、ユーザーや現場の業務に強い関心を持てることも重要です。PdMは、利用者が何を言ったかだけではなく、実際にどのように行動しているか、どこで迷っているか、何を代替手段で補っているかを深く理解する必要があります。机上の分析だけでなく、現場を見て一次情報を集めることに前向きな人は適性があります。
さらに、自分が専門家でなくても、エンジニアやデザイナーと協働し、相手の専門性を尊重できることも欠かせません。PdMは、すべてを自分で決める役割ではありません。異なる職種の意見を統合し、チームが納得して前進できる状態をつくる役割です。
顧客支援から長期的な価値提供へ移るキャリアの考え方
コンサルからPdMへの転職を考える際は、単に職種名を変えるのではなく、仕事を通じて実現したい価値を見直す必要があります。顧客企業の変革を支援することにやりがいを感じるのか、それとも一つのプロダクトに長く関わり、改善を積み重ねて利用者の行動を変えたいのかを整理しましょう。
PdMでは、戦略を描く力だけでなく、細かな仕様の検討、開発中の調整、リリース後の問い合わせ対応、数値の振り返りなどにも向き合います。華やかな企画業務だけではなく、地道な改善を続ける仕事であることを理解しておく必要があります。
長期的な価値提供に魅力を感じるのであれば、転職先選びでも、プロダクトの市場、ユーザー、成長段階、開発体制を確認することが重要です。自分が共感できる課題を扱い、継続して改善したいと思えるプロダクトであるかを見極めましょう。
コンサル経験をPdMの強みに変える棚卸し方法
担当案件を課題設定から成果まで分解する
棚卸しでは、担当案件を時系列で並べるだけでは不十分です。各案件について、どのような課題があり、自分が何を考え、誰を巻き込み、どのような成果につながったかを分解します。PdM選考では、役職や案件規模よりも、本人が課題解決にどう関与したかが見られます。
整理する際は、次の順序で書き出すと効果的です。
- どのような顧客や利用者が対象だったか
- どのような課題や不満があったか
- 課題の背景をどのように調査したか
- 自分が設定した仮説は何か
- どのような関係者と連携したか
- どのような判断や提案を行ったか
- 実行後にどのような変化や成果が出たか
- 次に同じ状況であれば何を改善するか
この整理により、抽象的な「課題解決力」ではなく、PdMにも転用できる具体的な行動として経験を説明できるようになります。
仮説構築力をユーザー課題の発見力として整理する
コンサルタントにとって仮説構築は基本的なスキルですが、PdMでは仮説の対象がユーザーの行動や課題に変わります。たとえば、売上が伸びない原因を分析した経験は、ユーザーが離脱する理由や、利用頻度が伸びない理由を見つける力として整理できます。
ただし、PdMでは仮説を早く作るだけでなく、仮説を検証する姿勢が重要です。ユーザーの発言をそのまま受け取るのではなく、実際の行動や利用データと照らし合わせて理解を深めます。「この機能が欲しい」という要望に対しても、なぜ必要なのか、どの業務のどの場面で困っているのかを掘り下げる必要があります。
棚卸しでは、案件でどのように仮説を立て、どのような情報で検証し、当初の見立てをどう修正したかを振り返りましょう。この経験は、不確実な状況でユーザー課題を探索する力として伝えられます。
分析力を指標設計と改善判断の力として示す
コンサル経験者は、調査や分析の経験を持つことが多い一方で、PdM選考では分析結果をプロダクトの改善判断にどう結びつけたかが問われます。単にデータを集計した経験ではなく、何を測るべきかを決め、結果をもとに次の行動を選んだ経験を示しましょう。
たとえば、業務改善案件で処理時間、エラー率、利用率などを設定した経験があれば、それはPdMにおける利用状況の確認や改善効果の測定に通じます。重要なのは、数字の変化を説明することではなく、その数字が何を意味し、どの意思決定に使われたかです。
プロダクトでは、売上だけでは判断できない場面も多くあります。新機能であれば利用開始率や継続利用率、業務支援型のサービスであれば作業完了率や処理時間など、目的に応じた指標を設計します。既存の分析経験を、目的に合った指標を設計し改善につなげる力として言い換えましょう。
関係者調整力をチームを動かす力として言い換える
コンサルタントの関係者調整力は、PdMでも大きな強みになります。ただし、「調整できます」と伝えるだけでは不十分です。PdMに必要なのは、意見の対立を避けることではなく、プロダクトの目的に立ち返って意思決定を進める力です。
営業部門は顧客要望への迅速な対応を求め、開発チームは品質や技術的な安定性を重視し、経営層は事業成果を求めます。PdMはそれぞれの要望を単純に受け入れるのではなく、背景を理解したうえで、優先順位と判断理由を示す必要があります。
棚卸しでは、対立する意見があった案件を選び、自分がどのように論点を整理し、合意形成につなげたかを具体化しましょう。特に、目的、判断基準、選択肢、見送った理由まで説明できる経験は、PdMとしての推進力を示す材料になります。
業界知識と顧客理解をプロダクトの強みに変える
特定業界でのコンサル経験は、PdM転職で差別化につながる強みです。金融、製造、医療、物流、人事、会計など、業務が複雑で専門性が高い領域では、顧客の業務や意思決定の背景を理解していること自体が価値になります。
ただし、業界知識を単なる知識として伝えるのではなく、プロダクト価値にどうつながるかを説明する必要があります。たとえば、「業界の制度や業務フローを理解しているため、現場で使われる条件や例外を踏まえた仕様を考えられる」「導入時につまずきやすい点を想定し、利用定着まで考慮できる」といった形です。
顧客企業の意思決定者との対話経験も強みになります。導入を決める人と、日常的に使う人が異なる場合、双方の期待を理解した設計が必要です。こうした経験は、法人向けプロダクトのPdMを目指す際に特に活かしやすいでしょう。
PdM転職で不足しやすいスキルと優先順位
ユーザーの行動を深く理解する力
コンサルからPdMを目指す場合、優先的に補いたいのがユーザー理解です。コンサルでは顧客企業の担当者や管理職との対話が中心になりやすく、実際にサービスを利用する人の行動を継続的に観察する機会は限られます。
ユーザー理解では、要望を聞くだけでは足りません。ユーザーがどのような状況でサービスを使い、どこで迷い、何を代替手段として使っているかを把握します。インタビューでは、理想論を聞くよりも、直近の具体的な行動や一日の業務の流れを聞くことが重要です。
ユーザーの言葉をそのまま機能要望として受け止めるのではなく、背景にある目的や困りごとを探る力を身につけましょう。「何が欲しいですか」ではなく、「最後にその作業をしたとき、どのような手順でしたか」「困った場面はどこでしたか」といった問いを使うことで、より具体的な情報を得やすくなります。
開発の進め方と技術の基礎知識
PdMが自らコードを書く必要はありませんが、開発の進め方や技術的な制約を理解することは必要です。技術を理解していなければ、実現可能性、開発負荷、品質上のリスクを踏まえた判断が難しくなります。また、エンジニアとの信頼関係を築くうえでも、基本的な理解は重要です。
まずは、要件定義から設計、実装、テスト、リリースまでの流れを把握しましょう。加えて、データベース、外部サービスとの連携、情報セキュリティ、画面と裏側の処理の違いなど、Webサービスや業務システムの基本的な仕組みを学ぶことが有効です。
重要なのは、技術用語を覚えることではありません。エンジニアに対して、なぜその機能が必要なのかを説明し、どの程度の品質や速度が求められるのかを対話できる状態を目指しましょう。
仕様を具体化し優先順位を決める力
戦略や構想を描く力があっても、それを開発できる単位まで具体化できなければ、PdMとして価値を出すことは難しくなります。ユーザーの課題を整理し、誰が、どの場面で、何を達成できるようにするのかを明確にし、必要な機能や画面の条件に落とし込みます。
また、PdMはすべての要望を実現する役割ではありません。開発資源には限りがあるため、ユーザーへの効果、事業への影響、開発にかかる負担、緊急性などを比較し、優先順位を決める必要があります。
優先順位付けでは、単に点数を付けることよりも、判断基準をチームで共有することが重要です。なぜ今この施策を行うのか、なぜ他の要望を見送るのかを説明できれば、関係者の納得感を高められます。
数字を見て改善を続ける力
コンサルタントは分析経験を持つことが多い一方、プロダクトにおける改善サイクルを継続的に回す経験は不足しやすい領域です。PdMは、リリース後の利用状況を確認し、想定どおりの変化が起きたかを確かめます。
たとえば、新しい画面を公開した場合、利用者が増えたかだけではなく、途中で離脱していないか、目的の操作を完了できているか、問い合わせが増えていないかなどを確認します。数字だけでは理由が分からない場合は、ユーザーへのヒアリングと組み合わせて解釈します。
数字を見る目的は、報告書を作ることではなく、次の改善判断を行うことです。どの数字が変われば成功といえるのかを事前に定め、結果を踏まえて続ける、直す、やめるを判断する習慣を身につけましょう。
不確実な状況で小さく試して学ぶ姿勢
コンサルでは、一定の分析や検討を経て提案をまとめる仕事が多い一方、プロダクト開発では、完全な情報がない状態で小さく試すことが求められます。長期間かけて完成度の高い機能を作っても、ユーザーに使われなければ価値になりません。
そのためPdMには、最初から大きな開発を行うのではなく、試作品、簡易的な画面、限定公開などを通じて、早い段階で学ぶ姿勢が必要です。仮説を立て、必要最小限の形で確かめ、結果を見て次の判断を行います。
失敗を避けることよりも、小さな失敗から早く学ぶことが重要です。コンサル経験者は完成度の高い資料や提案を求められてきた場合もありますが、PdMへの転職では、不完全な状態でも検証を進められる柔軟性を示すことが評価につながります。
不足スキルを現職と学習で補う実践方法
現職案件でユーザー調査や検証の機会をつくる
PdMを目指すなら、現職でもユーザー理解に近い経験を意識的に増やしましょう。顧客へのヒアリング機会がある場合は、意思決定者だけでなく、実際に業務を行う担当者の話を聞く機会を提案します。業務フロー、手作業で補っている部分、失敗しやすい場面などを具体的に確認します。
ヒアリング後は、発言をそのまま議事録にするだけでなく、困りごと、発生する場面、現在の対処法、解決できた場合の価値に整理します。この作業は、ユーザー課題を構造化する練習になります。
また、提案前後で顧客の反応や利用状況を確認する機会をつくることも有効です。施策が実行された後に、当初の仮説と結果がどう違ったのかを振り返れば、プロダクト改善に近い経験として蓄積できます。
開発チームとの協働を通じて技術理解を深める
ITコンサルでない場合でも、現職で開発チームやシステム部門と関わる機会を増やすことが有効です。システム導入、業務改善、データ活用、新規サービス検討などの案件で、要件整理や仕様検討に関わる役割を担いましょう。
開発チームと協働する際は、技術的な回答を受け取るだけではなく、なぜ実現が難しいのか、どのような代替案があるのかを質問します。こうした対話を重ねることで、技術を万能な手段として扱わず、制約を踏まえて判断する感覚が身につきます。
業務外では、基本的なプログラミング、データベース、Webサービスの構成、バージョン管理、テストの考え方などを学ぶことも役立ちます。目標はエンジニアになることではなく、開発チームと共通言語を持ち、よりよい議論ができる状態になることです。
身近なサービスを題材に改善案を作成する
実務経験が不足している場合は、日常的に使うサービスを題材に、PdMの思考を練習する方法があります。ただし、見た目の改善案や機能アイデアを並べるだけでは、PdMの実績にはなりません。利用者の課題、事業上の狙い、優先順位、検証方法まで考えることが重要です。
改善案は、次の流れで整理するとよいでしょう。
- 対象となるユーザーを具体的に設定する
- そのユーザーが利用する場面を描く
- 現状の不便や達成できていない目的を特定する
- 解決策の仮説を考える
- 実現に必要な画面や機能を簡潔に整理する
- 成功を判断するための数字や観察項目を設定する
- 最初に試す範囲を決める
このように考えることで、アイデアを思いつく力ではなく、課題から改善案を組み立てる力を示せます。
プロトタイプと小規模な検証で実行経験を積む
PdM未経験者にとって、最も不足しやすいのは、仮説を形にして検証する経験です。学習だけで補うのではなく、小規模でも実際に試すことをおすすめします。社内の業務改善、コミュニティ活動、副業、個人プロジェクトなど、対象は限定的でも構いません。
たとえば、手作業が多い業務の流れを整理し、簡単な画面案や入力フォームを作り、実際の利用者に試してもらう方法があります。その際は、使いやすかったかを聞くだけではなく、利用中の迷いや操作の詰まりを観察します。
検証の規模よりも、仮説、実施内容、結果、次の判断を一連で経験することが重要です。うまくいかなかった場合も、なぜ想定と異なったのかを振り返れば、PdMとしての学びになります。
学習の目的を転職で示せる実績につなげる
資格取得や書籍学習は、PdMへの理解を深めるうえで有効です。ただし、学習歴だけでは選考での評価につながりにくい場合があります。学んだ内容を、実際の行動や成果物に結びつけることが大切です。
たとえば、ユーザー調査を学んだなら、現職でのヒアリング設計や調査結果の整理に活かします。データ分析を学んだなら、施策の評価指標を設定し、改善提案まで行います。開発知識を学んだなら、エンジニアとの要件調整でどのように役立ったかを説明できるようにします。
転職活動では、「学びました」ではなく、「学んだことを使って、何を変えたか」を伝えましょう。小さな実践でも、目的を持って継続した経験は、PdMへの本気度と成長意欲を示す材料になります。
PdM未経験でも選考で評価される実績の作り方
プロダクトの課題を特定し改善案を示すポートフォリオ
PdM未経験者がポートフォリオを作る場合は、画面デザインの完成度だけを競う必要はありません。重要なのは、課題をどのように発見し、なぜその改善案を選び、どのように効果を確かめるかが説明されていることです。
ポートフォリオには、対象サービスの概要、想定ユーザー、利用場面、課題の仮説、調査内容、改善案、優先順位、検証方法を含めます。実際の利用データにアクセスできない場合は、公開情報や自身の利用観察をもとに、仮説であることを明記しましょう。
完成度の高い提案に見せるよりも、前提条件が変わればどう判断を見直すかまで書ける方が、PdMとしての思考を伝えやすくなります。断定しすぎず、何を確認すべきかを示す姿勢が重要です。
コンサル案件の経験をプロダクト視点で再構成する
コンサル案件の経験は、プロダクト視点で再構成することで、PdM選考でも有効な実績になります。たとえば、業務改善案件であれば、単に業務フローを設計したのではなく、現場の困りごとを把握し、利用者がより少ない負担で目的を達成できる状態を設計した経験として説明できます。
システム導入案件であれば、要件を定義した経験だけでなく、誰がどの場面で使うのか、利用定着の障害は何か、導入後にどのような効果を確認したかに焦点を当てましょう。新規事業案件であれば、市場性の検討だけでなく、顧客価値の仮説をどのように検証したかを伝えると効果的です。
PdM選考では、顧客の要望を満たした経験よりも、利用者や事業にとって本質的な課題を見極めた経験が評価されます。案件の説明を、成果物中心から価値創出中心へ切り替えることがポイントです。
成果を事業への影響と数字で伝える方法
職務経歴書や面接では、成果をできるだけ具体的に伝える必要があります。売上、コスト削減、工数削減、利用率、満足度、処理時間、エラー件数など、案件に応じた数字を整理しましょう。
ただし、数字だけを示しても、自分の貢献が分かりにくい場合があります。成果は、課題、行動、結果の順で伝えると理解されやすくなります。
- どのような課題があったか
- 自分は何を担当し、どのような工夫をしたか
- 関係者をどのように巻き込んだか
- 結果として何がどの程度変わったか
- その経験から何を学んだか
たとえば、「分析を行った」ではなく、「利用状況を分類し、利用頻度が低い顧客層の課題を特定したうえで、導入手順を見直し、利用開始までの期間短縮につなげた」といった形で説明します。自分の判断と成果のつながりを示すことが重要です。
職務経歴書で強みと不足分を一貫して示す方法
PdM未経験の場合、経験不足を隠そうとするよりも、強みと補っている領域を一貫して示す方が信頼につながります。職務要約では、コンサル経験を通じて培った強みを、応募先のPdM業務に接続して書きます。
たとえば、戦略コンサル出身であれば、事業課題の整理、仮説構築、経営層との合意形成を強みにできます。総合コンサル出身であれば、業務理解、部門横断の推進、導入定着支援を示せます。ITコンサル出身であれば、要件定義、開発チームとの協働、技術制約を踏まえた計画づくりを強みにできます。
不足分については、「PdM経験がありません」とだけ書く必要はありません。代わりに、ユーザー調査、開発理解、改善検証などに対して、現職や個人活動でどのような実践をしているかを具体的に示します。学習と実践がつながっていれば、伸びしろを評価されやすくなります。
面接で問われる転職理由とプロダクトへの関心の伝え方
面接では、なぜコンサルからPdMに転職したいのかが高い確率で問われます。この質問では、現職への不満ではなく、PdMで実現したいことを中心に伝える必要があります。
たとえば、「提案で終わらず、利用者の反応を見ながら改善を続けたい」「特定の業界課題に長く向き合い、プロダクトを通じて変化を生み出したい」「事業と開発の両方に関わり、継続的な価値提供に責任を持ちたい」といった考え方です。
そのうえで、なぜその企業やプロダクトなのかを説明します。事業領域、ユーザーの課題、プロダクトの成長段階、チームの体制などを調べ、自分の経験がどのように役立つかを伝えましょう。PdMになりたい理由と、その会社を選ぶ理由がつながっていることが重要です。
転職後のギャップを乗り越えPdMとして立ち上がる方法
正解のない意思決定を自分で担う覚悟
PdMに転職すると、意思決定の責任を強く感じる場面が増えます。コンサルタントとして提案を行う立場では、最終判断は顧客や経営者が担うこともあります。しかしPdMは、自ら優先順位を決め、判断の結果に向き合う必要があります。
情報が不足していたり、関係者の意見が割れたりする中で、期限までに決めなければならないこともあります。このとき重要なのは、完璧な正解を探すことではなく、判断の根拠を明確にし、必要に応じて見直せる状態にしておくことです。
判断を誤らないことよりも、誤りに早く気づき、修正できる仕組みをつくることが重要です。仮説、前提、期待する結果を記録し、リリース後に検証する習慣を持つことで、意思決定の質を高められます。
顧客ではなくユーザーと事業に向き合う視点
コンサル経験者が陥りやすいギャップの一つは、顧客の要望を優先しすぎることです。PdMは、特定顧客の要望を実現するだけでなく、より多くのユーザーにとっての価値、事業としての持続性、開発チームの負荷を踏まえて判断します。
特に法人向けプロダクトでは、大口顧客からの要望が大きな影響力を持つことがあります。しかし、その要望が他の顧客にも価値があるのか、個別対応によってプロダクトが複雑になりすぎないかを検討する必要があります。
ユーザーに向き合うとは、要望をすべて受け入れることではありません。ユーザーの目的や困りごとを理解し、より多くの人に再現性のある形で解決することです。この視点を持つことで、顧客対応とプロダクト戦略のバランスを取りやすくなります。
提案で終わらず成果が出るまで改善を続ける姿勢
PdMの仕事では、リリースは終点ではなく、改善の出発点です。機能を公開した後に、ユーザーが実際に使っているか、期待した効果が出ているかを確認し、必要に応じて改善します。場合によっては、作った機能をやめる判断も必要です。
この継続的な改善は、短期間で成果物を出すことに慣れたコンサルタントにとって、最初は手応えを得にくい場合があります。小さな改善を積み重ねても、すぐに大きな成果が見えないことがあるためです。
しかし、プロダクトの成長は一度の大きな提案だけで実現するものではありません。利用者の反応を見ながら、仮説を修正し、チームで改善を続けることが重要です。成果物を納品する感覚から、価値が生まれ続ける状態をつくる感覚へ転換しましょう。
エンジニアやデザイナーとの信頼関係の築き方
PdMがチームを動かすためには、肩書きや権限よりも信頼関係が重要です。エンジニアやデザイナーに対して、仕様を一方的に伝えるだけでは、よい協働は生まれません。なぜその課題に取り組むのか、誰のどのような困りごとを解決したいのかを共有しましょう。
特にエンジニアとの協働では、開発期間や技術的な制約を尊重する姿勢が必要です。実現できないと伝えられたときに押し切るのではなく、何が難しいのか、別の方法なら実現できるのかを一緒に考えることが重要です。
デザイナーとは、見た目の調整だけではなく、ユーザーにどのような体験を提供したいのかを議論しましょう。PdMが目的と背景を明確に共有すれば、チームメンバーは専門性を活かしてよりよい解決策を提案しやすくなります。
入社後90日で取り組むべき理解と成果づくり
入社後の最初の90日間は、早期に大きな成果を出すことだけを目指す期間ではありません。会社、プロダクト、ユーザー、チームの文脈を理解し、周囲から信頼を得るための重要な期間です。最初からすべてを変えようとせず、理解と小さな成果を両立させましょう。
最初の30日間は、プロダクトの利用者、主要な指標、過去の意思決定、開発の進め方、関係者の役割を理解することに集中します。ユーザー対応や営業同行、カスタマーサポートの問い合わせ確認、開発会議への参加などを通じて、一次情報を集めます。
31日目から60日目は、把握した課題の中から、自分が責任を持つ領域を定めます。すぐに改善できる小さな課題を一つ選び、関係者と協力して進めるとよいでしょう。この段階では、大きな改革よりも、約束を守り、判断の根拠を共有することで信頼を積み上げます。
61日目から90日目は、学んだ内容をもとに、改善案や今後の優先順位を提案します。自分だけで決めるのではなく、ユーザー、開発チーム、事業側の意見を踏まえ、判断の背景を示すことが重要です。入社後90日で目指すべきなのは、すべてを理解することではなく、チームと共通認識を持ち、自律的に改善を進められる基盤をつくることです。
