Photoruction工事中!

Photoructionの開発ブログです!

カスタマーサクセス・サポートを経験したプロダクトマネージャーの強みと苦労について

こんにちは!株式会社フォトラクションでPMグループリーダーをしている市橋です。 Photoruction Advent Calendar 2021の10日目の記事です。

本記事では、カスタマーサクセス(CSM・サポート)を経てプロダクトマネージャー(PM・PdM)にキャリアチェンジした私が考える、ユーザーに近いポジションからプロダクトマネージャーになったことによる強みと苦労している点ついて簡単にまとめています。

同じようにカスタマーサクセスやカスタマーサポート(以降、CSとします)または他の職種から、プロダクトマネージャー(以降、PMとします)へのキャリアチェンジを考えている方の参考になれば嬉しいです。

目次

私の簡単な経歴


私は建築系の学科を卒業後、大手建設コンサルタント企業で道路設計をしていました。

建設業界は労働人口が減少しており、今後さらなる生産性や魅力の向上が求められています。

そんな中、「建設の世界を限りなくスマートにする」というミッションを掲げてアプローチしている弊社で、業界で働く人達がスマートに働けるようにサポートしたいと思い、2019年末にCSMの立ち上げメンバーとして入社しました。

フォトラクションのCS


フォトラクションのCSは、photoructionを導入いただいている企業の方が、よりphotoructionを使いこなしていただけるために、以下のようなことをしています。

  • 導入いただいた企業様への操作説明会の実施
  • 各企業様との月次定例会を開催し、利用状況の確認や今後より活用できるようにするためのアクションプランの策定
  • 利用状況を計測し、使えている方・使えていない方それぞれの要因分析
  • 問い合わせ対応・サポートサイトの作成

PMへのキャリアチェンジを考えたきっかけ


日々photoructionをご利用いただいている方と接していく中で、「こんなことができなくて困ってるんだよね」や「この部分が使いづらいんだよね〜」と言ったご意見を聞いていくうちに、

「こんな機能だったら使いやすいのに」「自分だったらどうやって改良していくだろう」という考えを抱くようになっていきました。

もともと、ものづくりが好きだった(学生自体は建築の模型づくりが好きだったり、自宅の家具をDIYしたり、プログラミングを勉強して簡単なサイトをつくってみたりしていた)こともあって、

photoructionを最大限使っていただけるようにサポートするよりも、使いやすいサービスを作ることでphotoructionユーザーの方々に貢献したいと思うようになりました。

2021年の初めにその思いを当時の上司に伝えてみたところ、「いいんじゃない?市橋くんに向いているかもね。やってみなよ!」とすんなり後押ししてもらえました。(大感謝です!)

その後、2021年3月からCSと兼務する形でPMグループに異動しました。

強み1 : 機能やユーザーの使い方を一番把握している


使いこなしてもらえるようにサポートするため、また、使い方に関するお問い合わせに対して適切に答えるためには、サポートする側が一番使い方を熟知している必要があります。

使い方を熟知するためには、文字通りすべての画面・すべてのボタンを確認しました。

この画面ではどんな挙動をするのか、これは何のための機能なのか、ユーザーの課題を解決するためにはどのように操作するのがいいのかを徹底的に確認します。

嬉しいこと(?)に、photoructionには多種多様な機能があるため、すべての機能を把握するためには日々触り倒して体に染み込ませる必要があります。(稀にお客様からのお問合せで存在を知る機能もあったり、、、)

PMとして新機能を企画する際には、既存の機能との親和性や機能追加することによる影響などを正しく把握する必要があります。

最前線でユーザーと向き合ってきたおかげで、PMに転向してからは既存仕様の理解にあてる時間はほぼなし。開発メンバーから仕様や既存の使い方を確認された際にも即時に返答することができています。

強み2 : 定量調査の経験を企画に活かすことができる


CSとしてユーザーの利用状況を正しく把握するためには、定例会でのヒアリング内容(定性データ)に加えて、アクティブ率などの定量的なデータも活用する必要があります。

私が入社した当時、アクティブ率やデータ量の推移は逐一エンジニアに確認しないと取得できない状況だったため、自分たちで取得できるような仕組みをつくることにしました。

Google Analyticsを用いたアクティブ率の算出や、SQLを書いてデータベースに蓄積されたデータの取得をしながら、利用状況確認用のダッシュボードを作成しました。

(私がCSから異動したあとの今でも、KPIとして活用されています)

私がPMになった時点では、企画段階で定量データを確認する習慣がありませんでした。

仕様検討時に、既存ユーザーの活用状況や蓄積データ量を確認しておくことで、企画精度の向上や開発メンバーに説明する際にも納得感のある説明を行うことができます。

私がPMグループになってからは、社内で非エンジニア向けのSQL勉強会を主催し、PMグループのメンバー全員がデータを見るクセを付けられるように動いています。

また、photoructionの開発組織では、今後ユーザーの行動ログ解析ができるような体制をつくっていく動きをしています。

今後はより精度の高い定量データや、ユーザーインタビューによる定性的なデータなどを活用して、より利用していただいている方々のためになるようなサービス開発をしていきたいと思っています。

苦労 : 開発に関する知識が不足している


photoructionのPMグループは、開発する機能の企画部分(プロダクトマネジメント領域)と、企画した機能をリリースまで持っていく部分(プロジェクトマネジメント領域)を担っています。

企画の部分については、建設業に関するドメイン知識(私は道路計画が専門だったので、建築の施工についての知識は十分ではありませんが)と、CSで培ったユーザーとプロダクト理解の部分でカバーしています。

ただ、プロダクトマネージャー界隈で有名なThe Product Management Triangle でも記されているとおり、PMに求められるスキル・知識はユーザー・ビジネス・開発というとても広い領域で求められます。

特に、プロダクト開発やUI/UXデザイン領域については0からのスタート、かつ、プロジェクトマネジメント部分も任されていることもあってとても苦労しています。

PMという立場上、実装する上での実装難易度の想定であったり、エンジニアからの技術的な提案を受ける際にも、素早く適切な意思決定をしないといけません。

今の開発チームのメンバーは、私が開発領域の知識が少ないことを考慮して、分かりやすい表現を使っていただいていますが(大感謝)、素早く質の高い意思決定をするためには、開発に関する知識がどうしても必要になってきます。

まとめ


前述のとおり、世間一般的に言われるプロダクトマネージャーとして必要なスキル領域はとても広く、実際にやってみるとものすごく難しく感じます。

ただ、最初からすべてのスキルを持っている人はそうそういないのと、色々なバックグラウンドを持ったPMがチームにいたほうが、不足している部分をお互いに補えるので強いチームになれると思います。

現在のPMグループは私を含めて3名在籍しています。

建設業界出身という共通点はありますが、持っているドメイン知識領域はそれぞれバラバラですし、スキル面でも得意不得意な領域はそれぞれ異なっています。

そのおかげで、不足している部分をお互いで補うことによって、チームとしてプロダクト開発に臨めています。

私にPMとして期待されていることは、CS出身者である強みを生かして、photoructionを利用していただいている方の気持ちを一番理解しているPMになることだと思っています。

今、開発畑以外のところで活躍している方々で、PMへの転向を考えている方は、「いいプロダクトをつくりたい」という気持ちと「自分がプロダクトをつくる上で活かせることはなにか」を考え続けることが一番大事だと思います。

最後まで読んでいただきありがとうございました!

Photoruction Advent Calendar 2021の投稿はまだまだ続きます。

他の記事も是非読んでみてください!

 

株式会社フォトラクションでは一緒に働く仲間を募集しています

corporate.photoruction.com

www.wantedly.com