プロダクトマネージャーの書き溜め

エンジニア出身のプロダクトマネージャーが学んだこと、気づいたことを書き溜めていくブログです

1人目PdMの壁

プロダクトマネジメント業務を主として行うようになったが、同じ業務を行なっているスタッフは会社に自分しかいない。つまり1人目PdMという状態だ。

1人目PdMというポジションを取ることはPdMのキャリアをスタートしたい方にとって悪くない戦略だと思っている。既にPdMが何人かいる組織で新たにポジションを取れるタイミングはPdMが退職するか、新規プロダクトが立ち上がりPdMを増やす必要がある場面に限られる。そう言った場面があったとしても自分が選ばれる保証は無い。

かと言って未経験での転職は鬼門だ。
どの会社も中堅PdMを欲しがっている。未経験可の場合もあるが、これはPdMの肩書きがなくても良いという意味で、同様程度の業務経験を積んでないと厳しい場合が多い。

そのような状況の中で1人目PdMであれば、誰とも競争することなくポジションを取って実務経験を積むことができる。
会社の中で経験を詰み、プロダクトを成長させシニアPdM、PO、CPOなどのポジションを目指すこともできるし、他者へ転職する足がかりとすることも出来る。(既に実務経験を持っているため、完全未経験で転職を試すよりずっと確度は上がる)

一方で1人目PdMが抱えがちな課題もいくつかあると考えている。
この記事では私自身が感じている1人目PdMとしての課題感をシェアし、PdMを目指している方、1人目PdMに挑戦している方の参考(もしくは「やっぱりみんなこんな辛み抱えるよね・・！」という共感)になるととても嬉しいです。

1人目PdMが抱える課題

課題1: 知識を正しく積み上げることの難しさ：

1つ目はプロダクトマネジメントの業務知識の正しい積み上げの難しさがある。 PdMとして仕事をする上で必要な知識・能力をざっと箇条書きしてみる。

  • PdMの責任
    • プロダクトの成功責任
      • ユーザーに提供する価値の向上
      • 収益の増加
      • ビジョンへの前進
  • プロダクトを成功させるためのコミュニケーション能力
    • 各領域間の翻訳力・マネジメント力
      • 異なる領域(開発・デザイン・営業など)の関係者まとめ上げ、各関係者で認識の齟齬が発生しないよう正しく情報を翻訳し伝達・牽引する
  • プロダクトの階層意識
    • Core / Why / What / How
    • 階層を意識して仮説を検証していく
      • ターゲットが抱えている課題が仮説と一致しているか検証するフェーズなのにページの表示スピードの改善をしても意味無いなど
  • プロダクトを構成する分野の知見
    • テック・ビジネス・ファイナンス・CS・UIUX・マーケ・PR・リーガルなど
    • プロダクトの成功責任を持つPdMが知っておくべき知見を、各担当者と問題なくコミュニケーションが取れる解像度で持っておく
  • プロダクト改善の一連の流れ
    • 課題の洗い出し
    • 優先順位の設定
    • 課題の分解(サブイシューの定義)
    • 分解した課題を解くための施策定義、PRDへの落とし込み
    • チームへのPRD共有
    • 開発・テスト・リリース
    • 検証
    • 検証結果のフィードバック、次施策への反映
  • ドメイン知識
    • プロダクトで解く課題関連の知識

上記の通り、必要な知識・能力は幅広い。
そしてどこから順番に積み上げていけばいいかも分かりにくいし、積み上げるにしてもどの程度の解像度があれば良いかも分からない。(「プロダクトを構成する分野の知見 > テック」であれば、コードを書いて自身で個人サービスをリリースできるくらいの知見が必要？それともざっとしたWebサービスの仕組みが理解出来ていればいい？など)

自分自身も積み上げ漏れによる失敗を数多くしてきた。
一番お金も時間も無駄にしたなと感じたのは「ひたすらHowの回収に熱中する」ことだ。
当時は良いプロダクト、イケてるかっこいいプロダクトを作れば、めちゃくちゃ使われて有名サービスの仲間入りだ！なんて甘いことを考えていて、「これまで見たことのない信じられない技術」や「感動的なUX」を提供することに躍起になっていた。結局、ユーザーは課題を抱えてないという結論になった。その結論に辿り着くまで上記のようなHowに対してのアプローチを延々と行なっていたが、今考えるとコツコツとWhyの検証「まず顧客は課題を抱えているのか？」に注力すべきだった。(プロダクトの階層意識)

