見出し画像

優れたプロダクトマネージャーのなり方・役割・スキルをプロPdMが考えてみた

Shin

ある企業でCPOを担っている人とお茶をしたときに、プロダクトマネージャー（以下PdM）こんな会話がありました。

CPOさん：「いまどこの会社もPdM不足だけど、なんでこんな不足してるんですかね？下手したらエンジニアより不足してそう。」

私：「PdMってキャリアの中で自然発生しないからじゃないですかね？営業とマーケティング、そしてエンジニアの仕事だけしていてもPdMになれないじゃないですか。」

そう、PdMって人のキャリアのどこかでえいや！とチャレンジする機会がない限り、自然発生しないんですよね。だいたいのBiz側の人間が最初はセールス、マーケティングからキャリアをスタートさせますが、PdMからスタートする人はほとんどいません。不思議ですね！

個人的にはPdMの仕事はとても面白くやりがいがあると思いますが、同時に複雑で難しく、求められるスキルセットも多岐にわたります。

私は社会人キャリアのそのほぼすべてをBizDevとPdM（プロダクトマネージャー）として生きてきてスタディサプリやタイムバンク、SmartMeetingなどのプロダクトの立ち上げ、成長に関わってきました。なので私はいわゆる「強制的にPdMやってきた勢」なので誰かに教わったことはあまりないのですが、私自身がSaaS企業などのPdMをするときに気をつけていることを言語化してみました。

そもそもプロダクトマネージャーとは？定義から考える

画像6

そもそもプロダクトマネージャーって何だろう？という点から認識をそろえていきます。

・プロダクトのCEOのこと
・エンジニアのキャリアの派生形
・昔のwebディレクターのことを今どきっぽく言っただけ

などなど色々な定義をされていますが、私個人の定義としてしっくりくるのは、

会社が目指す理想のプロダクトへ近付ける人

です。どういうことか？これを言い換えると、プロダクトが成長している状態を「定義する」人のこととも言えます。簡単に言い換えると、CEOはあるべき姿を決め、PdMはそこに至る道のりを決める人と考えるとわかりやすいかもしれません。

下の図にあるように、ゴールという惑星に向かって進むロケットの指揮官のようなイメージです。ゴールを決めるのはCEOや上司かもしれませんが、どう進むか、どのようなロケットで進むのかはPdMが決めます。

画像4

引用：The First Principles of Product Management

プロダクトが成長する、とは何をもって言えるのか？

そもそも、プロダクトが成長している、とはどういう状態のことを指すのでしょうか？ちょっと考えてみてください。意外と明確な答えが出せる人は少ないんじゃないでしょうか。PdMは、この質問に対して明確な回答を持っている人のことです（そうでなくてはいけません）。プロダクトマネージャーにとっては、

プロダクトの成長 ≒ 理想のプロダクト像へ近づくこと ≒ 事業の成長 

こうなります。厳密には完全にイコールではありませんが、プロダクトマネージャーはその会社が目指すべき理想像をプロダクトを通じて実現する人のことを指します。プロダクトと事業戦略の橋渡しをする人、とも言えますね。多くのスタートアップの場合、プロダクトの理想像はCEOが決めますが、それを現実のプロダクトに落とし込む人のことを指します。

逆に言えば、理想のプロダクト像がない、または近づいていないプロダクト開発は完全に自己満足であり、それは結果的に事業戦略に沿う結果にもなりません。まとめると、PdMは、理想のプロダクト像に近付くためにするべきことをすべて実行・管理する人のことを指します。

ごくまれに、理想のプロダクト像に近づいているのに売上があがらない、ビジネスとして成立しないということもありますが、これはプロダクトマネージャーではなくビジネスモデルの問題、BizDevの戦略ミスなので、今回はこの場合は割愛します。別に私が書いている記事をご覧ください。

PdMがプロダクトのCEOと呼ばれるゆえんは、この理想のプロダクト像を実現させる大役を担っている点にあります。スタートアップの場合はPdMをCEOが担うことがほとんどですが、事業が成長するとプロPdMのような人に権限移譲することがスタートアップの黄金ルートになっています。

プロダクトマネージャーのスキルセットとその身につけ方

プロダクトマネージャーのスキルセットを語るときに有名なのが、こちらのトライアングルです。

画像2

引用：https://productlogic.org/2014/06/22/the-product-management-triangle/

もともとの記事が英語なので簡単に翻訳をして整理すると、こんな感じになります。

名称未設定-1

まずトライアングルのうちの1つを磨くことが大事

最初に書いておくと、このトライアングルをすべて完璧に満たすことを目指すと挫折しますし、この3つはPdMにとって同じ価値があるものでは実はありません。

