シニアPMへの成長を実感した瞬間


この記事は、estieのプロダクトマネージャーによるブログシリーズ「PM Blog Week」第3弾・2日目の記事です。前回の記事は<< ユーザー行動ログと向き合う技術 - estie inside blog>>です。

こんにちは。estieでプロダクトマネージャー(PM)を務めている三橋です。

本日は、先日開催したイベント、

[増枠] estie PM Meetup#4 PMキャリアの分岐点。ミドルPMが次に進むべき道とは? - connpass

の振り返りも兼ねて、自身がシニアPMに至った分岐点について、「シニアPMへの成長を実感した瞬間」というタイトルで私の具体的な経験を述べたいと思います。PMはバックグランドも人それぞれなので当然すべての方に該当するものではないと思いますが、シニアPMになるための1つの事例として、参考にしていただけると幸いです。

私のキャリアは4つのフェーズに分けられる

まず、私のキャリアを4つのフェーズに分けてご紹介します。

簡単にサマリとして申し上げると以下の4フェーズに分けられます。

  1. ECの実務運営を起点に
  2. ドメインエキスパートとしてPMになり
  3. ECプラットフォームでマルチプロダクトのプロダクトマネジメントに携わり
  4. 商業用不動産のドメイン知識ゼロでestieのPMに転職(今ここ)

三橋のこれまでのキャリア

実務経験時代

この時代はただひたすらにネット通販業務の実務に明け暮れる日々でした。

幸いにも最初に入社した会社は当時社員数が十数名で、退職時には数倍規模になっており、会社が1→10に成長するフェーズに携われたのは、非常に幸運だったと思います。

この時代の学びは大きく2つあります。

1. PMが実務を理解することの大切さ

当時は当然そんなことは考えていませんでしたが、ここでしっかりとネット通販に関わる業務のほぼ全てを経験したからこそ、PM駆け出し時代にドメインエキスパートとして様々な案件をリードすることができたと思っています。

2. 業務課題を自ら解決できた経験

2つ目は、自社の業務課題の解決策を自ら生み出せるということを身をもって体験した点です。たとえば、当時はネット通販隆盛期で、言うなればどのお店も売上が伸びている状況で、売れば売るほど日々の出荷業務が増え残業時間が増えるばかりで、これ以上注文を受けてはいけないのではないか?というような悩みがありました。それでいて、今でいう物流業務のアウトソーシングもまだまだ整っていない状況でしたので、出荷業務は自分たちでどうにかするしかなかったのですが、その過程で、商品を仕入れる産地と交渉して現地から直接商品を発送するというスキームを考案したり(そうすれば自分たちは販売に専念できる)、当時ピッキング施設が整っていないような物流倉庫と交渉して出荷業務を委託する仕組みを作ったりなどして、業務課題は自分で解決できる、ということを実感できたことが大きかったです。

この時代は今後自分がPMになるということなんて考えもせず、ただ毎日がむしゃらに目の前の仕事に向き合っている状態でした。

駆け出しPM時代

私がPMになったきっかけは、1社目を退職した後にECコンサルタントとして働いていたことにあります。その当時、私はECの分野が大好きで、もっとこの領域でキャリアを広げたいと考えていました。そこで、次のステップとして、ECプラットフォームの企業に転職することを検討していました。そして、実際に、かつて私自身が出店店舗の立場として関わっていたECプラットフォームで働くことを選んだのです。

転職活動を進める中で、ある企業から「あなたのドメインエキスパートとしての知識を活かして、サービス企画に携わってみないか?」と声をかけてもらいました。これが、私がPMの道を歩み始めたきっかけです。

この時代は、常時数十人規模の開発体制を持ち、ECモールの流通向上を目的に、BtoB、BtoCの両面で機能を積極的に開発していました。

この時代の特徴を一言で申し上げると、

自ら先頭に立ってプロダクトの仮説検証を回しまくった時代

と言えると思います。

PMとしての今の私の土台を築き上げた時代でもあります。
とにかく失敗が多かった時代で、その分学びも多かったです。

