プロダクトマネージャー向け職務経歴書テンプレート — 事業指標と意思決定の数値化
PM 職務経歴書は『担当プロダクトの事業指標 + 意思決定プロセス + エンジニア / デザイナー / セールスとの協業様式』の 3 軸で再現性を示すのが勝ち筋。冒頭でプロダクトの成長フェーズと自分の責任範囲 (Discovery / Delivery / Go-to-Market) を宣言するとミスマッチが減る。
60 秒で完成させる 5 ステップ
- プロフィール入力 (氏名・連絡先・SNS / 登壇資料 / note)
- 担当プロダクトの成長フェーズ (0→1 / 1→10 / 10→100) と自分の責任範囲を冒頭 3 行で宣言
- 直近 3 プロダクトを『事業指標 (MAU / NRR / CAC / LTV) + 意思決定プロセス + リリース結果』で整理
- 使用フレームワーク (OKR / NSM / RICE / Kano / JTBD) と実務適用事例を一覧化
- ResumeForge の AI 提案機能で 3 案比較 → 採用 → PDF ダウンロード
書類通過を上げる 5 つのポイント
- 『担当プロダクトの事業指標 (MAU / ARR / NRR)』を必ず書く。事業規模なしでは PM レベルが読めない
- 意思決定プロセス (発見インタビュー → 仮説 → A/B テスト → リリース) を具体手順で書く
- リリース成果は『リリース前予測 → 実測 → 学び』の順で書くと再現性が伝わる
- エンジニア / デザイナー / セールスとの『交渉・合意形成』具体事例を 1 件は入れる
- 失敗経験と学びも 1 件書くと信頼される。成功だけの PM は疑われる業界慣習
業種別のサンプル文言
AI が 3 案を提示する際の下書きとしてそのまま使えます。
BtoB SaaS で PM を 4 年、直近 2 年は年 ARR 4.2 億円プロダクトの Senior PM として Growth + Retention 領域を責任範囲としました。North Star Metric (週次アクティブ組織数) を 320→720 組織、NRR 104%→128%、新規顧客の Aha Moment 到達率 42%→73% を実現。エンジニア 8 名 + デザイナー 2 名のチームで月 14〜18 リリース、OKR + RICE 優先順位付け + weekly GTM 同期を運用。外部登壇 3 件、社内 PM ラダー策定に寄与。
【Situation】年 ARR 成長率が 18→9% に鈍化、既存顧客の ACV 拡大が停滞。【Task】料金体系の再設計 PM (エンジニア 4 名 + セールス 6 名 + CS 3 名 + CFO 連携)。【Action】既存 140 顧客の利用パターンを 6 セグメントに分類 → 3 プラン + 従量課金の組み合わせを設計 → 12 社パイロット → 全社 GA。【Result】GA 後 6 ヶ月で ACV +38%、NRR 104%→128%、チャーンへの影響は -0.4pt と最小化。学び: 『従量課金の閾値設計は顧客の予算周期と合わせる』を PM 虎の巻として社内共有。
『ビジネス・エンジニアリング・デザイン・顧客の 4 者で意思決定に耐えるナラティブを作る』ことが強みです。数値だけ、or 直感だけに偏らない論点整理 (データ + 仮説 + 予測 + リスク) をテンプレ化し、四半期毎の RoadMap Review を 60 分で終わらせる運用を作ってきました。貴社の 10→100 フェーズで、プロダクトの複雑性と組織の多軸を横串で束ねる役割に貢献したいと考えております。
ATS 通過に効くキーワード
求人票 (JD) と書類の一致度を高めるため、経歴に合うものを自然な形で本文に含めます。
- プロダクトマネージャー
- プロダクトオーナー
- PM
- PO
- ロードマップ
- ユーザーインタビュー
- 仮説検証
- A/B テスト
- OKR
- NSM
- North Star Metric
- RICE
- Kano
- JTBD
- MAU
- DAU
- NRR
- CAC
- LTV
- アジャイル
- スクラム
- BtoB SaaS
- BtoC
- Growth
よくある質問
- Q. エンジニア出身 PM とビジネス出身 PM、職務経歴書の書き分けは?
- A. 出自に応じて『技術判断 or 事業判断のどちらに寄れる強みがあるか』を冒頭で宣言します。エンジニア出身なら『アーキテクチャと事業戦略の接続』、ビジネス出身なら『定量分析と顧客インサイトからの意思決定』を前面に。応募先が求めている軸と合致させて書くと通過率が上がります。
- Q. 失敗プロジェクトは書くべきですか?
- A. 書きます。PM の実力は失敗からの学びで測られるため、『失敗 1 件 + 学び + 次回適用事例』のセットで必ず 1 ケース入れます。失敗を隠す経歴書は採用側に『省察力が弱い』と判断されがちです。
- Q. PM 未経験 (例: エンジニア / コンサル → PM) の転職では?
- A. 『現職で PM 的役割を担った事例』を必ず 1 件は書きます。例: コンサルの PJ 設計、エンジニアの機能提案 + 実装、セールスの顧客要望の事業化。『正式な PM 役職でなかったが、意思決定・優先順位付け・ステークホルダー調整を担った経験』として翻訳し、志望動機で PM の型 (発見 → 検証 → 優先順位付け) への学習姿勢を示します。
このテンプレートで書類を作る
AI が 60 秒で 3 案を提示 · カード不要で 3 日間 Premium 無料
このテンプレートで書き始める →