こういった失敗をしながら力をつけていくのも良いが、効率はあまり良く無いと思う。こういうとき他にPdMがいて相談できればよかったなと思う。

補足: ちなみに今自分が駆け出しPdMの方にどのように知見を積み上げるべきかと問われたなら以下のように返答すると思う。

  1. PdMの責任
    1. まずあなたが就こうとしているポジションはこんなことをやるということの共有
    2. あなたが持っているイメージと相違ないかのチェック
  2. プロダクトを構成する分野の知見
    1. プロダクトの全体像のイメージを共有
    2. Webサービス自体は「テック・UIUX」で構築されていて、そのプロダクトで収益を上げていくための構造を「ビジネス・ファイナンス」の領域で考える。ただネットで公開されていても人の目に触れないからそのために「マーケ」があって・・など
  3. プロダクト改善の一連の流れ
    1. プロダクトの構造を理解した上で、どういうところに着眼してどういう手順で改善していくかの共有
  4. プロダクトの階層意識
    1. プロダクトには階層があり、フェーズによって改善する階層を見定めることが必要である旨を共有
  5. ドメイン知識
    1. こういう課題があって、こう解こうとしている。いままではこういう解決策があったんだけど、こういう問題があって・・
    2. いままで解かれてこなかったのにはこういう業界の理由があって・・など
  6. プロダクトを成功させるためのコミュニケーション能力

課題2: 課題の解像度が一定値以上上げられない

2つ目は課題の解像度について。PdMの最も重要な責任は「担当するプロダクトの課題を明らかにして、課題を構成する要素(サブイシュー)に優先度を振り、最もインパクトがあるところから改善、ユーザーに提供する価値の向上・収益の向上・ビジョンへの前進を行うこと」にあると考えている。

それらの手順を実行していく際の「課題を明らかにする」「課題を構成する要素(サブイシュー)を明らかにする」対応の確度が一定値以上上げられなくなる点も1人目PdMの大きな課題だと思っている。

確度が上げられない原因は主に課題やサブイシューを鮮明に捉えられていない、つまり課題に対しての解像度が低いからだ。
課題がぼんやりとしか見えてないので、それを分解してもさらにぼんやりするだけだし、施策を打っても当たらない(目が悪い人がメガネを外してダーツをするようなもの)

そうなると解像度を上げれば良いのでは？となるがこれがとても難しい。 「解像度を上げる」を読むと、課題に対しての解像度が低い場合基本的に課題の「深掘り」が足りていないとあるし、自分自身の実体験からもそう思える。
この深掘りが難しい。どこまで深ぼればいいか分からないし、自身の持っている知識の範囲で観測できない場合もある。(センサーが発達してないと言ってもいい。第三者にこういう路線は考えた？と言われると、あ！と一気に分かるが、自分一人だと一行に進まない)

自分は本からのキャッチアップ+失敗に失敗を重ねて解にたどり着いた(深掘りして失敗、ではもう少し別方向で掘って失敗を繰り返す。最後は良い解にあたる)がやはり効率が良くないし、いい結果が出来ないと気持ちも下がる。スタートアップなら資金的にそんなことをしている余裕が無い。

この課題を解決するにはメンターを付けるしか無い。ただそのまま社外の人に話してしまうと情報漏洩になってしまうので難しい所。会社がメンター・アドバイザーと契約してくれるのが一番望ましい。(ただこれも外側からのアドバイス程度に留まるので、結局は自分でやるしかない。それでも何も無いよりはいい)

まとめ

自分が一人目PdMを経験する中で感じた課題をまとめた。
うまくまとめきれなかったし、こう解決すればいいという方法もほぼ無く最後まで読んでくれた方がいたらちょっと申し訳ない・・

ただ、もし同じように挑戦し、同じような課題に直面している方がいるのならあなただけじゃないと言いたい。この記事では上記の通り、具体的にどう乗り越えて行くかはまとめられなかったが、これ以降の自分自身のPdM人生の中で乗り越え方を見いだせたらまた記事にしたい。この記事がそういった誰かの役に立つコンテンツの幹になれるよう、プロダクト・顧客と向き合い知見を貯めて行く。