3週目にして少し更新に遅れが出てきましたね 笑
実はアメリカは今週の月曜日はMLK (Martin Luther King’s Day)で会社はお休みということで、更新もちょっとゆったりにしてみました 笑

今回はProduct Development Cycleの一番初めのステップについて書いていこうと思います。

 

PM Responsibility Recap

まずは、前回のログで書いたProduct ManagerのResponsibilitiesについて再記しておこうと思います。

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

前述した通り、今回は一番最初のステップについて書くので、「顧客や会社の抱える問題が何か突き止める」について書いてみます。

このプロセスには定量的なアプローチと定性的なアプローチがあります。
両方このログでカバーしようと思ってたのですが、書いてみると意外と定量的なアプローチが長くなってしまったので(初めは定性的なアプローチに比重を置こうと思ってたのですが。。。)とりあえず、定量的なアプローチで一区切りにして、明日定性的なアプローチについて書こうと思います。笑

Quantitative Approach

非常にざっくりとまとめると下記になります。笑

• 一次情報(自分で作ったデータ)によるImpact/Opportunity Sizeの推定
• 二次情報(誰かが別目的で行ったリサーチ結果)によるImpact/Opportunity Sizeの推定

基本的に一番初めに行う定量的な分析で、問題解決に直接繋がるInsightが発見されることは少ないと思います。どちらかというと、問題の大枠(ユーザー体験のどのフェイズに問題/機会がありそうか)のあたりをつけるために行うというのが一般的だと思います。

既にメインのサービスやプロダクトが世に出ている場合、基本一次情報による分析がここの主になると思いますが、スタートアップであったり大きな会社でも新しい事業を始める等まだ一番最初のサービスやプロダクトが出ていない場合、そもそものデータが社内に存在しないので、二次情報によるリサーチになると思います。ただ、基本的に有用な二次情報は有料な場合が多かったり、データの細かさが具体的なアクションに繋がるInsightを獲れるレベルにないことが多いので参考程度に使って、一番最初のサービスを世に出して実験を通してデータを作っていくと言うのがセオリーかと思います。

一次情報の分析は最終的な”So What” (問題を解決したらどんなうまみがあるのか)に繋がるのでめちゃくちゃ大事なんですが、方法論をちゃんと書こうとすると本一冊分くらいになってしまい、ふわっと書こうとすると逆にあまり書くことがないです。笑

ちゃんと学びたい場合は、Lean Analyticsという本がオススメです！
詳細は上記本を見てもらうとして、読んだ上でProduct Managerの実務レベルで気になる点は、個人的には下記な感じです。

Universal Metrics

基本的に今の自分の担当分野で見つかる機会/問題が一つしかないという状態は結構レアで、多くの場合複数の全く違う機会/問題が見つかります。その時にお互いを比べやすいように、そのチームとしてフォーカスするMetrics(指標)であったり、会社全体で最適化しようとしているMetricsに落とし込んで定量化しておくと、後々の優先順位づけが楽になりますし、チームにとってそのプロダクトを作るモチベーションにもなりますし、さらにリソースの議論(あと何人エンジニアが必要でそれはROI的に理にかなっているか等)もしやすくなります。

Logging Is Everything

ソフトウェアのログをしっかり吐き、かつ分析できるように構成して使えるデータを増やす。結局ユーザーがそのサービス/プロダクトをどのように使っているのかのヒントになる情報(ユーザーが一つのスクリーンにどのくらい滞在していたかとか、何をクリックしたかとか、どこでchurnしたかとか)が一番定量的なInsightを得やすいので、横着をせずに必ず定義をしてエンジニアに必ずプロダクトが世に出る前に実装できるように念を押しておく必要があります。ここをショートカットしてしまうと、世に出た後にプロダクトが意図通りに機能しているのか、ユーザーはちゃんと機能を使っているのかが分からないので、Product Managerとしては死活問題です。

Seasonality

詳しくはタイトルのリンクを参照してみてください。簡単に言うとデータの中のトレンドの発生周期のことです。例えばショッピングのサイトだったら毎年12月になるとクリスマスを見越して購買が多くなるみたいなやつです。Seasonalityという名前的に一年周期を想像しがちですが、取り扱うデータによってトレンドの周期には1年もしくはそれ以上単位のものから一時間またはそれ以下単位のものまであります。もしあなたの分析がある異なる特定の時期のデータ同士を比べるものだとしたら、Seasonalityを無視していないかをチェックしないと分析結果がmisleadingになってしまう可能性があります。

Simpson’s Paradox

これも詳しくはタイトルのリンクを参照してみてください。(こちらはリンク先、日本語です)特にちゃんとしたA/B testingではないけども二つのグループの違いを分析するような場合は、そもそもその二つのグループの特性が違う場合があって、それが本来起こるべきインパクトを隠していたり、逆に誇張していたりします。A/B testingをする場合でも、手法によってこのparadoxが起こってしまう可能性があるのですが、それは後に書く実験のログで解説しようと思います。

Analytics’ Independence

これは特にリーンな組織でProduct Managerが自らデータ分析をがっつり行う場合等に大事なことなのですが、Product Managerはプロダクトに対して強めの意志を持っているので、データ分析においても自分の見たいInsightが顕著に現れるようなデータの切り方をしがちです。特にそのProduct Managerに中途半端なアナリティクスのバックグラウンドしかない場合だと、知らず知らずのうちにバイアスのかかったデータの見方をしてしまっていることがあります。上記でもいくつか指摘してますが、データ分析において陥りやすいトラップを意識しておくこと、スタートアップでもリソースが許すのであればアナリティクスをProduct Managerとは独立して配置して、ニュートラルな目でデータを見やすい仕組みを作るというのが結構重要です。

Product Managerが関わるデータ分析には、上記で説明したような問題を発見するための定量的な分析の他に、プロダクトを世に出す際に行う実験があります。実験もそれ自体非常に大きなトピックなので、後ほどProduct Developmentのプロセス後半で登場する際に解説をしていこうと思います。

今回のQuantitative Analysisの話はわりと当たり前のことを書いてるだけと感じる人も多いと思いますが、笑
明日のQualitative AnalysisではUX Researchについて書いていこうと思っています。こちらの方はあんまり日本でメジャーではないと思うので、参考になる方も少しは多いかもしれないなー、なんて期待しています。笑

前回のログ通り、これから数回かけて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って何？でした！笑