見出し画像

1人目のプロダクトマネージャーは何からすべきか?

こんにちは
GENDA Advent Calendar 2023 4日目の記事を担当する千葉です。

GENDAでは、toC/toB/DXなど複数のプロダクトでプロダクトマネージャーを担当しております。



前書き

昨今、プロダクトマネージャーの存在が浸透し、プロダクトマネージャーという役割を導入する企業も増えてきました。
しかしながら、プロダクトマネージャーの導入事例についてはまだ少ない状態です。
そこで、ベンチャー企業に1人目のプロダクトマネージャーとして入社して実際に取り組んだリアルな事例について紹介します。
CPOや1人目プロダクトマネージャーの方の参考になれば嬉しいです。

プロダクトマネージャーとは

書籍やWebで様々な表現で定義されていますが、共通しているのはプロダクトの成功を実現することに責任を持つことです。

プロダクトの成功は、ビジネスとして成立することだったり、ユーザーの期待に応えることだったり、環境によって様々な定義があります。

私の過去の経験でビジネスの成立をおざなりにし顧客に対して価値提供を追求し続けた結果、事業存続が出来なくなり最終的に顧客を悲しませてしまったことがあります。
どちらか片方では意味がなく、両方を両立させた状態がプロダクトの成功と考えています。

プロダクトが実現するべき状態

プロダクトの成功に責務を持つプロダクトマネージャーの仕事に必要な領域はビジネス、ユーザー体験、テクノロジーの3つで、それぞれの領域を横断しながらプロダクトの成功を実現するため推進していくことが求められます。

プロダクトマネージャーの仕事領域

プロダクトマネージャーがすべきこと

前段のプロダクトマネージャーの説明にもあるように、役割の範囲が明確に分けられていないため、やるべき(やれてしまう)仕事は無数に存在します。

ですが、私の経験から最初に行うべきポイントは以下3点と考えています。

  1. 事業に纏わる情報の把握

  2. 価値提供環境の構築

  3. アウトカムの実現

事業に纏わる情報の把握
Why/Whatを前提にどう実現するかがプロダクトマネージャーにおいて大事なミッションなので課題特定、ユーザーのニーズと事業のドライバーになる変数を把握することは重要です。

価値提供環境の構築
方針を定義することは重要ですが、方針を実現することもとても大事です。
したがって、プロダクト開発を実行できる状態を作ることも同時に必要になると考えます。実現できなければ何の価値も提供できていないのと同じですから。

アウトカムの実現
課題の特定→解決策の策定→実現 を経て、最終的に成果を生み出すことが最重要です。なぜならば、プロダクトマネージャーの責務はプロダクトの成功だからです。

これらのポイントを抑え早期に価値提供をすることがプロダクトマネージャーに求められます。
各ポイントの詳細と事例については次のセクションで説明します。

プロダクトマネージャーの登り方

事業に纏わる情報の把握

何か行動を起こすには、まず把握することから始まります。
プロダクトマネジメントにおいて抑えておきたいことは以下に羅列します。
ただ、初めからここまで定義できている環境は少ないと思います。
なので、最初は何がわかっていて何がわかっていないかを明らかにしていく行為を経て全体把握と今後明らかにすべきことを見定めることがおすすめします。

事業に纏わる情報把握の観点の例

把握のポイントとしては、この記事がとても参考になります。

また、これらを整理する際に関係者との対話やユーザーヒアリングを行い、目に見えない情報を拾うことが重要です。
Webで拾ってきた情報には反映されていない大事な情報があるかもしれないからです。
なので、1次情報を取りにいくことを意識して情報を集めることが大事です。

私の場合は、ユーザーリサーチは勿論のこと、景品の発注/機械の調整/お客様対応/配送手配などのサービス運営を行う現場にも出向き、現場視点で何を感じているか何を考えているかをヒアリングしました。
結果、見えていなかった課題が見つかり事業全体の解像度が高まり方針策定の精度を高めることが出来ました。内容は長くなってしまうので別の記事で紹介しようと思います。
現場はリアルです。

全体把握を経て、わかっていることを基準に今後の方針を作るのか、わかっていないことを明らかにすることを優先するのかは経験が物を言う場面かもしれません。どこにレバレッジをかけていくかが1人目のプロダクトマネージャーの腕の見せ所と醍醐味です。

価値提供環境の構築

事業とプロダクトの把握を行い、今後の方針を定められるようになったら価値を実現する仕組みを整えることが必要です。
どんなに素晴らしい方針や解決策を検討できても、その価値を現実に提供できなければ意味がないからです。

価値提供プロセスで抑えておきたいポイントは以下です。

  • 意思決定の責任

    • 体制役割

  • 意思決定の場

    • 会議体

  • 意思決定のフロー

    • 施策検討や開発着手の合意

プロダクト開発は多くのステークホルダーと共に作っていく活動です。
多くの考えをプロダクトとして形にしていくためには意思決定プロセスの整備が大事です。
プロセスの品質がプロダクト質と量を生み出すと言っても過言ではありません。

これらを実際にどのような形で定義しているか紹介します。

役割と責任

カッコイイ名前をつけることが重要ではなく、定義すべき情報として大事なのは、誰が何に責任を持っているか可視化することです。
誰が何に責任を持っているのかが明らかになっている状態を目指しましょう。

実際の役割整理(担当名は非公開で)

会議体

誰が何に責任を持つかが決まったら、どの場で何を決めるかを定義します。
したがって、参加者と何を議論するかを明らかにすることが重要です。
議論の場なのか共有の場なのか、会議内容の設計もあわせて行うと効果的です。

実際の会議体の例

意思決定フロー

