PM memorandum

Product Managementにまつわる記事をポストします。twitter: @kyosu_ke

プロジェクトマネジャーからプロダクトマネジャーへの転向に必要な3つの変化

これはなにか

本記事はプロジェクトマネジャーがプロダクトマネジャーに転向する際におさえるべき重要な点をまとめたものだ。

私自身、プロジェクトマネジャーからプロダクトマネジャーへと転向しているが、その際にいくつか重要なポイントが存在した。 この記事が、同じようにプロジェクトマネジャーからプロダクトマネジャーへ変わったばかりの方や、これから転向しようと思っている方の助けになれば幸いだ。

以降、プロジェクトマネジャーをPjM、プロダクトマネジャーをPdMと略称表記する。

PdM は PjMの延長線上にはない

f:id:kyosu-ke:20180916000545j:plain

字面が似ているせいか、「PdMはPjMの延長線上にある」と考えている方も一定数いると思う。(私自身そう思っていた)

しかし、そうではない

共通する部分はあるが、PjMとPdMでは、それぞれの役割に求められるものが異なるため、転向する場合、3つのポイントについて大きく認識を改める必要がある。

  • 実行の担保 → 結果の担保
  • 管理・調整 → 方針・意思決定
  • 開発現場視点 → ユーザー視点

まずは、議論の土台となる、PjMとPdMそれぞれの役割について記述し、のちに各ポイントについて詳述する。

PjMの役割と主な業務

役割

PjMは割り当てられたリソースで期日までにアウトプットを出すことにコミットする役割である。 よって、プロジェクトの進行上の課題に対してのアクションがメインになる。

たとえば、新規プロダクトと運用プロダクトでは下記のようなミッションを持つことになる。

  • 新規: プロダクトを期日までにリリースすることに責任を持つ
  • 運用: プロダクト改善施策を期日までにリリースすることに責任を持つ

主な業務

PjMの主な業務としては下記が挙げられる。進行の管理および調整ごとの占める割合が多い。

  • 開発進行管理
  • 仕様の調整
  • 工数アサインメントの調整

PdMの役割と主な業務

役割

一方、PdMの役割は、プロダクトが生み出す成果にフォーカスしている。 プロダクトをリリースした先にある「成功」を担保する役割である。

当然、一口に「成功」と言っても、定義がなければ判断がつかないため、「なにが成功であるか」を定義することも重要な役割の一つである。

例えば、新規プロダクトと運用プロダクトでは下記のようなミッションを持つ。

  • 新規: プロダクトがPMFに到達することに責任をもつ
  • 運用: プロダクト改善施策により目標KPIを達成することに責任を持つ

主な業務

よって主となる業務としては、方針決定・意思決定が中心になる。 また、意思決定を行うにあたり、必要な情報を集めるための分析も広義として当てはまる。

  • 戦略方針の決定
  • 仕様の策定
  • 分析・振り返り

3つのポイント

前置きが長くなったが、ここからPjM → PdMに転身する際の3つのポイントについて詳述する。

f:id:kyosu-ke:20180915235438j:plain

実行の担保 → 結果の担保

5W1Hでたとえるなら、When, HowからWhat, Whyへの視点の変更である。

PjMは担当しているプロジェクトを期限内(When)に限られたリソースで(How)させることに責任がある。 一方PdMは担当プロダクトの成長に責任があるため、実行だけでは役割を果たせない。

実行レベルから業務領域をストレッチして、実行の前段階に存在する、なにをやるのか(What)、そしてそれはなぜか(Why)を明確にしなければならない。 また、最後にその結果がどうであったのかを分析により確認し、次のWhat, Whyにつなげていく。

管理・調整 → 方針・意思決定

上記の責任領域の変更に伴い、帳尻を合わせや整理からロードマップ作成、製品仕様の意思決定にウェイトをよせる必要がある。

PjMであれば、進行に問題が合った場合に、仕様のスコープ削減を提案したり、リソースを要求するなど、整合性が取れない部分の最終意思決定をエスカレーションできる。

一方でPdMになると、そのエスカレーションを受けて、意思決定を行う側になり、理想と現実のギャップに対して、最終的な結果責任を引き受ける役割を担う。

開発現場視点 → ユーザー視点

PdMはより視点をユーザーにフォーカスさせる必要がある

PjMの視点では、いかに期待された機能を、期待された期日に出すかという視点になるため、最終的には期待値を調整することで整合性を保つことができる。( ex. 仕様のスコープを削ってもらう、リソースを追加してもらう、期限を延ばしてもらう)

よって、要求仕様とリソースがマッチしない場合に、収めることを優先して考えるインセンティブが働きやすい。

一方、PdMの視点では、ユーザーに届ける価値が全てとなるので、開発している機能の中心的な価値がなにかを見極め、仕様削減や必要に応じたリリース延期等の意思決定を行う必要がある。 「収めること」ではなく「どんな価値を届けるか」にフォーカスする必要がある。

PjM から PdMになるには

ではPjMからPdMになるには、具体的にはどうしたらよいのか?

主に3つのパターンがある。

  • 1) 急拡大中の組織に入る
  • 2) 新規立ち上げの組織に入る
  • 3) 既存のチーム内で転向させてもらう

1) 急拡大中の組織に入る

急拡大中の組織では、関わる人が増えていく中で、ステークホルダーをまとめ上げながら、実行を推進する力が重宝されるタイミングがある。

また、業績がよく、急拡大している組織であれば、やることが山程ある状態が想定されるので、ポジションへのニーズが強い可能性がある。

2) 新規立ち上げの組織に入る

設立間もないスタートアップ等の組織の場合、人材ニーズによっては近接領域であるPjMからPdMへ転向するチャンスが開ける可能性がある。

採用力のある組織の場合は、PdM経験のある人が採用できてしまうため望みは薄いが、一般的なスタートアップであれば道はあるはずだ。

3) 既存のチーム内で転向させてもらう

自社内や既存チームであれば、PjM業務で組織内の信頼・評価を重ねることで、チャンスを掴める。

所属する組織のカルチャーにもよるが、可能であればこの選択肢が一番無難とも言える。 なぜなら組織内評価を引き継ぐことができ、これまでのステークホルダーとの関係値をもとに成果を上げやすい状態で始めることができるからである。

まとめ

PjMとPdMは似ているようで、実は全く異なる役割を担っており、転向する際には大きな視点の変更が強いられる。

また、PdMはPjMの延長線上にはないため、転向を目指す場合は戦略的に行動を起こす必要があるといえる。