2021/12/27
物流techの207株式会社でプロダクトマネージャー（以下、PdM）をしている黒川恭です。 先日まで各社、各コミュニティのアドベントカレンダーがTwitterのタイムラインを賑わしており、たくさんの記事たちに刺激を受けたので、自分も筆を取ってみました。
本エントリでは、PdM1年目に教えてほしかったこと・あまり分かっていなかったことへのアンサーを現在の自分なりに書こうと思います。 今の自分の考えをスナップショット的に残すとともに、これからPdMになりたい人、なりたての人に何か一つでも気づきがあれば嬉しいなと思いながら書きます。 また、あくまでこれはスナップショット=現時点での自分の考え方であり、自分自身の定点観測的にも毎年アップデートしたことを書けたらいいなと思っています。
PdMとは何をする人なのか
まず、PdMとは何をする人なのでしょうか。 私自身はカスタマーサポートを7ヶ月、シェアサイクルサービスのオペレーションマネージャーを1年半、その後PdMに転身したというバックグラウンドを持っており、PdMになる前からPdMという職種の人とずっと一緒に働いてきました。 しかしながら、PdMになったばかりの頃は自分が何をする人なのか、どの部分において責任を追うべきなのか、分かっているようで分かっていなかったように思います。 なので、まずは役割の定義から始めたいと思います。
私はPdMとは「プロダクトの全てに責任を持つ人」だと考えています。 以前はよく海外の記事などで「PdMはミニCEOだ」と言われたりもしていましたが、自分の中では極めてそのイメージに近いです。 プロダクトの成功のために必要なあらゆることを考え、それを全てやる（あるいは適切なメンバーをアサインし、マネジメントする）。そんな役割です。 プロダクトマーケティングマネージャー（PMM）のいる組織のPdMや、一つの機能に複数人のPdMがいる大型の開発組織のPdMとは若干ずれる部分があるかもしれませんが、自分個人としてはPdMの役割をこんな感じで定義しています。 また、PdMの役割の交点としてよくBusiness・Technology・Designが語られますが、インターネットの事業会社では基本的に「プロダクトの成功 = 事業の成功」となるので、PdMはこの中でも特にBusinessに最も責任を負う意識を持つ必要があると考えています。
to Bのサービスおいては明確にビジネスモデルが必要になるのはいうまでもありませんが、to Cのサービスに関しても同様だと考えます。 一昔前までは一定のMAUを作ることができればマネタイズは広告を中心にどうとでもなる、といった風潮も一部ありましたが、昨今ではYouTubeやTikTokくらいのメガサービスでない限り広告だけで黒字化するのはかなり難しいイメージがあります。そういった意味でもBusinessに対して責任を追う意識はPdMにとって重要だと考えます。
PdMに求められるスキル
まず、PdMには「パッと見てスキルと呼べるか分からないが実は重要なスキル」がたくさんあるということを認識しておくことは大事な気がします。 例えば「良いKPIを設計できる」は重要なPdMのスキルだと考えていますが、「UIデザインできる」「プログラミングができる」「データ分析ができる」等に比べるとスキルと認識しづらいと思います。ですが、PdMにはこういったスキルがたくさんあり、この総合力を高めていく必要があります。 PdMやプロダクトマネジメントに必要なスキルの全体像を掴みたい方には『プロダクトマネジメントのすべて』がオススメです。 （何かにつまづいたとき、辞書的な存在としても頼りになります）
そんな感じでたくさんのスキルが求められるPdMではありますが、その中でもまずはここから始めなければいけない、と思うスキルに絞って以下にあげていこうと思います。
課題を見つける
まずPdMにとって最も重要なスキルは「ユーザーの課題を見つける」ということです。 なぜならプロダクトを作るというのは課題を解く、ということであり、そのためには課題からスタートする必要があるからです。何ならプロダクトを作ることは手段でしかありません。 これは新しいプロダクトを作る時はもちろん、既存のプロダクトに新たな機能を加えるときにも共通して言えます。 また、ただの課題ではなく、「今すぐ解決したい課題」「お金を払ってでも解決したい課題」を見つけなければなりません。そうでないものは使ってもらえません（本当に使ってもらえないので覚悟してください）。 課題の見つけ方については以下の記事、書籍をオススメします。
上記した記事・書籍を読んでいただければ初手としてはバッチリだと思いますが、あえて自分の口から何かいうとすれば、ユーザーの課題を見つけるためには一次情報に当たることが大事だと思います。 ユーザーインタビュー、ユーザービリティーテスト、フィールドリサーチなど手法は色々ありますが、自分の目で見て生の情報からインサイトを得ることが大事です。 また、この際に大事なのは問題の本質に行き着くまで問いを繰り返す、ということです。 例えばユーザーインタビューやお問い合わせで「○○という機能がほしい」とユーザーから機能要望の声が寄せられることがあります。 「ユーザーは自分が欲しいものを知らない」とはよく言いますが、「なぜユーザーはそう思うに至ったのか？」「何に困っていてそういう発想が出たのか？」それを考え、語られた言葉から本質を導き出すのもPdMの仕事です。
向かうべき方向を決める、伝える
解くべき課題を見つけたら、どのように解くのか？どのような順番で進めていくのか？といった向かうべき方向を決めなければなりません。 どのように解くのか？はプロダクトの具体的な部分になることが多いです。ここは答えが無数にあるので、解けるまでアプローチするというマインドセットの方が大事です。ときには解こうとしている課題が正しいか？に戻ることもあります。 解くべき課題への向き合い方については10X CEO矢本さんのBlog記事がオススメです。
どのような順番で進めていくのか？は「戦略」と呼ばれたりします。解くまでの道筋を描く作業です。戦略を考えるにあたっては下記の本がオススメです。
上記の本からインスパイアを受け書かれた高橋京輔さんのBlog記事もオススメです。 （本を読んだ後に振り返り的に定期的に読むとめっちゃ良いです）
決めた向かうべき方向が正解か不正解かはやってみるまで誰にも分かりません。 一方で、なぜそう決めたのか？を言語化し、メンバーに伝えることはしっかりとやらなければいけません。 どの課題を解こうとしているのか、なぜその機能が必要なのか、なぜこの順番で取り組むのか、といった向かうべき方向を伝えることは新たな議論が生む火種となりますし、エンジニアやデザイナーがなぜ今この作業をするのか？の目的を明確にします。 そのための言語化スキル、ドキュメンテーションスキルは身に付けなければなりません。 口頭で伝えることも大事ですが、ドキュメントは齟齬をなくし、伝言ゲームを防ぎ、結果的にコミュニケーションのコストを下げる最高のツールです。非同期で伝えられるという利点もあります。 言語化、ドキュメンテーションのスキルを高めるには下記の本がオススメです。
技術知識はなくてもいい、自分のペースで少しずつ
非エンジニアのバックグラウンドからPdMに転身するとき不安に思うことの一つに「技術知識がどの程度必要なのか？」があると思います。 ざっくり結論からいうと、個人的にはPdMに技術知識はなくてもいい、と考えています。 なぜならPdMの役割はこれまで書いてきたように、解くべき課題を設定し、向かうべき方向を決め、プロダクトを成功に導くことだからです。 このPdMの役割を全うし、バリューを発揮し続ければ技術知識がなくても必ず信頼してもらえます。 技術的に分からないことがあれば、エンジニアに聞くのが一番です。 多くの場合、想像しているよりもずっと丁寧に説明してくれます。目的に向かって協力していくことが大事です。
一方で、技術知識があった方が良いというのは紛れもない事実です。 エンジニアとのコミュニケーションコストは下がりますし、開発管理もしやすくなります。 薄っすら知っているだけでも全然違うので、少しずつ自分のペースで知識をつけていくといいと思います。 そして、最初に勉強するなら個人的にはSQLという言語をオススメします。 SQLをオススメする理由は2つあって、1つ目は自分でデータ分析ができるようになるということです。前項で触れた一次情報には当然データも含まれます。これを自分で抽出・加工し分析できるのと、都度人に依頼しなければいけないのとではスピードも大幅に変わるので、技術知識というよりはPdMのスキルとして身につけることをオススメします。 2つ目に、SQLを勉強することでプロダクトを理解する上で基本となるデータベースへの理解が深まるので、その後の様々な技術知識を学習する上での効率が格段に上がります。 SQLの勉強には下記の本をオススメします。
自分はこの他にUdemyの講座を参考にRubyを使って簡単なアプリケーションを作って見たりなどしました。
また、技術知識は薄くてもエンジニアが日々どういうことに向き合っているかを理解することは重要です。 特に「開発には不確実性が伴う」ということはしっかりと理解してコミュニケーションを取る必要があります。 コミュニケーションについて学ぶには下記の本がオススメです。
終わりに~常に先を見て行動~
最後に常に先を見る重要性について、少し触れようと思います。 PdMは自分がボールを蹴り出すことからあらゆることが始まります。なので、常に先を見て一緒に働くメンバーの手を止めないことが大事です。 メンバーが1ヶ月先にやるタスクの準備を今日する意識を持ちましょう。 また、あらゆる計画は計画通りに進みません。常に先を見てプランA、プランBを持ち、状況に応じて次の手を打てる準備ができるといいと思います。
さて、色々と偉そうに書きましたが、1年目の自分に向けて書いたと思って大目に見ていただければ幸いです。 以下、宣伝です！
- Twitterをやっております、よろしければフォローお願いいたします
- 主にプロダクト作り、キャリア、組織、207についてつぶやきます