この時代の失敗や学びは以下の通りです。

  • 数千企業が利用しているプラットフォームシステムのリプレイスをした際に、リスク管理が甘く開発コストが最終的に2倍近くに膨れ上がった(スケジュールだけは何とか死守できた)

  • リプレイス後のシステム移行をうまく遂行できずに、システムの並行稼働期間を数年許してしまい、システムの保守を複雑にしてしまった

  • リリースした後にほとんど使われない機能をいくつも開発してしまった(もちろん、開発時点では「これはすごい!絶対に使われる!」と思って開発している)

  • PMに成り立て当初は開発するプロダクトの期待効果を定量的に一切算出せずに、また、開発した後の評価をもせずにひたすらに開発し続けていたが、適切に試算、評価する方法も覚えた(ただし、個人的には、開発前に蓋然性を高めようと思っていた後の時代よりも、蓋然性を考えずただひたすらに最速でプロダクト/機能を生み出していた時代の方が、成果の総量としては多かった気もする)

とにかく毎日が失敗と学びの日々で、良くも悪くも刺激に溢れていました笑

今考えるとPMに成り立ての私にありえないほどの開発予算を与え、多くの開発をリードさせてくれた当時の経営層には感謝をするしかないのですが、なぜそのように任せてもらっていたかというと、実務経験時代を経て、当時の社内の誰よりもEC領域に精通したドメインエキスパートであったからだと思います。

ECプラットフォームの収益構造は、ECプラットフォームに出店してくださっている店舗様から毎月の月会費やオプション利用料、広告費用や成約時の手数料をいただくことで成り立っていますが、私はECプラットフォームのお客様である「出店店舗」の実務経験者だったので、言うなれば、どのような機能にすればいいか自分が一番理解していたので、何を作るべきか?どのような仕様にすべきか?というあらゆる意思決定を高速化できたのです。

当然、ドメインエキスパートであっても開発したプロダクトや機能において失敗はたくさんありました。思った以上にその機能が使われなかったり、思った以上に売上向上に寄与してくれなかったなどその理由は様々ですが、とにかく開発→振り返り→開発というサイクルを高速で回せたことで、「成功するプロダクト」「成功しないプロダクト」を何となく肌感で掴めるようになったのもこの時代だと思います。

マネジメント時代

この時代になって、ようやくシニアPMとしての成長を実感します。

駆け出しPM時代が始まった当初は組織すらなく私一人だけの取り組みでしたが、数年後には数十人の組織に成長しており、この時代ではより会社らしいプロダクトマネジメントを実施するようになっていました。

まず、ECプラットフォームのプロダクトは、本当に幅広い領域があるので、以下のようにプロダクトカットに分解し、どの組織でどの領域を担うか、それぞれの領域でどういうミッションやKPIを担うのかというプロダクトや組織整理をしていきました。

当時のプロダクトカットの一例

  1. toC向けプロダクト
    a.TOPページ
    b.商品ページ
    c.検索結果ページ
    d.購入フロー

  2. toB向けプロダクト
    a.商品管理
    b.受注・決済管理
    c.店舗管理
    d.販促管理
    e.API管理

  3. プラットフォーム機能
    a.インフラ管理
    b.クーポン管理
    c.ポイント管理
    d.検索エンジン

思い返せば、estieのカジュアル面談でWhole Product構想を聞いた際に、自身がこれまでやっていたマルチプロダクト構想と似ていると気づき、Whole Product構想を進めたいと強く思ったことも、estie入社を決めた理由の1つです。もし単一プロダクトしかない会社だったら、estieに入社することはなかったと思います。

そして、シニアPMになったと私が実感したターニングポイントもこのマルチプロダクトにあります。

なぜならば、1つのプロダクトや機能をどのようにすればいいかを考えるのではなく、

業界全体をプロダクトに落とし込むとどのように表現できるのか?
その際にどこから攻めていくのが良いのか?

を考えることは、シニアPMが持つべき視点そのものだと思うからです。私は今でも、これを自信を持って実行できるかと問われると、正直自信はありません。今でも失敗はしていますし、仮説の域を抜けないようなことも多々あります。

ただし、この視点を持ってもう数年繰り返し実行してきているので、何かをプロダクトに分解・構造化することは得意なつもりですし、人一倍早く情報整理・構造化はできると思っています。どんなに時間をとって考えても仮説は仮説でしかないので、私はその仮説検証サイクルを回す速度を早めることによって、より早くより大きな成果を出したいと思っています。

正直言って、マルチプロダクトのマネジメントは大変です。

そもそも吸収すべき知識も多いですし、マルチタスクになるので頭の切り替えも大変です。

ただし、この広い視点を持つことが、シニアPMになる第一歩だと私は思っています。