トライアングルのどこから磨いていくべきか？基本的にBizの人がPdMになるためには①→②→③の順がおすすめです。というのも、このトライアングルは3つが平等に語られていますが、プロダクトマネージャーとして仕事をするうえで、①のプロジェクト管理、仕様管理のスキルが最も求められることが多く、②と③は他の人を採用することで代替が可能なのです。①はあまり代替がきかず、経験・知見がもっとも差別化要因になるところなので企業はこぞってPdMの採用に力を入れているわけです。ドラクエでたとえるならPdMは魔法戦士です。最初は誰でも魔法使いから始まりますが、一定レベルを超えると戦士スキルも身につけられるようになるイメージですね。賢者が大賢者になるのとはちょっとイメージが違います。

3つ全てを満たすよりは1つでもいいので強みとなる分野の経験をする、スキルを身につけることが良いPdMになるための最短ルートだと思います。トライアングルのうち1つのスキルを身につける過程で、他の2つを強みとする人と一緒に働く機会があるので、結果として1つ磨いていることが他の2つを伸ばすことにもなります。3ついっぺんに身につけるのは不可能なので、まずは強みとなる1つを磨いてください。

また、Biz側の人の多くはセールスまたはマーケティングだと思いますが、こういう人がBizDev的な発想を持つことはそんなに難しくありません。BizDevとは基本的にセールスとマーケティングをビジネス成長のための手段だと捉える（目的ではなく）人のことを指します。セールスの人にとっては営業は手段であり目的になりますが、ここを1つ視点を上げて手段だと割り切る考え方ができたら、BizDevの仕事がしやすくなります。要するに異なるスキルを身につけるのではなく、考え方を1つ俯瞰して見るだけでセールス→BizDevの発想になりやすいので確実にスキルとして身につけやすいということです。

エンジニアの方であればまず技術スキルを高めることが大事です。①でいう技術仕様はエンジニアのスキルと直結しますが、プロジェクト管理スキル（お金や時間の調整をして開発プロジェクトを管理すること）はまた別のスキルなので、ある程度技術を高めた人がチャレンジすることが多いです。

一方で、エンジニアから始まった方はどうしても何かを考えるときに「これ実装可能かな？」という発想をしてしまいがちで、あるべき理想像から逆算することが苦手な人が多いので苦戦するかもしれません。あなたがもしエンジニアで、PdMやCTOを目指したいのであればBizDevスキルは必須なのですが、DevelopersとBizDev領域が両方できる人はかなり稀なのでもしできたら一気に市場価値が上がるので頑張ってください（こういう人もっと増えてほしい！）。


プロダクトマネージャーの役割と仕事の流れ

プロダクトマネージャーという言葉のイメージが曖昧なことが多く企業によってロールが変わることも多いのですが、私個人としてはプロダクトマネージャーの役割は「上司や他の部署を巻き込んでプロダクトを改善すること」が最も大事だと思います。

実は、PdMは1人だと何もできません。目指すべきプロダクトを決めるのはCEOなど創業者で、実際に作るのはデザイナーやエンジニア、出来たものを売るのはセールスやマーケティングの人です。そんな中でも、こういう多様な人と一緒に働き、力を借りながらプロダクトを改善していくことが求められます。

【基本的なPdMの仕事の流れ】
1. あるべき理想像を決める（with CEO・創業者・上司）
2. その実現プランを考える（with エンジニア・デザイナー）
3. 作る（with エンジニア・デザイナー）
4. お客様に提供する（with セールス・マーケティング）
5. お客様からのフィードバックを拾う（with セールス・マーケティング）
6. 軌道修正し理想像を修正する（1に戻る）

このように、他部署の人と働くことがデフォルトなので、他部署の人がどう働いているかイメージできる高い解像度があるとグッと仕事がしやすくなります。実際、どういう人がPdMに向いているのか？を考えると、うまくいっているPdMで圧倒的に多いのはサーバント型（仕えるように手助けするスタイルのこと）が多いそうです。

いわゆるカリスマ的なオラオラ系のリーダーシップはPdMにはあまり向いていないのでしょう。オラついてる人にあんまり近付きたいと思う人っていないですしね。自分では何もできないから、他人の力を借りてプロダクトを作ることがPdMの面白さであり難しさです。実際、スタートアップのほとんどが創業者がPdMを担うことが多いのは、CEOの仕事は「PdM＋BizDev＋ファイナンス＋その他雑務すべて」だからです。

プログラムを書いてみると一気に仕事の解像度が上がるのでおすすめ

PdMになるために、自分がプログラムを書ける必要はありません。私自身、新卒のころRailsやObjective-Cを写経したことがありましたが、今はもうほとんど忘れてしまいました。ただ、自分でプログラムが書けなくても、プロダクトがどういう仕組みで動いているのか、インターネットサービスが動く仕組みは知っておくと一気に仕事がしやすくなるのでおすすめです。実際、アメリカで働いているPdMのうちわずか5％しか自分でコードを書けないという統計データがあります。

