エンジニア出身プロダクトマネージャーで良かったこと
最近は新卒でプロダクトマネージャーになる方も多いと思うが、CS、デザイナー、エンジニアなど何らかのキャリアが元々ありその延長でプロダクトマネジメントに関わっている方が多数だと思っている。
自分はエンジニア出身のプロダクトマネージャーだが、エンジニアというバックグラウンドがあって良かった点を考えてみた。
良かったこと1: 解決策の実装方法を深くコントロールできる
課題に対し、解決アプローチを決定し仕様を引いていくが実装するアプローチは複数考えられると思っている。
例えば、まず機能ニーズがあるか検証したいので簡易的に実装し、ニーズが確実にあると考えられる場合、正実装するようなアプローチ。また短期間のキャンペーンでの運用なので工数かけず実装したい。既に成功事例があるため検証せず、正実装したい。など。
そういった解決策の実装をエンジニアとすり合わせる際、認識がずれない点はとてもプラスに働いている。認識がずれない理由は
の2点によるものだと思っている。技術の知見がないと、思った以上の工数がかかっても「そんなにかかるのか〜」程度の認識で止まってしまう。結果思っていたより複雑な実装がなされてしまった、という失敗はよくあると思う。素早くPDCAを回す上でこういった不要なコストアップは命取りなので、そういった失敗を回避できる意味でエンジニアの経験があってよかったと思う。
良かったこと2: 技術的に実現できない、必要以上に難易度の高い仕様を設計する心配がない
技術の知見がないと既存の技術仕様を考慮していない仕様を作ってしまい、エンジニアと衝突する場面が考えられるが技術の知見があるとそういった問題起こりにくいし、起こったとしても解決アプローチを発想しやすい。
良かったこと3: SQL等分析業務のキャッチアップ工数がかからない
SQLはバックエンドエンジニアであれば当然使いこなせる。Pythton・Rなど使う局面があったとしても柔軟に対応できる。(自分は分析業務において使用したことはまだないが)
データエンジニア・データサイエンティスト・リサーチャー等いれば対応する場面は少ないが、規模が小さい組織ならプロダクトマネージャーが兼任している場面も多いと思うので、そういった場合はプラスに働くと思う。
強みと弱みは隣り合わせ
個人的に良かったと考えられるポイントは上記の通りだが、これは常に弱みに転じる可能性があることも強く認識しておきたい。
解決策の実装方法を深くコントロールできる点は、上手くコントロールできればプラスに働くがついついマインドが解決策をどう構築する側に傾いて、課題の分析がおろそかになってしまう危険がある。(自分は注意していないとたまに起こる、意識しないとプロダクトファーストになりがちなのはエンジニア->プロダクトマネージャーにキャリアチェンジして最初のうちの問題あるあるだと勝手に思っている)
技術的に実現できない、もしくは難易度の高い仕様を組まないという点は技術側にとっては好都合だが、その実装がもしかしたらユーザーにとって最も良いアプローチだった可能性も考えられる。常識の範囲内の凝り固まった仕様しか練れなくなるかもしれない。時には大胆に考えることをマイルールにしている。
分析業務が容易に実行できる点も、プロダクトマネージャーがチームのボトルネックになっているような局面ではマイナスに働くかもしれない。チーム状況によってはだれかに分析だけ任せる判断も必要。
このように強みと弱みは常に隣り合わせだと思っている。エンジニアとしての経験をプラスに発揮できるプロダクトマネージャーであれるよう日々気をつけて取り組みたい。
