ほぼ未経験ながら第2新卒でプロダクトマネージャーに転職できた方法
はじめに
タイトルの通り、先日約２か月に及ぶ転職活動が終わって、無事プロダクトマネージャー（候補）としてキャリアチェンジできました。詳しくは別で書こうと思いますが、次はリアル産業DXのプロダクトにジョインします。
今プロダクトマネージャー（以下PM）という職種がホットになる中で、未経験の状態からキャリアチェンジできた事例がまだ少ないです。
なので、
・第２新卒の比較的早い段階でPMになれたこと
・Bizサイドからキャリアチェンジできたこと
この2つの点で、今回の事例はユニークだと思うので、今後転職を考えている人の参考になればと記事を書くことにしました。
前置き少し長くなりましたが、軽く自己紹介させてください。シェアリングサービス（ToC）のスタートアップで約2年半グロースハックに携わっていました。
具体的には、新機能の企画や既存機能の磨き込みを担当していました。PMという肩書がないので、対外的には「PM」「グロースハッカー」みたいに伝えています。
テーマと結論
PMの肩書がないことから分かるように、いわゆる「プロダクト開発組織」が整っていない会社からどうやってキャリアチェンジできたのか？をお話できればと思います。
具体的にこの記事では「実績をどう作るか」にフォーカスします。ほとんどのPM募集は経験ある人を対象にしているため、PM未経験だと応募できません。「実績を積もうにも積むチャンスがないのでPMになれない」問題が発生してしまいます。
この問題に対する解決策は、現職でPMらしい動きをするに尽きます。
もう少し詳しく言うと、「教科書的な理想の手順を踏もうとせずに、組織の強みを活かして、自分ひとりでPMぽく動く」が大切になります。どうやって実践したらよいか、N=1ですが実体験をもとに話します。
読んでほしい人
・未経験でPMに転職しようとしている人
・社内にPMがいない中で、どう実績を出せばいいか分からない人
実績づくりどうすればいい？
未経験でも実績が必要な理由
前提としてなぜ実績が必要なのかというと、採用する側から考えると「自分はPMに向いていると思う」「PMになりたい」という感想よりも、できる範囲でPMぽく動いてみた事実があるほうが安心して採用できるからです。
これはユーザーヒアリングと似ていると思います。本当に顧客が困っていて、解決すべき課題があるなら「課題を解決するために代替手段を使っている」「実際にお金を払ってくれる」はずなので、解く価値がある課題か見極めるためにPMはユーザーヒアリングを実施するはずです。
転職時のPMを面接官と考えるなら、PMとしてやっていけると思ってもらうには、実際に行動したファクトが必要です。
どうやってPMぽく動いたか
具体的にどう動いたか、の説明に入る前に前提を説明します。
入社の経緯
学生インターンののちアルバイトで入社、その後社員登用で正社員に
期待されたこと
アプリ内施策を提案すること（当時施策を提案するメンバーがいなかった）
普段の進め方
「今何をやるのか」「どうやって解決するか」から考えて上長（＝執行役員）に提案する
※自分でやることを考える文化だったので、上からやることを指示されることがない
上に書いたように、前提として自分の仕事（やること）は自分で生み出す文化だったので、何をするか・どう動くかを比較的自由に決めることができました。
上長が期待していたことは、事業を伸ばすような施策を考え提案すること（その先によい施策を拡大させること）だったので、PMぽく動くことは施策を生み出す考え方を変える（＝How）部分で影響が少なかったです。
なので「PMぽくやる」と周りに宣言したわけではなく、提案方法や提案の前段階を自分なりに工夫しただけでした。
最初はアプリ内のポイント付与のキャンペーン施策を企画していましたが、PMになりたいと思ってからは、機能の行動ログとアンケートの回答を分析して、「どんな課題を持っている人がどのようにアプリを使っているか」ファクトを集めました。そして、KGIの達成に沿う形で一番インパクトが出せるであろう施策を考えました。
例えばKGIが有料会員数を伸ばすことだった場合、新規ユーザーの集客or既存ユーザーのチャーン抑止のどちらかに注力する必要があります。チャーン抑止が有効な場合、
・どんな理由でのチャーンが多いかアンケート分析
・該当理由でチャーンした人はどんな行動をしているかログ分析
・不満理由を解決する機能/訴求を考え提案する
のようなステップで施策提案しました。
ここで大事なのは、教科書的なPMの立ち回りは真似しないことです。ユーザーヒアリングをする。プロトタイプ検証をする。そういった1つ1つの手段をやることがプロダクト開発と捉えるのではなく、事業・プロダクトを伸ばすために最適な手段を選択するスタンスの方がいいです。
「誰がどんな課題に困っていて」「どんな価値を提供すればいいか」さえ分かればいいので、目的が達成できるならどんな手段でもよいです。
Biz側の人は「事業目標や事業戦略の意識が強い」「誰がどんな課題に困っているかの解像度が高い」といった特徴があると思うので、PMになる場合こんなことに気を付ける/意識するとよいと思います。
・顧客課題を解決すると事業目標が達成するかを意識する
・その課題は新たに解く価値があるか検討する
（既存の機能や訴求や顧客対応フローの見直しで解決できる場合もある）
・エンジニアさんと信頼関係を築く
1・2つ目は自分次第で変えられる部分ですが、3つ目も結構重要です。実は私自身が苦労した部分なのですが、「施策の実行が決まったものを依頼する」マインドだと信頼は生まれません。
施策をやるか、と実際にどんな機能を実装するかは別フェーズの問題です。施策の実行可否は上長と決めてもいいですが、実装する機能はエンジニアさんと相談しながら作った方がうまく行きます。
実績づくりで一番大切なのはアウトカム（成果）です。狙った通りの価値提供ができたかを数値でみると同時に学ぶことが大事です。
仮に価値提供ができてたとしても、「もっとユーザー数を広げることはできないか」「+αの価値提供ができないか」などユーザーの反応から学び、次の実装に活かしたほうが事業成長にもつながりますし、面談での実績を話す時でも話に奥行きがでます。
社内にプロダクト開発の知見がない場合は？
PMぽく動きたいが、プロダクト開発に理解を示す人がいない。あるいは、教科書的なプロダクト開発ではない。こんな不満を持っている人もいるかと思います。
結論をいうと、
・上長含め周りのメンバーがプロダクト開発の知見を持つことに期待しない
・教科書的な理想のプロダクト開発を追わない
・自分ひとりで自己流プロダクト開発をやってみる
がおすすめです。
例えば、現職の場合はユーザーヒアリングやプロトタイプ検証をする習慣がありませんでした。またエンジニアチームが社内受託のような形になっており、施策提案者が作った仕様通りに開発する体制でした。
PMを目指した初期は、こうした環境に不満を持って「理想的なプロダクト開発ができるよう説得したい」と思っていました。
しかし今までのやり方に慣れている人の考え方を変えるには労力がかかるので、違う手法をとることにしました。
一般的に紹介されるプロダクト開発は、「顧客が何を求めているか分からない」不確実性を減らし、早く正解にたどり着くための1手法なので、組織にフィットしない部分は組織の強みに合わせて変えても良いはずだからです。
具体的には、ユーザーヒアリングはせずに行動ログやアンケート分析から顧客の課題仮説を出すようにしました。また上長と話して、仮説が確からしいとなったら、実際に機能を実装しABテストを実施しました。
現職の場合、「若手が意見するときはデータが必須。逆にデータがあれば意見が通る」文化でした。良くも悪くも定量情報を重視するので、定性情報を見ようと訴えても受け入れられる可能性は低いと考え、定量から仮説立案するようにしました。
PSFの検証も元々やっていないので、フローとして組み込むことをやめ、実際にリリースしてから顧客の反応をみるように変えました。そしてABテストで反応を確かめ、数値が改善しない場合にヒアリングの手段を持ち込むようにしました。
エンジニアさんが仕様書をそのまま作る問題については、ラフに仕様を作った後に相談しに行ったり、わざと工数がかかるような機能を提案して相手からアイデアを引き出すなどコミュニケーションの工夫をしました。
このように社内に体制が整っていなくても、1人でやり方を変えられる部分はあります。確かに教科書に載っている手順は「ベストプラクティス」ではありますが、組織状況によっては求めすぎな部分もあります。今ある環境や状況を使って、顧客が求めていることの不確実性を少しでも下げられないか？を考えて手早くできる方法を模索してみてください。
実際に転職活動するときの注意ポイント
一定の実績が作れたら、いよいよ転職活動スタートになりますが、実績が少し作っても、有名スタートアップやベンチャーに採用されるわけではないです。PMぽく動けるのとPMには壁があるので、一足飛びで有名企業のPdMを目指さず、ポテンシャルならではの強みを活かせる環境でPdMになった方がいいです。
ポテンシャル採用を目指すときは、ぜひPMの肩書へのこだわりを捨ててみてください。転職活動のなかで、役割・職種は事業を成長させる手段でしかないと痛感しました。事業の成長を実現するためにメンバーがいて、その中で顧客の課題を深くとらえて解決策を考える人をPMと呼ぶイメージです。
実際、PMの肩書に拘り過ぎてお見送りになったこともありますし、面談の中でPM（肩書）は手段でしかないよねという会話が何度もありました。
PMの肩書にこだわらなかった場合、取れる選択は広がります。実績を作った時点で「職域を超えて、ユーザー価値を高めようと主体的に動ける」 「コラボレーションできる」と評価できるので、その価値を最大限活かせる場所を探すとよいと思います。例えばこのような場所です。
・知名度が高くないスタートアップや新規事業を多く生み出すベンチャー企業
・役割に人をアサインする方法ではなく、メンバーにあわせて役割をデザインする企業
ある程度候補が見つかったら、PMの人数や有名スタートアップやベンチャー出身の人が開発チームやPMにいるかなどを確認してみるとよいです。
最後に
4,000字を超える長文を読んでくださりありがとうございます。転職活動を振り返ると、プロダクト組織が整っていない中でPMらしく動く方法を模索し、自分なりに答えを出す作業/期間だったように思います。
いい意味で理想の環境ではなかったからこそ、教科書やイベントの知識を現実の場面に落とし込む方法を考える癖がつきました。
分かったような口調で書いた部分もありますが、まだまだPMとして未熟でここからが勝負だと思っています。今回ご縁があって、PMとしてリアル産業DXプロダクトにジョインしますが、ジョインしたからには1日でも早く多くの人に価値提供して非連続の成長を達成できるようにしたいです。
引き続き事業家人材として突っ走っていきますので、応援よろしくお願いします。