前回のログ通り、これから数回かけてProduct Managementについて書いていこうかなーと思ってます。今回はその第1回なので、大枠のProduct Managementって何？についてです。

※このログを含め、本ブログの内容は全て僕の個人的見解/意見/主張で、過去に僕の所属していた組織や現在僕の所属する組織の見解/意見/主張と必ずしも一致するものではありませんので、その点ご理解いただいた上で読んでみてください。

So, what is it?

A PM is responsible for making sure that a team ships a great product
(Product Managerの職務とは、チームが素晴らしいProductを世に出すことを担保することです)

Cracking the PM Interview

まずは、Product Managerになりたい人必読と言われている就活本、Cracking the PM Interviewからの定義の引用です。PMの定義については色々なところが色々出していますが、大枠でいうとまさにこれがProduct Managerの本質だと思います。

…と言われてもあんまりピンとこないかもですよね？笑
特にProduct Managerという仕事を見たことがない方や、したことがない方にとっては。ぶっちゃけMBA就活時は僕もそうでした。

僕はProduct Managerがいない製品開発組織(日本)もProduct Managerのいる組織(シリコンバレー)も経験できたので、その経験から両方の組織を比較してみたいと思います。

日本で働いていた組織では（少なくとも当時は）単純に「製品を作って世に出す」ということが主なフォーカスでした。エンジニアが何人かの顧客の業務を聞いて、想像でその業務を解決するためにはどういう機能が必要か考えて、製品スペックを定義して開発というプロセスを辿っていました。こういう組織ではぶっちゃけProduct Managerは組織に必要ないかもしれません。

シリコンバレーの企業では「問題を実際に解決する」ということが主なフォーカスです。会社全体としてそこにフォーカスしているので、「問題が実際に解決されたかどうか」を検証するプロセスがあります。また、シリコンバレーでは、エンジニアの単価がめちゃくちゃ高いです。日本で働いていた組織も日本ではまぁまぁのお給料を支給していましたが、シリコンバレー企業はたぶんその2-4倍払っていると思います。そういう環境なので、エンジニアのROIの最大化は会社にとってとっても重要な課題です。こういう環境ではProduct Managerが必要で、「顧客や会社の抱える問題を解決するのに最適化された製品を作って世に出し、その問題解決において製品開発チームのアウトプットを最大化する」ことを専業的に扱います。

文字ばっかりだとわかりづらいかもなので、イメージを書いてみるとこんな感じです。

製品開発チームのそれぞれ(エンジニアだったりデザイナーだったり)がそれぞれの思う「こういうプロダクトだといいと思う」に基づいて行動すると赤の矢印になってしまうことがよくあります。「このプロダクトはいろんなことにタッチしているけど、一番解決したかった軸で判断すると必ずしも最適ではない」という状態です。

これがプロダクトマネージャーという「プロダクト全体を通して意図した問題を最も効果解決していること」を担保する役割の人をチームに配置することで、プロダクト開発の(デザインであれ、テクニカルアーキテクチャであれ)各意思決定フェイズでチームを正しい方向に導けるので、プロダクトの成功確率をあげることができます。

How do they do it?

Responsibility

「顧客や会社の抱える問題を解決するのに最適化された製品を作って世に出し、その問題解決において製品開発チームのアウトプットを最大化する」というのがProduct Managerの仕事であることはわかったので、じゃあ具体的にそれをどうやって実現しているのかをまとめてみます。それぞれのトピックはそれ自体が1ログ分以上くらいの分量になりそうなので、今回はあくまで大枠のまとめです。

• 顧客や会社の抱える問題が何か突き止める
• 顧客や会社の抱える問題はどうやって解決されるのが最適か突き止める
• 定義された解決策が実際にその問題を解決することを確かめるために必要な最小限のProduct(MVP)と、MVPから理想のProductに発展させるためのロードマップを定義する
• エンジニアのチームによるMVPの実装を意思決定面からサポートする(実装時にわかった障壁をどう克服するか)
• アナリティクスのチームによるMVPの実験/検証計画の策定の意思決定面からサポートする
• 実験結果とInsightをチームに共有し、それらに基づき次のステップを定義する
• マーケティングチームによるGo To Market Strategyの策定をサポートする
• 実験からの学びに基づいたPivotを含め、Product Roadmapを次に進める

会社の規模や文化によってそれぞれの項目で具体的にProduct Managerが何をするか、どこまでするかは大きくことなりますが、項目レベルではどこもここら辺が製品開発におけるProduct Managerの職務範囲だと思います。

