POLのPdMになりました！
（※2022年9月1日より、社名がPOLからLabBaseに変更となりました。
記事内で旧名の記載が残っている箇所がありますがご了承ください。）
はじめまして、株式会社POLでPdMを担当している あやぱん と申します。
2019年に新卒入社し、3年間のカスタマーサクセス（以下CS）を経験したのち、2022年の3月よりプロダクトマネージャー（以下PdM）をしています。
主に「LabBase」という理系新卒スカウトサービスに携わっております。
CS→PdM異動の理由
より良いプロダクトにしたい
CSでは、理系を採用したいクライアントに対して「サービス導入後、早期に価値を実感してもらうこと」を目的に、サービス導入支援とその品質向上を行なっていました。
例えば、利用開始に向けたKick Offや、サービス利用説明、利用状況のウォッチ、利用促進のアプローチ、それらの改善と仕組み化などです。
クライアントに価値を感じてもらい利用を継続・拡大してもらうためには、もちろんプロダクトによる価値提供が重要ですが、
それ以外にも、人力でのサポートや他部署とのコラボ、別サービスのクロスセルなど、あらゆる手段を最大限に用いてアプローチしていました。
CSの仕事は、やりがいの大きいものでした。
クライアントの課題を解決するために能動的に働きかけるというスタンスがとても面白かったですし、
クライアントと直接会話ができるので、サービスの利用状況をよりリアルに理解できたり、利用成功の瞬間に立ち会うことでサービスの価値が実感できたりしたためです。
しかし、それと同時に、別の想いも生まれました。
それは "プロダクト自体の価値をもっと上げたい" というものです。
プロダクトの力でクライアントを成功に導きたい、
CSがより難易度の高い課題解決に集中できるようにしたい、
クライアントと近い距離にいたCS出身者の観点を入れることで、そこに近づきやすいのではないか、と思うようになりました。
さらにいうと、私は プロダクトドリブンな会社 に憧れを持っていました。
スタートアップ企業は「先進的な技術（テクノロジー）やアイデアを強みに、ゼロから市場やビジネスモデル創出に挑戦する成長速度の早い企業」と定義されますが、私の興味は アイデアを形にするテクノロジーやプロダクト にありました。
どんなに素晴らしく素敵なアイデアがあっても、形にならないと届かなくて、そんなアイデアを形にしてくれるのがプロダクト開発チームだと思っています。
私は彼らへの強い憧れと敬意の念を持っていました。
技術を保有し、日々磨き続け、何かを生み出すエンジニアさんデザイナーさんは、私にとって尊い存在です。
彼らのような存在が、全社をリードし、みんなでものづくりをしていけるプロダクトドリブンな会社 がとってもかっこいいなと思っています。
そんな背景から、プロダクトをもっと良くしていきたい、そしてそこに携わりたいという想いが強くなっていきました。
PdM検定との出会い
そんな想いが生まれてきた時に、たまたま社内でPdM検定という社内制度が新しく誕生しました。
PdM検定とは、全ての正社員に受験する資格があり、プロダクトマネジメントに関する特定のテーマに対して企画書を作成・発表し、それに対して評価・合否を受ける検定のことです。
この検定により、サービスを魅力的にしていきたいと思うメンバーが増えたり、事業・開発両方の観点を持つメンバーが育ったり、PdMへのキャリアパスの可能性が広がったり（配属は確約されていません）します。
私はこの検定を通じ、初めてPdMという存在を知り、プロダクトをより良くしていくのにとてもピッタリな役割だと思い、受験しました。
結果は不合格でしたが、本当に本当にたまたまご縁があり、プロダクト開発チームへ異動することになりました。
新米PdMの3ヶ月
全員と1on1
プロダクト開発チーム全員と、挨拶を兼ねた1on1を実施し、
こんなことを聞きました。
・プロダクト開発チームのゴール
・プロダクト開発チームの課題
・PdMへの期待
・技術的なチャレンジ
・プロダクト開発チームの良いところ
・皆さんのバックグラウンド
- これまでのキャリア
- POLへの入社理由
- 得意なこと、好きなこと
そして、結果をスライドにまとめて一部メンバーに共有してみました。
この1on1を通じて、POLのプロダクト開発チームは、ミッション実現への想いが強かったり、コードよりもプロダクトやユーザーに関心があるメンバーが多い組織であることを知り、感動を覚えました。
一方で、そういったミッションへの想いがあるが故に、現状の品質に対して強い課題意識を持っていて、なんとかしたいと思っていることも、よくわかりました。
基礎知識のインプット
プロダクト開発チームの皆さんにおすすめな書籍を聞き、基礎知識のインプットを進めました。まだ途中のものもあります。
書籍・オンライン教材
SQL
エンジニアさんに頼らず不具合調査ができるようになりたいと思い、エンジニアさんに教わりながらプロダクトのデータ出しを練習しています。
複雑ではないちょっとしたデータ出し、不具合調査の触りの部分だけであれば、一人でできるようになりました。
自社プロダクト、ユーザーの理解
自分がこれまで関わりの薄かったプロダクトをstg環境で使いまくったり、社内資料を漁ることでtoC側ユーザーへの理解を深めています。
意外だったのは、これまで自分がCSとして携わっていて、熟知していると自負していたプロダクトにおいて、まだまだ理解が浅い部分があったことでした。
お客様の声から理解するプロダクトと、データから読み取るプロダクトとでは、違いがあったからです。
両方の視点でプロダクトを理解し語れたら超かっこいいです。
事業KPIの理解
プロダクト開発をする際に、その開発が何の指標に紐づいているのか を明言する必要があるため、事業側が立てている指標と進捗を随時理解するようにしています。
問い合わせへの対応
キャッチアップ目的と、自分でもできそうなことはとりあえずやろうというスタンスから、各部署からプロダクト開発チームへいただく開発要望・障害報告・質問に対して、積極的に対応していました。
一旦自分で調査し、わからなかったらエンジニアさんデザイナーさんに聞き、同じことは2度と聞かないようにドキュメントとして蓄積していくという流れで行っていました。
問い合わせは、CSで一緒に仕事をしていたメンバーからのものが多かったので、状況もよくわかるしコミュニケーションも取りやすく、この自分の状況にありがたさを感じていました。
初めての要求定義書
作成するのに1ヶ月かかりました。すごく難しかったです。
要求定義書を、エンジニアさんデザイナーさんへ発表した際にもらった、たくさんの質問が非常に勉強になりました。
■なぜ作るのか？について
・他にやるべきことがたくさんある中で、なぜ今この施策をやるのか
・一番シビアなユーザーの視点から考えられているか
・ユーザーは本当にこの課題を感じているのか
・1つの要求に対して、課題が複数入ってないか、大きすぎないか
・課題を裏付ける根拠はあるのか、定量/定性で示せるか
■何を作るのか？について
・打ち手は本当にそれしかないのか、他にもないのか
・プロダクトの性格からずれたものになっていないか
■その他
・この開発の順番で良いのか、逆の方が効果検証しやすいのではないか
・ABテストで検証した結果に応じたアクションのイメージは持てているか
・事業側への相談や合意は取れているのか
思ったこと
別の会社かと思った
CSと比較すると、プロダクト開発チームは別の会社のようでした。
コミュニケーションの取り方、働き方、求められる成果、社内会議やイベントへの捉え方などが異なり、すごく新鮮で、たくさんの発見がありました。
これ私が決めていいんですか？！
プロダクト開発チームに来て一番感動したのが、何を作るか？を自分で決められるということでした。
今までCSで、この機能をこう改善してほしい！こういう新たな機能を作ってほしい！という思いがたくさんあったのですが、それを決められる立場であるということに、かなりの感動を覚えました….（泣）
特にCSからの異動だったので余計に思うのだろうと思います。
ビビらない
数ヶ月間、エンジニアさんデザイナーさんの側で仕事をしてみて、ものづくりの難しさや大変さも理解しました。理解したからこそ、自分の技術的知見が足りないことへの後ろめたさを感じ、これやりたい！という自分の意見を発信しづらくなってしまう時もありました。
しかし、CTOとの1on1で言われた「あやぱんさん、最近おとなしくてつまんないよ」という言葉を機に、何のために自分がPdMにきたのかを改めて思い返し、発信することに躊躇せず頑張ろうと思えています。
PdMとしてのこれから
リリースを見てみたい！
まずは、今携わっている初めての施策が世にリリースされるのがとても楽しみです。
各工程にいる各分野のプロフェッショナル達が、ユーザーに価値を届けるという共通の目的に向かって、自分の持ち場でできることを最大限する というものづくりのプロセスに、青春というか、感動というか、心がグッときます。
こんなPdMになりたい
これまでのバックグラウンドを踏まえ、こんなPdMになりたいな〜と思っています。
中長期的かつLabTechプラットフォーム視点で、プロダクトの課題特定をし、ステークホルダーと解決策を決められる
事業側・開発側のコミュニケーションを円滑にできる存在
（おまけ）刺さった言葉
妥協は絶対にダメ。自分の決定に責任を持ちなさい。周りの意見で自分の意見をコロコロ変えると、エンジニア・デザイナーはついてこなくなるよ。（CTO）
365日24時間PdMであれ（CTO）
不具合、バグが多くある場所は、それ程多くのユーザーの要望が集まっている場所で、かつそれに応えて改善してきたということ（同じチームのPdM）
まあ、肩の力抜いて、ゆっくりやっていきましょう（同じチームのエンジニア）
この記事が気に入ったらサポートをしてみませんか？