また、もう1つ挙げるとすれば、駆け出しPM時代は具体的な課題に向き合っていたのに対し、シニアPMになるほど、抽象的な課題に向き合うことが増えると思っています。例えば、「このセグメントを開拓するためにはどんな機能が必要?」「この事業戦略を達成するためにどんなプロダクトが必要?」というものです。

こういった抽象的な問いに応えていく耐性を身につけることも、シニアPMになる大きな一歩だと思います。

estieでPM時代

この時代は、言うなれば私のこれまでのPMとしての全ての経験を糧にして活動している時代で、個人としても大きな成果が求められていると思っていますし、周囲からもそのような期待があることを強く感じています。

現在、私はマネージャーではなく100%プレイヤーとしてPMをしています。自分の行動が全て自分の成果につながるので、逃げ場は一切ありません。そんな中で、今私がどんなことを意識して日々活動しているかを言語化すると、以下のようになります。

仮説検証をとにかく進める

顧客に向き合って仮説検証をとにかく進める。

検証方法は、資料を見せる、デザインを見せる、MVPプロダクトを見せる、から最適なものを選べば良い。

とにかく現場に出て顧客と話してドメイン解像度を高める

まだまだドメインエキスパートと呼ぶには程遠いです。

顧客の生の声を聞いてもっともっと吸収していく必要があります。
その顧客の声を構造化してプロダクトやソリューションにどのように落とし込んでいくか?を考え続けていかないといけません。

プロダクトの未来を考え続ける

estieでは、半年ごとにプロダクトビジョンプレゼンテーションというイベントを実施し、各PMが自身のプロダクトやその領域のビジョンを語る場があるのですが、現在作っているプロダクトの先にどのような未来があるのか?を考え続け、チームや周囲や語り続けることは非常に大切だと思っていますし、それが開発チームにPMが存在する価値の一つでもあるとも思っています。

極端な話になりますが、プロダクトは、

  • PMが場当たり的にフィードバックを集め
  • 適当に開発の優先順位を決め
  • 雑にPRDを書く

でもうまくいくことがあります。なぜなら、同じチームのデザイナーやエンジニアが優秀であれば、PMが想像している以上のプロダクトを生み出してくれることがあるからです。

ただ、それがPMの成果なのかと言えばそうではないと思いますし、「PMがいないとそのプロダクトは作れなかったの?」と問われれば、「PMがいなくても作れたかも」と言う回答になってしまうでしょう。それではいくらなんでも同じPMとして悲しすぎます。

私が思うに、PMにできて他の役割の人にはできないことの一つは、どのようなプロダクトにしたいかと言う自身の考え・想いを表明し(個人的には、これをプロダクトに魂を込めることと言語化している)、結果的に、自分がそのチームにいなければ今のプロダクトでは実現し得なかったことを増やすことだと思っています。

この件についてもっと知りたい!と思った方は、ぜひ以下の記事もご覧ください。

プロダクトに魂を込める方法 - estie inside blog

結論:シニアPMとして成長を実感した瞬間は?

本題から大分話が逸れてしましたが、改めて結論づけると、マルチプロダクト思考を当たり前に持つようになったことが、シニアPMへの成長を実感した瞬間であったと思います。

私はPMはプロダクトや機能に向き合っているのではなく、本質的にはプロダクトや機能の向こう側にいる「顧客の業務やその業務課題」に向き合っていると思っています。言い換えれば、マルチプロダクト思考を持つことによって、当たり前に顧客の業務に深く向き合うようになったことが、シニアPMになるターニングポイントだったのかもしれません。

一方で、ターニングポイントはマルチプロダクトだけに限らないと思います。例えば、PMでありながら事業開発的な活動ができるようになったことがターニングポイントの方もいるかもしれません。シニアPMへの入り口は様々だと思います。

もし、この記事を読んでいただいたシニアPMの方がいれば、自分はこれがターニングポイントだった、ということをぜひ教えてください。

最後に

最後までお読みいただき、誠にありがとうございました。

今回は私の経験からシニアPMへの成長を実感した瞬間について述べましたが、PMのバックグラウンドは本当に様々で、何が良い悪いはないと思っています。

estieではまだまだ新しいPMを募集しています。今回の記事に少しでも興味を持っていただいた方は、キャリアのご相談からでも構いませんので、ぜひ、カジュアル面談でお話しましょう。

hrmos.co

© 2019- estie, inc.