経験が裏目に？！大手IT企業出身PdMが3カ月で学んだこと

ogp

はじめに

この記事は enechain Advent Calendar 2023 の17日目の記事です。

enechain で Product Manager をしているokpです。本記事ではenechainでPdMデビューした私が、どんな壁にぶち当たり何を学んだかを紹介します。異職種や異業種からPdMを目指す方にとって、少しでも参考になればと思っています。

PdMの役割はそれぞれ

前職ではマーケティング部に在籍し、10年ほどBtoCサービスのWEBディレクターを務めていました。数字を元にした課題や仮説をもとに、キャンペーンの開催やプロダクト改善をしていました。「PdMという肩書きは初めてだけれども、プロダクト改善経験はちょっとはある」という自信をもとに enechain に入社しました。けれど、MTG内でビジネスチームのリクエストをキャッチアップできなかったり、要件定義完了の直前で根幹の仕様を変えてしまったり、同じチームのエンジニアを混沌の渦へと突き落とし続けてしまいました。

振り返ってみると、過去の経験に縛られてしまって、PdMとしてプロダクトのフェーズに合った適切な振る舞いができていなかったと感じます。PdMの仕事内容は、横断的な定義があるわけではなく、担当するプロダクトやフェーズ、チームメンバーによって異なってくると考えています。特定のスキルがある、これをやれば正解といったものが無いとも言えます。過去の成功体験よりも、今目の前にある課題にいかに対応するかを考える能力が重要だと感じさせられました。

前職の場合、プロダクトは既に成熟期に入り、ビジネスモデルは完成しており、グループサービスの機能を利用しながら、更なる成長を目指して新しい起爆剤を探しているフェーズでした。既に一定数のコアユーザが毎日使用している状態で、認知度も十分獲得できており、課題はDAUやMAUを指標としたユーザーの活性化でした。マーケティング部に所属していたこともあり、週次のMTGで仮説を元にした数字の説明、それに対する具体的な打ち手を提案、翌週には仕様書に落とすといったことを、長年にわたってやっていました。チームの構造的にチーム間で連携して物事を決定するのではなく、分析を元に提案をした後は、自分の決定のものと実施まで完了させるというスタイルでした。

	前職	現職	感じたギャップ
業界	BtoC	BtoB	ドメイン知識不足による仮説の解像度の低さ
サービスのフェーズ	成熟期or延命期	成長期	過去のデータを元にした仮説が作れない
ポジション	マーケティングチームのウェブディレクター	TECHチームのPdM	ビジネスチームの課題感の変化をタイムリーにキャッチできない
TECHチームの動き方	機能単位にまで落とし込まれた定義書を元にリソースを確保、ゴールは仕様書の実現	ビジネスチームの課題をシステムを用いて解決がゴール	解決策のアイディアはTECH主導

現職の場合、プロダクトは成長期であり、新しいビジネススキームの立ち上げが多いです。ビジネスチームの要件をヒアリングし整理、何が必要とされ求められているかを理解した上で、エンジニアと情報共有していくという流れ。文字にすると何ともないのですが、ビジネスチームが持っている課題を背景や前提を元に的確に理解し、WhyとWhatをエンジニアに共有することがスムーズにできませんでした。対エンジニアへの共有のタイミングで、理解不足が露呈し手戻りが多く発生、コミュニケーションコストばかりかかったという顛末です。前職までは課題の把握から解決策の実施までの決定権が自分自身にあったため、問題なく進めてこれていたということに気づきました。

学んだこと

この3カ月の経験で学んだことは、大きく3つあります。

1：自分だけで物事を進め、解決策を探らないこと

ビジネスチームとのMTG全てにエンジニアを巻き込むことは非効率ですが、同席してもらった方が効率的な場面が往々にしてありました。特に急な手直しでその場で仕様の決定をする必要がある場合、ビジネス背景や課題についてビジネスチームからヒアリングする場では有効でした。

一度、仕様の急な変更が起こり、PdMだけが呼ばれビジネスチームで考えている解決策の共有を受けたことがありました。急遽、エンジニアも同席したことで、想定よりも良い改善案を即座に決定でき、修正までの時間が大幅に削減されました。PdMは、全体像を理解した上で方針決定・提案できることが理想ですが、PdMだけで方向性を決めなければいけないという思い込みは時としてボトルネックになってしまいます。状況に応じて早めにヘルプを出して、チームとして課題に取り組むことが最適だと学びました。

2：ビジネス側の意思決定フローや状況について、できるだけ情報収集すべき

仕様変更や機能追加の依頼を受けるタイミングでは、例えば「CSVでデータ登録できるようにしたい」といったHowから飛び込んでくる場合も多いです。これをそのまま対応してしまうと、最適なソリューションにならない事も多々あります。こちらからヒアリングをするとリクエストに至った経緯や背景は理解できるものの、Why/Whatを聞き出すためには相応のヒアリング能力が求められます。

ある飲み会の席で、接点のなさそうなチーム内のやり取りについて話題にしたエンジニアがいました。話を聞いていると、担当プロジェクト以外のSlackのやり取りやNotionの議事録も読み込んでおり、会社全体として何が起こっているかを把握していました。エンジニアもそこまでやっているのだから、PdMの自分はそれ以上に能動的に情報を集めにいかなければ！と感じています。説明されていないから、アサインされていないから知らないではなく、情報を拾いにいく姿勢が必要だと考え、できるだけ情報アンテナを広げるようにしています。

3：理想像を描き、現実を見て実装すべき

自分の失敗談として、ビジネスチームの理想を細かくヒアリングして整理し、それをエンジニアに提案しようとしていた時期がありました。大風呂敷を広げた未来の話から直近の話まで聞いた上で、ロードマップを作って要件を詰めていくことを試みたのです。頻度高くMTGをしていましたが、結局うまくは行きませんでした。実はビジネス側でもプロダクトの理想像が明確には描けておらず、新たな課題が発生するたびに優先度にブレが生じてしまっていました。

問題点は2つあったと理解しています。 1つは、プロダクトオーナーシップをビジネス側にも持ってもらうべきだったという点。プロダクトの理想像を描いてもらい、その上で直近の課題への対応と理想に向けた開発のどちらを優先すべきか考えてもらうことが重要でした。もう1つは、あまりにも先のことまで考えてしまった点。理想はあれど、不確実性が高すぎて実装要件に落とし込めないものも多々有りました。理想を頭に置いた上で、どんな実装が出来るかを地に足をつけて考えることが重要でした。このような気づきを元に、今ではプロダクトとして実現したいことをビジネスチームにも描いてもらい、スピード感を持って実装が進む単位で優先度付けをして開発を進めているところです。

最後に

電力業界、PdMという職種、共に初めてのチャレンジでしたが、enechainという環境のおかげで思考の強化や整理が格段にできるようになりました。enechainにはさまざまなバックグラウンドを持ったエンジニア、ビジネスメンバーが在籍しており、言葉での説明を丁寧にしてくれるメンバーが多いです。些細な質問や疑問に対しても、言葉にして論理的に説明をしてくれ、曖昧な質問を投げかけても咀嚼し言い換えてくれます。この環境は、説明力や情報整理、調整力が求められるPdMという職種にとって日々研鑽できる貴重な場だと考えています。

2024年は新しいプロダクトも始動予定です、どんな刺激と壁が待っているか今から楽しみです。明日はデザイナーKeiさんです。

enechainでは、一緒に事業を拡大していける仲間を絶賛募集中です。 herp.careers