Hyper Growth企業ではProduct Managerが各項目どんなことやってるのかというのは、次回以降各論解説していけたらなーと思っています。

Mentality

次にもう少しソフトな部分も簡単に解説してみたいなーと思います。

Fall in love with the Problem not the Solution
(問題と恋に落ちましょう、特定の解決策ではなく。)

Facebook Product Management

Product Managerをするにあたって、まず一番初めに出てくるのがFacebook発祥と言われてる上記です。Product Managerをやってみたい人にとっての一般的なProduct Managerのイメージは、アイディアマンでクリエイティブで他の人が思いつかないような斬新なアイディアを思いついて周りにピッチするのが上手い人、だったりするのですが、
Product Managerにとって一番大事なことは、問題を解決することです。自分が思いついたアイディアだけに固執せずに、その問題を最も効率的に解決するアイディアを採用するのはその第一歩だったりします。

Product Manager is The Heartbeat of Product
(Product ManagerはProductの”鼓動”である)

Uber Product Management

たまに受ける日系IT企業の方の就活相談等で、「Product Managerはエンジニアを部下に持つんですか？/どういった役職を部下に持つんですか？」という質問を聞いたり、アメリカでも”Product Manager is a mini CEO of the Product”というような言い方をされることがあります。

これはProduct Managerの特徴なのですが、基本的にProduct Managerは製品開発チームのメンバーを部下に持ちません。エンジニアやアナリティクス、マーケティングその他の役職とは基本的に独立した組織にいることが多いです。

こういった組織構造にあるので、Product Managerはエンジニアもその他の職種に対して直接的/組織的な権限はないですし、彼らも基本的には「Product Managerが言ってるから、これをしなければならない」という風にはなりません。Product Managerは彼らがそのProductを作るべきであることを、権限を使わないで説得しなければいけないのです。

説得の大前提として、Product Managerがチームの中で、その問題が解決されることに対して一番パッションを持っているべきで、態度や振る舞いからもそれがひしひしと伝わってくるべきというのがありますが、製品開発チームには様々な職種がいて、それぞれ響くポイントは異なります。例えばエンジニアやアナリティクスの中には「それを解決することでどんな定量的なインパクトがあるのか」に魅かれる人がいたり、デザインの中には「その問題によって顧客がどんなふうに困ってるか」に魅かれる人がいたり。チームのメンバーがどういうところに魅かれていて、自分の問題が解決されるべきなことをどうやってそれぞれのメンバーに伝えるかというのがProduct Managerの腕のみせどころだったりします。

Product Managerがチームの心臓となって、血をチームの各器官に循環させてチームの士気を高める。結構ソフトなスキルですが、特に組織上特別な権限を持っていないProduct Managerには重要なスキルだったりします。

How are they different from other “Similar” Roles?

さて、もうすでに長くなってますが、笑
このトピックは多分このログにしかうまく当てはまらないので、最後にここだけ解説して終わります。笑

Project Manager and Technical Program Manager

日系企業/非テクノロジー企業だとProject Managerが結構似た役割を果たしていることも多いんじゃないかなーと思います。また、テック企業でも似たような職種にTechnical Program Managerというのがあります。
これは完全な私見ですが、それらの職種とProduct Managerの大きな違いは、前者はフォーカスがプロジェクトの円滑な遂行であるのに対し、Product ManagerのフォーカスはROIの最適かにあることだと思います。

テック企業だと一つの製品開発チーム内にもProduct ManagerとProject Manager/Technical Program Managerが共存することはよくあります。それは、Product Managerが何を解決するべきで、それをどう解決して、どうやって検証するかにフォーカスしているのに対し、特に関わるステークホルダーの数が膨大な場合、各個人の各タスクのトラック、ステークホルダー達へのプロジェクトの進捗報告、外部エンジニアリングチームとのタスクレベルでの連携等をProject ManagerやTechnical Program Managerが担っているというように職務の住み分けがなされているからです。チームの関わる関係者の規模が小さかったり、チーム自体に十分なリソースがない場合はProduct ManagerがProject Manager、Program Managerの職務を兼任するということも多々あります。

余談ですが、そういったケースだと、例えばエンジニアから直接見える主なProduct Managerとの関わりがProject Managementだったりするので、(特に小規模チームの)エンジニアからも「Product Managerとは主にProject Managementをする人だ」という誤解が生まれがちだったりします。

ということで、まとめと言っておきながらあんまりまとまってない気も多分にしますが 笑
とりあえず日本語作文のリハビリ第一弾として、Product Managerって何？でした！笑