マネージャーではないシニアPdMがチーム内で意識して実践していること

estieでPdMをしている三橋です。先日、半期に一度の自己評価に関わる振り返りを行いました。その際に、PdMってチームで見たら一人のプレイヤーでしかないけど、そのPdMの立ち振る舞い次第でチームの動きをよくも悪くも大きく変える影響力があるぞ、ということを改めて認識しました。

思い返せば、入社前の面談の際に弊社VPoPの久保が「シニアなPdMがマネジメントをせずに暴れる環境を作りたい」と言っていましたが、まさしくシニアなPdMのチーム、または全社における影響力を期待してこその発言だったのでしょう。

で、実際どうなの？ということを、大変おこがましいのですが、私と同じチームメンバーの声も引用しながらシニアPdMがいるチームの実態をご紹介していきたいと思います。

そもそもシニアなPdMとは

はじめに、どのようなPdMをシニアPdMと呼ぶのか？という論点が出てきますが、estieのPdMのジョブディスクリプションでは、概ね以下のように定義をしています。

求められる総合的な期待値
- 担当領域（一つ、または複数のプロダクト群）において、1-2年後を見据えたプロダクト戦略を立案・実行する職務を担う
求められる具体的な振る舞い
- 全社のプロダクト戦略とチームのプロダクト戦略を統合し、最適なプロダクト方針を定める
- 定めたプロダクト方針をチームで協業してあらゆる手段を用いて実現させきる
- プロダクト価値向上のために最適な手段を定性定量の両面で探求し、再現性・拡張性を磨きこむ

シニアPdMに求められる振る舞いを単純化して述べるのであれば、「判断力」「実行力」「再現力」の３点と言えそうです。

本記事ではその中でも、定めたプロダクト方針をチームで協業して実現させきるために何をするべきなのかという「実行力」、正確には、私は実際に何をしたのか？にフォーカスしてお話ししたいと思います。

マネージャー兼PdMであるジレンマ

私の経験上、シニアなPdMは総じてマネージャーも兼務していることが多かったように思います。

本記事のタイトルは「マネージャーではないシニアPdMがチーム内で意識して実践していること」ですが、あえて「マネージャーではない」という枕詞をつけています。理由は、PdMがマネージャーも兼務している場合、あらゆる場面において、それはPdMの立場としての発言なのか？チーム全体の意思決定が可能なマネージャーの立場として発言なのか？が曖昧にならざるを得ないからです。

もちろん、プロダクトの初期フェーズにおいてはPdMがマネージャー、リーダー、事業開発を兼務することも多いため、PdMが何らかの役割を兼務することにより意思決定のスピードが上がる、というメリットもありますが、少し大きくなったチーム（5人くらい〜）では、二つの人格が存在することで、純粋なPdMとしての責務（ここでは「定めたプロダクト方針をチームで協業して実現させきる」にフォーカスする）を果たしにくくなるのでは？という懸念は拭えません。

estieではこのような問題を発生させないために、大きな意思決定権限を持つ取締役等がプロダクトに深く関わりたい場合は、一人のPdMとして現場に降りてきて、そのチームのPdMを兼務することになっています。要はプロダクトの方針やその戦略の執行に細かく意見したいなら、現場まで降りてきてPdMとして活動せよ、ということです。実際にこの記事を書いている今、全社CTOがとあるプロダクトのPdMを兼務しています。

私がPdMとして意識して実践していること

ここからは定めたプロダクト方針をチームで協業して実現させきるために、私がPdMとして意識して実践していることを3つご紹介したいと思います。

1. とにかく構造化

こちらのブログで以前「PdMの業務は全て言語化」と言っても過言ではないと述べましたが、同じくらい構造化も重要だと思っています。実際に直近約三ヶ月で私が構造化したものの例は以下の通りです。

プロダクトについての振り返り内容の構造化
クライアントの業務上のデータの流れの構造化
クライアントのホームページの情報の構造化
クライアントの報告書に記載されている情報の構造化
プロダクトで将来的にカバーしたいマイクロサービスの構造化
カスタマージャーニーによるフローや思考の構造化
とある機能の拡張のための情報の構造化

構造化するメリットは、抽象的な事象を要素分解することで、具体的な事象に置き換えて共有・議論ができるようになることです。構造化によってチームメンバーと様々な場面で共通認識を持ちやすくなります。

2. 70%の質でチームに「たたき」を持ち込む

二つ目は、自身が整理した「たたき」を、反論を恐れずにチームに持ち込むことです。そして、その際に持ち込む「たたき」は、必ずしも丁寧に時間をかけて推敲を重ねたものである必要はありません。言うなれば70%の質でいいと考えています。

これによるメリットは、フィードバック可能な余地が十分に残されていることでチームメンバーが発言しやすくなり、結果として一人で推敲を重ねるよりも時間を短縮できるということです。PdMが「たたき」を作り、その後柔軟な姿勢で意見をどんどん取り込んでいき、その中で譲れないことがあればしっかりと言語化して伝える。これこそが、最短で最良の結論にチームとしてたどり着く方法だと私は思っています。PdM一個人の力なんてたかが知れています。どんどんチームメンバーの力を借りるべきです。

3. 「読んでおいて」ではなく「一緒に読み合わせる」

変にチームメンバーに気を遣って「みなさん忙しいでしょうから、それぞれお手隙の際に読み、気になる点があればコメントをください。」のようなスタンスを取っていては、折角作った「たたき」も活かされません。重要なことはしっかり時間を取って読み合わせと議論をしましょう。完全な読み合わせではなく、「冒頭に5分時間を取るので読んでください。その後議論をしましょう」などと全員が読む時間を先に設けるのもありです。

重要なのは、その「たたき」について全員をOn the same page（共通認識）にすることです。そのためには、全員の時間を使うぞ！という決断も時には必要なのです。

チームメンバーからのフィードバック

最後に、チームメンバーからもらったフィードバックを簡単にご紹介します。もちろん、私のPdMとしての振る舞いに関して、「ここはもっとこうした方がいいよ！」というようなフィードバックも数多くもらっているのですが、ここでは私がPdMとして意識して実践したことに関するポジティブなフィードバックだけを要約してご紹介します。

「過去事例を徹底的に分析して仮説を立て、更にそれを分かりやすくチームに共有・確認し、共通認識を丁寧に揃えていってくれた」

「たたき台を用意してくれている。議論のたたきがあるから、それは理想形・登り方はここから、というような具体的な議論ができる」

「いるものはこれ、いらないものはこれ、の基準をチームに言語化して伝えてくれるところが良い」

「プロダクトの方向性について、周りを上手く巻き込み、頼りながらつくり上げてくれた」

「柔軟に色んな人の考えを取り込む姿勢が良い」

「プロダクトに留まらず、チームとして取り組むべきことを拾って前に進めてくれるので安心感がある」

どうでしょうか。チームが一体となって動いている様相が浮かんできませんか？

私個人の感覚でいえば、「たたき」を持ち込むことで議論が進み、結果としてチームが進むべき道が見えてくるケースが多いので、スピード重視でどんどんチームメンバーを頼っていこう、という気持ちです。笑