Luckily for product managers, it’s often not mandatory to know how to code. Only 5% of product managers know how to do this.
コードを書けるPdMはわずか5％しかいないので、幸運なことにコードが書けることは必須スキルではありません。

But this makes it even more important to communicate with your different teams to get your idea implemented in the product. You have to trust in your team’s abilities.
あなたのアイデアを実現するために異なるチームと協働することが求められるため、チームメイトのスキルを信じる必要があります。

If you do know how to code, this could give you an advantage when you want to apply for a product management job in software development.
もしあなたがコードを書けるようになれば、それはソフトウェア企業で働くうえで大きなアドバンテージになります。

引用：Product Management Statistics: 20+ Eye-Opening Insights

特にPdMは他の部署の人との協働がキモになるので、Bizだけでなく開発のことを理解していることは大事だと思います。ノンエンジニアの方でも、クソコードで構わないので少なくとも1回くらいプルリクエストを出してみると一緒に働いているエンジニアから「おっ！」と見直されるかもしれません。少なくとも、歩み寄ろうとしてくれるPdMはエンジニアから嫌われにくくなりますのでメリットしかありません。おそらくプルリクエストはそっとクローズされますが、それはそれでご愛嬌です。

機能開発のフレームワーク

私がフリーランスとして仕事をする中でよくされる質問が「どうやって機能開発の優先順位をつけたら良いですか？」というものです。これは事業やプロダクトの状態によって変わるのでなんとも言えないのですが、基本的な考え方のフレームワークはあるので、私がいつも考えていることをまとめてみました。

理想のプロダクトを作るために必要なものを判断するうえで参考にしてください。

タイプ1：ベースの機能開発

名称未設定.001

考え方としてはこんな感じで、基本的にユーザー価値が向上するもの意外はやらないのが原則で、開発工数に対してどれくらいユーザー価値が向上するか（≒理想のプロダクト像に近づけるか）で決めます。PdMとして仕事をするのであれば、何かを開発しようとしたとき、簡単に技術的な見積もりまでできると仕事がかなりスムーズになります。

特に個人的にPdMがやるべきだなと思うのは、エンジニアでない人からの開発リクエストに対してやること・やらないことを判断することです。この判断が良いほど、プロダクトは成長しエンジニアも楽しく開発ができると思います。俗に言う炎上案件というのは、PdMにあたる人が無茶振りを打ち返せないときに起こることがほとんどですからね…私も経験があります。上司や周りの人に無茶振りをされそうになってもしっかり断れるようになるとエンジニアから感謝されるので、そういう意味でもPdMであってもある程度プログラムを書いた経験は役立つと思います。

タイプ2：保守・運用の機能開発

インターネットサービスには保守運用やパフォーマンス向上など、新機能ではないけどメンテナンスとして必要な開発があります。この場合も基本的には同じ考え方で、開発工数が小さくサービスのパフォーマンスが向上するものからやっていきます。

・サイトの読み込みが早くなる
・不具合が減る
・より使いやすくなる

などの場合です。ただし保守運用コストはサービスによって大きく変わるのと、PdMだけでは判断がつかないことも多いので、SREチームやインフラエンジニアの人と相談しつつ決めると良いでしょう。例えば、Abema TVのようなロードバランシングが大事なサービスと、一般的な業務SaaSとでは気にするポイントが変わるものなので、私もこの領域は自分だけで判断せずプロの意見をもらうようにしています。

ここは会社によってはPdMが関わらないこともあります。

タイプ3.：受注するために必要な追加の機能開発

こちらはちょっと特殊な考え方ですが、特にSaaSなどクラウドサービスを作っている場合に実はよくあります。例えばこういうものです。

・セキュリティ基準が満たしていないとセキュリティチェックが通らない
（マルチテナンシー、暗号鍵の保管など）
・すでに導入しているサービスとの連携
（他SaaSとのAPI連携など）
・社員数がものすごく多い、社内システムとの兼ね合いなど特殊事情がある場合
（csvインポート・エクスポート、オンプレなど）

このように、どうしても受注したいけれど今のままでは受注できない場合、PdMは工数をかけてでも受注するか、受注しないかを判断する必要があります。世の中いろいろな企業があり、いろいろな事情があるため、一律にこれ！とサービスをすんなり受け入れてくれるとは限らないのが辛いところです。特に大企業からの受注をしたいスタートアップは、この判断で悩むのが常なんですよ…（遠い目）。

