プロダクトマネージャーの書き溜め

エンジニア出身のプロダクトマネージャーが学んだこと、気づいたことを書き溜めていくブログです

エンジニアからプロダクトマネージャーにキャリアチェンジする方法

最近エンジニアのキャリアの選択肢としてプロダクトマネージャーが注目されていると思います。
私自身エンジニア出身のプロダクトマネージャーということもあり、ちらほらご相談を受ける場面もあります。 そういったご相談に答えたり、他サービスのプロダクトマネージャーをされている方とお話しをする中でエンジニアからプロダクトマネージャーにキャリアチェンジする方法がある程度まとまってきたので記事に書き出してみようと思います。

結論

色々方法はあると思いますが、基本的には「社内でのプロダクトマネジメント業務経験、もしくは近しい業務経験を行い、経験値を貯めてから転職をする」が一番確度が高いと思います。

なぜ上記の結論か

上記の方法以外にもエンジニアからプロダクトマネージャーを目指す方法はいくつかあります。自分の思いつく範囲だと以下が挙げられます。

  1. プロダクトマネジメント未経験の状態での転職
  2. プロダクトマネジメント経験を副業、個人開発で積み転職する
  3. プロジェクトマネージャー経験を社内で積み、プロダクトマネージャーとして転職する

ただ、1番だと取ってもらえる可能性が限りなく低いですし、2番もあまり評価されない印象です。3番は本質的に全く異なるポジションですが割と聞く転職パターンではあります。ただ現在エンジニアなら、プロジェクトマネージャーになって数年経験を積んで、、と考えると長期計画になってしまうのでこちらも難しそうです。そのため消去法で「結論」に書いた方法が一番確度が高いなと思います。

具体的な方法

「結論」に「社内でのプロダクトマネジメント業務経験、もしくは近しい業務経験を行い、経験値を貯めてから転職をする」方法が良いと書きましたが具体的にどういった業務経験を積んでおくと良いかをまとめます。

1. プロダクト課題の洗い出しの経験

プロダクトを長く使ってもらうには「ユーザー体験の向上」「利益の向上」を継続して実現していくことが不可欠です。それらを実現するために現状のプロダクトに足りないことは何なのか、どういったところに課題があるのかを明らかにする経験です。

SaaSの例を挙げると

  • 申し込み相談のCVRが下がっている
  • 申し込み相談から申し込みへのCVRが下がっている
  • 契約3ヶ月以内のチャーンレートが上がっている
  • 1ヶ月を過ぎると徐々にログイン率が下げる
  • LPへの流入が下がっている
  • 特定のページでエラーが発生して操作ができなくなる

などです。

2. 課題の優先度の設定の経験

洗い出した課題をどのような優先度で解決していくかを設定します。優先度の判断基準は基本的には「ユーザー体験の向上」「利益の向上」に対してよりインパクトを与えられるものから優先して対応します。

1番に記載した例を考えてみると

  • そもそも、申し込み相談のCVRが下がっているのはLPへの流入が下がっているのが原因かもしれない
  • 特定のページでエラーが発生して操作ができなくなる問題は既存ユーザーのチャーンに影響するため、最も優先度を上げて対応する。ログイン率が下がったり、チャーンレートが上がっているのはここに起因するかも

など、課題の構造を考えながら優先度を振ります。

3. 課題の深掘り、課題を構成する要素の洗い出しの経験

解く課題の優先度付けを設定できたら、最初に解く課題の深掘りを行います。課題は表面に出てきている問題で、原因はもっと深くに存在します。

  • 例: 「LPへの流入が下がっている」に対しての深掘り
    • 流入チャネル周りに問題が起きている
      • オーガニックからの流入に問題が起きている
        • SEO順位が下がったことによりクリック数が下がった
        • 他社の広告が検索上位に表示されることによりクリック数が下がった
      • SNSからの流入に問題が起きている
        • SNSでのサービスシェア数が減ったことによりリンクのクリック数が下がった
        • OGPがうまく表示されていない
        • SNS自体に問題が発生している
      • 広告からの流入に問題が起きている
        • 差し替えたバナー画像の影響
        • 新たにスタートした広告パターンの影響
    • 技術的な問題が起きている
      • LPの表示スピードが遅くなり、ユーザーの離脱率が下がった
    • ビジネス的な問題が起きている
      • 他社サービスにユーザーが流れている

このように課題が発生している原因を特定できるまで深掘りを行います。(本当は、具体的に改善すべき場所が特定できるまで深掘るべきです。この辺りのポイントは馬田 隆明さんの著書「解像度を上げる」に詳しく載っています。)

また、定量・定性データを交えながら、この要素は本当に存在しているのかも確認しておきます。

4. 課題を構成する要素を解く優先度の設定の経験

3番で深掘った要素をどのような順番で解いていくかを設定します。ここも課題解決においてのインパクトがある順で解いていくのが基本パターンです。

5. 課題を構成する要素を解決するための施策立案の経験

優先度の順位付けができたら、最も優先度の高い要素を解決するための施策を考えていきます。 施策案を練り、PRDに書き起こします。自分のチームではPRDは以下のような項目を書いています。

  • 施策番号、タイトル
  • 施策概要
  • やる意図、期待する結果
  • 具体的なタスク
  • 計測対象のKPI
  • 計測方法
  • フィードバック

施策の指示書だけでなく、タスク管理、フィードバック管理も兼ねている作りです。こちらは会社によって異なると思いますが、自分たちはこのようにやってます。こうしろというわけではなく、各社にあった型をやりながら見つけていくのが良いと思います。 このフェーズでワイヤーフレームなども書きます。

6. 開発をリードする経験

エンジニア・デザイナーとコミュニケーションを取り開発を開始します。自分のチームだと、プロダクトマネージャーがワイヤーフレーム・PRDをデザイナーに共有し、デザインを作りつつ、エンジニア側でワイヤーを元に仮デザインを設定して実装、デザイン出来上がり次第反映のような手順を取っています。また広告・PRなどの部署とも必要に応じコミュニケーションを取ります。

7. 施策実行・フィードバックの経験

機能をリリースし、効果を計測します。課題が解消しきれていなければ別の要素へのアプローチを試みたり、要素の構成自体を見直します。課題が解消できたら次の課題の対応に移動します。

以上が基本的な業務経験になります。「自身で課題を特定して要素分解し、施策を立案・実行し数字を改善した」経験がとても重要なので、エンジニア業務をしながらそういったところに関われないかチャレンジしてみてください。これらの経験を積み成果が出せたと考えたタイミングで転職活動を行ってみて問題ないと思います。 面接のポイントなどはまた別記事で書ければと思います。