物事を決める場を決めた後は、それを実際にプロダクト開発するプロセスに落とし込む必要があります。特に手戻りが発生しないなど非効率なステップにならないか、定例会議の開催日まで考慮して設計すると効率的なフローが構築できるでしょう。

大まかなプロダクト開発フローの例

また、プロダクト開発では通常の機能開発以外にも不具合対応などの突発性ある物事が発生することが多々あります。通常の機能開発以外の場合のフローも定義しておくと関係者が混乱なく対応できるとのでおすすめです。

不具合対応フローの例

他にもプロダクトマネジメントの業務として根幹である優先度の考え方もこのタイミングで合意形成すると良いでしょう。
RICEフレームワークとフロー効率をベースにドメイン特有性を考慮した優先度基準を作れば大きくは外れないと思います。

実際の優先度定義の例

RICEフレームワークについて詳しく知りたい方はこちら

フロー効率とリソース効率について詳しく知りたい方はこちら

私の直近の事例を紹介すると、プロダクト開発が内製ではない環境でした。内製開発が絶対正しいわけではないのですが、toCサービスにおいてプロダクト開発のスピードが重要と考え、内製化プロジェクトを立ち上げて価値提供の環境を構築しました。
つまり、プロセス定義が重要ではなく、価値提供に必要な環境を考え作り上げることが大事ということです。

プロダクトマネージャーの仕事の範囲や素質が議論としてあがることが多いですが、プロダクトの成功のために手段も範囲も選ばず取り組める人がプロダクトマネージャーというラベルが付くと私は考えています。

アウトカムの実現

方針策定と環境構築ができたら残すは価値を提供するのみです。
私の経験上、プロダクトマネージャーという役割が不在でプロダクトマネジメントが浸透していない環境においては、どれだけ小さくてもいいのでプロダクトが事業へ影響を与え前進させた事実を作ることが大事です。

なぜならば、環境がプロダクトマネジメントの価値を真に理解できてない状態なので、プロダクトマネージャーが事業を前に進められる存在として確立する必要があります。

では、アウトカムをどうやって実現するかですが、様々な手法やアプローチがあります。
その中でもアウトカムの実現のためにKPIツリーが有用なので最優先で定義することをおすすめします。KPIツリーをもとにアウトカムを実現するうえで抑えておくべきステップは次のような流れです。

  1. 事業成果を生み出すための定数と変数の把握

  2. プロダクトが影響与えられる変数の特定

  3. レバレッジが効くドライバー変数の特定

事業成果の構造

まず事業が追う重要指標(KGI)からどのような指標で構成されているか定義します。指標間の影響(トレードオフ関係)や指標の分解構造を正しく可視化することを意識することが大事です。

プロダクトがコントロールできる範囲

事業全体で扱う指標と関係性が整理出来たら、その中でプロダクトが介在できる/すべき 領域を定義します。
例えば、セールス組織があり商談数を評価指標としておいていた場合にプロダクトがその指標まで追うには遠すぎるので、プロダクトがタッチポイントを持つ範囲かつ影響度の強さで整理することをおすすめします。
事業/プロダクト/組織 の環境でこの範囲設計が変わるので、都度設計が必要です。

注力すべき指標

プロダクトの介在する範囲が定義できたら、その中で何に注力すべきか定義します。プロダクトマネージャーが不在だったり浸透が進んでいない環境では、リソースが不足しているが短期成果を求められる状況は多いです。その状況下で全指標を満遍なく改善するアプローチを行うと成果を出すまでに時間がかかったり成果を出しつくすことが出来ません。
なので、実データや実績から1番インパクトがある指標を特定しレバレッジをかけることをおすすめします。

さらに注力指標をプロダクトが実現したい状態とビジネスとしても目指したい状態になるように設計できるととても良いと思います。(所謂NSM)
ただ、いきなりNSMを定義することは難しく時間を要する場合があるので、成果の緊急度でまずグロース指標を定義し、中長期的NSMを定義する進め方を行うと最終的なバランスが取れると私は考えます。

実際のKPIツリーとOKRの例(指標は非公開で)

「仕事の報酬は仕事」という言葉がありますが、小さな成果を積み上げていくことにより裁量が増え大きな裁量と大きな成果につながっていきます。
ホームランを狙ってフルスイングをすることは否定しないですが、小さな成果を積み上げる = 再現性 を意識して取り組む方が得るものが大きいと考えています。

なぜ得るものが大きいかというと、小さく始めることで新しい情報を得て学習に活かせるからです。複数の仮説があった場合に早期に検証することで軌道修正コストも低くなりますし、事実を沢山持っている方がは次の仮説精度が高まります。
また、小さな成果を積み上げるということは、再現性がある状態ということです。再現性高く事業と顧客に応えることでステークホルダーの信頼が高まり、信頼残高を増やすことが出来ます。
そうなれば裁量が増え、より大きな仕事を遂行しやすくなります。

まとめ

重要なポイントについて説明しましたが、ポイントを抑えることで果たすべき状態は、「プロダクトマネージャーの有用性」を証明する事と考えています。
プロダクトマネージャーという役割が介する事で実現できるコトや価値、ベネフィットをステークホルダーが理解する状態を早期に作り上げることがプロダクトマネージャーの存在を確かなものにする近道と私は思います。

さいごに

この記事で紹介したようなプロダクトマネージャーの導入例やプロダクトマネジメントの具体例は書籍やWebに中々ありません。
なので、今後はこのようなプロダクトマネージャーのリアルを記事にしていこうと思います。

いち早くプロダクトマネージャーのリアルを知りたい方はぜひこちらに。(実はプロダクトマネージャーとデザイナーのマネジメントも担当です)

カジュアルに面談も可能です。
連絡はお気軽にどうぞ。


それでは、またどこかで。

この記事が参加している募集

この記事が気に入ったらサポートをしてみませんか?