クラウドサービスの場合、個別対応をすればするほど保守運用コストも跳ね上がるため、乱発すると自滅しかねませんので、このバランスを絶妙に取ることがPdMの大事な仕事です。場合によっては経営判断にも関係するので、CEOなど役員レイヤーと相談する案件にもよくなります。

以上の3つのカテゴリの機能開発の中から、PdMは状況によってするべきことの重要度、緊急度を振り分けていくことが仕事になります。ここにセンスが問われるのが面白くも難しいポイントだと思います。

機能開発の優先順位の付け方・考え方

お客様のニーズが大きいものからやる、が原則
前述したように、お客様への提供価値が大きくなるものからやるが原則です。しかし、これを実行するためには、セールスやマーケティングなどの部署と連携をしてお客様のフィードバックをいただく体制を作っておくことが大切です。お客様の声なき機能開発は自己満足であり、良い結果になる可能性は低くなります。

ただし注意なのが、数少ないお客様だけが言っていることや、特殊な事情のあるお客様が言っていることを鵜呑みにしてしまうことです。こういう場合は、あえてやらない判断をすることもPdMの大事な仕事です。

自分たちのサービスがやるべきか？を問い続ける

PdMをしていると「この機能、要望は多いけどどうしようかな…」と悩むことが必ずあります。この判断は非常に難しく悩ましいのです。なぜなら、この問に対して正解はなく、会社やプロダクトによって異なるからです。

同じ機能を提供しているサービスでも、創業者やPdMが変わると実装される機能がガラッと変わることはザラにあります。

身近な例で言うと、チャットツールのSlackとMicrosoft Teamsは同じチャットでも考え方が異なります。実際に使ってみると分かるのですが、主に使う機能がこんな感じで異なります。

・Slack：テーマごとに分かれたチャンネル
・Teams：テーマごとのスレッド

それぞれサービスの特徴、哲学が垣間見えます。機能は同じでも、提供方法が変わるものなので、ここにこそPdMのこだわりを発揮するべきところです。この禅問答、解なき問にこだわることがPdMの仕事の醍醐味と言えるでしょう。

PdMは機能比較表を見て判断をしてはならない！

特にSaaSなどクラウドサービスでそうなのですが、競合がこういう機能を提供しているから、という理由で機能開発の優先順位を高めてはいけません。なぜか？

基本的にクラウドサービスは常に機能開発があり改善され続けるものなので、競合サービスなどと比較して現時点での機能だけで比較をしてやる・やらないを判断しても意味がありません。それよりも大切なのは、どういう体験をお客様に提供するべきか？その理想像は何か？から逆算して考えることがPdMの仕事です。

実際に私も経験したことがあるのですが、他社さんのSaaSを導入検討していた時、似たようなサービス2つの間で悩んでいました。最終的には、多機能で何でもやれるサービスよりも、1つの機能をUX高く提供している（かつ値段も高い）ほうを導入決定したことがあります。それぞれ考えがあると思うので良し悪しではありませんが、しっかりユーザーのニーズに答えている機能があるほうを選ぶことが長期的に良いプロダクトになる可能性を高めるでしょう。


機能開発は「理想から逆算する」と「実験的にやってみる」のバランスが大切

一般的な機能開発の優先順位付けフレームワークはあっても、実際に開発をするときはやってみないと分からないことがほとんどです。そういう時は、実験と割り切ってクイックに実装してみてお客様のリアクションを見る、というのも機能開発を進めるうえで大切になってきます。実験なので失敗しても良く、その場合は「学習」が成果になります。この学習サイクルを素早く回せる開発組織は、お客様のニーズを大きく外しにくく成長角度が上がっていきます。

もしクイックに検証できない機能開発をする場合は、実際に実装をする前にLPやGoogleフォームなどで疑似体験をしてもらう、ユーザーヒアリングをじっくりするなど、あらかじめリサーチをすることで失敗確率を減らすこともできます。百発百中はなくても死なない程度に当たり続けることがプロダクト開発ではとても大切です。

喩えるなら、プロダクト開発はフルマラソンのようなもので、42.195キロ走破という高い理想を目指しつつ、目の前にあるコースをどう進むかは走りながら決めるような感じです。

画像6

Note that working backwards isn’t universally better, it just creates a different perspective.
逆算する開発が必ずしも良いとは限らないので異なる観点で考えることは大切です。

引用：Product Management Mental Models for Everyone


PdMになるのは大変、でもものすごく面白い

アメリカの大学ではいまPdMになるための講座がものすごく人気らしく、エンジニアに続いてプロダクトを作れる人材の価値はどんどん上がっているようです。

日本では人材不足が理由でエンジニアがPdMになったりセールスからコンバートされたりすることが多いですが、いずれPdMのノウハウも体系立っていくでしょう。日本でももっとPdMが増えて、良いプロダクトが増えることを応援しております！

いいなと思ったら応援しよう！