このガイドは、Elad の著書 High Growth Handbook からの抜粋です。この書籍では、スタートアップが直面する最も複雑な課題をナビゲートするルールブックを提供しています。
優れた製品管理組織は、企業が製品のビジョンとロードマップを設定し、目標と戦略を確立し、ライフサイクルを通じて各製品の実行を推進するのを支援します。
一方、悪い製品管理組織は、エンジニアのためにスケジュールを管理し、文書を整理するプロジェクト管理グループとして機能しています。
優れたプロダクト組織を構築するには、まずプロダクトマネージャーの役割を理解する必要があります。次に、強力な製品担当副社長など、適切なスキルを持つ人材を採用する必要があります。最後に、製品組織を有効にし、製品開発の規模を拡大するためのシンプルな一連のプロセスを確立します。
プロダクトマネージャーの仕事とは?
プロダクトマネージャー (PM) は、製品の成功に直接責任を持つ、部門横断的なオーナーです。PM を「製品のゼネラルマネージャー」または「製品の CEO」と呼ぶ識者もいます。実際には、PM は製品に直接責任を持つ個人です。PM は製品の成功に全責任を負いますが、多くの場合、他の部門からの直接の報告はありません。
プロダクトマネージャーは、次のような役割を担っています:
製品戦略とビジョン
製品の目標は何か? 顧客は誰か? 主な機能とユースケースは? 成功をどのように定義し、製品を追跡するためにどのような指標が使えるか? 競合の勢力図はどのようなものか、競合に対して製品をどのように位置づけるべきか? 製品をどう差別化するか? 主な販売チャネルは? 製品のビジネスモデルは? 製品の価格設定はどうすべきか? PM は他の多くの部門 (デザイン、マーケティング、セールス、エンジニアリング、データサイエンスなど) と協力して上記の質問に答えますが、最終的にはこれらの質問を問い、答える責任があります。
製品戦略とビジョンは、顧客の声を反映したものでなければなりません。PM は、ユーザーの意見やフィードバックを製品ライフサイクルに取り入れることを最優先すべきです。
製品の優先順位付けと問題解決
PM は製品ロードマップのオーナーとなり、それには適切なトレードオフがあることを保証する責任があります。この戦術的側面には、製品要求文書 (PRD) の作成とフィードバックの受領、製品ロードマップ作成セッションの組織化とディレクション、上記のすべての機能との連携、機能対影響および必要な作業に関するトレードオフの決定などが含まれます。簡潔な PRD は、製品とその実行に関する簡潔な合意を推進する上で、大きな違いをもたらします。PRD は、主要な機能と製品ニーズを明確に示すものでなければなりません。
これらの責任は、PM がデータおよび顧客主導であることを必要とします。適切な指標を定義し、その指標について合意を得、そしてそれを追跡することで、製品の優先順位についてより整合性をとることができます。PM が技術的であればあるほど、重要なトレードオフを行うために必要なデータを分析できる可能性が高くなります。それと並行して、PM は顧客のニーズを理解し、エンジニアリングコストやビジネスインパクトとの相対的なトレードオフを行うように努めなければなりません。
PM はまた、製品やその開発の側面に関する問題解決にも時間を費やします。例えば、法律や規制上の問題を回避するために、製品にどのような工夫や変更が可能か? 販売上の競争や価格に関する懸念に対処するために、どのように機能を変更することができるでしょうか?
注：プロダクトマネジャーは一人で取り組むものではありません。製品の構築と関連する問題の解決はチームワークです。PM は、エンジニアリング (技術的制約や機能のアイデアについて)、デザイン、データサイエンス、マーケティング、セールス、サポート、法務 (規制問題について)、その他の部門と調整します。しかし、プロダクトマネジメントの最終的な役割は、デザインチームが求める原始的でプラトニックな理想の美しさ、エンジニアリングが求める技術的な魅力、セールスが求める「とにかく売れるものを」、法務が求める「これはリスクが高いかもしれない」というトレードオフを行ったり、提案したりすることです (これらの例はすべて意図的に誇張したものです)。
実行: タイムライン、リソース、障害物の除去。
製品を成功に導く一環として、PM はエンジニアリングと密接に協力し、期限内に目標を設定し、達成する必要があります。多くの場合、PM がチームの目標達成を支援できる最大の方法は、エンジニアリング、デザイン、その他の機能からリソースや注目を集めるための働きかけ、機能の削除や優先順位付け、実行のための明確なロードマップの提供、各機能がタイムラインの短縮や不要な機能や作業の削除が可能かどうかを確認するための「くだらない」質問、社内 (デザイン、セールスなど) であれ社外 (顧客、パートナー) であれ、余計な要求を押し返すことなどです。
多くの人は、製品の実行は製品を発売した時点で終わるものだと考えています。実際には、製品のメンテナンス、機能の反復が継続的に行われ、最終的には製品の廃止や終了が行われます。製品の廃止は、顧客をその製品から移行させ、顧客の反発を招く可能性のある価格変更やその他の問題に対処するため、それ自体が妙案となり得ます。
注意しなければならないのは、PM はプロジェクトマネージャーではないということです。彼らの基本的な仕事はスケジュール管理ではないのです。
コミュニケーションとコーディネーション (上記のすべてを包含する)。
PM は、チームの状況、進捗、障害、機能的な順序を整理し、組織全体に伝える必要があります。これには、リーダーシップチームとの毎週のチームステータスミーティングや製品レビューの推進 (またはエンジニアリングとの共同推進) や、ローンチやその他のタイムラインの組織全体への伝達が含まれます。
多くの場合、コミュニケーションで最も難しいのは、製品ロードマップ、優先順位付け、順序付けの背後にある「なぜ」を伝えることです。その一環として、あるものが他のものよりも優先される理由を確立するフレームワークを作成し、他のすべての部署がこのフレームワークを理解することが重要です。
最終的に、プロダクトマネジメントは、エンジニアリング、デザイン、セールスと密接に協力し、時には自然な (協力的な) 緊張関係を持つことになります。エンジニアリングは、自分たちがすべてを作っているのだから、製品の決定権は自分たちにあるはずだと考えるでしょう。設計は、製品管理は設計とは全く異なる機能であるのだから不必要だと考え、営業は、なぜ製品管理はより速く出荷できないのか、なぜ PM は常に営業担当者をエンジニアから遠ざけようとしているのかと考えるでしょう (それは、エンジニアが営業からの単発的な要求に時間を費やすことなく、製品づくりに集中できるようにするためです)。
PM はまた、エンジニアやデザイナーを社内外の関係者から守る「緩衝材」や「盾」としても機能すべきです。営業やマーケティング担当者は、常にエンジニアに直接会って、自分たちの好きな機能について働きかけたいと思うでしょうし、顧客はエンジニアリングと直接話をしたいと思うでしょう。プロダクトマネジメントは、このようなやりとりのための賢い緩衝材となり、すべての意見や質問を週 1 回の社内チームミーティングに集約すべきです。または、PM が営業チームにとってメインの問い合わせ先となるべきです。こうすることで、営業やマーケティング、その他の組織がエンジニアリングや設計の時間を使いすぎるのを防ぐことができます。とはいえ、顧客のニーズをエンジニアに納得させる最善の方法は、エンジニアを顧客の前に立たせることです。顧客の声を直接聞くことで、考えが変わったり、素晴らしいブレーンストーミングや問題解決のセッションが形成されたりすることがよくあります。
適切な人材はいますか?
良い PM と悪い PM は、上記の各項目にどれだけの時間を費やしているかで見分けることができます。もし、PM の時間がチェックリストやプロジェクト管理だけに費やされているのであれば、その PM はカバーするエンジニアリングマネジメントの相手が弱いか、会社の経営陣から自分の仕事をする権限を与えられていないか、自分の仕事を理解していないか、同僚から尊敬されておらず、より重要な仕事をすることができないのです。理想的には、プロダクトマネジメントのほとんどの時間は、製品の定義、トレードオフの優先順位付け、顧客との時間、ローンチ、機能の反復、コミュニケーションでのさまざまな部門との連携に費やされるべきです。最も難しいのは、適切な人材が適切な役割に就いているかどうか、あるいはあなたの会社がその人材に適切な権限を与えているかどうかを見極めることかもしれません。
優れたプロダクトマネージャーの特徴
プロダクトマネージャーを採用する際には、以下のようなスキルを持つ人材を選ぶ必要があります:
製品センス: 製品センスとは、ある分野の製品に対する顧客のニーズを理解する洞察力と直感を持つことです。どのような製品の機能が顧客を驚かせるのか、あるいは顧客の中核的なニーズを満たすのか。その PM が他業界から転職してきた場合、顧客の具体的なニーズを知らないかもしれません。しかし、顧客とそのニーズを素早く知るためのスキルセットとツールキットは持っているはずです。
優先順位をつける能力: 提案された製品機能の、それを達成するために必要なエンジニアリング作業に対する価値は何か? 営業チームのための新製品か、顧客のための機能か、どちらが重要か? 価格設定は消費者向けに最適化すべきか、中小企業経営者向けに最適化すべきか? すぐにでも発売すべき 80% の製品とは何か、また、その製品が解決できる顧客の問題とは？
遂行力: プロダクトマネジメントの大部分は、チームやさまざまなリソースを説得し、丸めこんで製品を立ち上げ、その後製品を維持し、顧客ベースをサポートすることです。プロダクトマネージャーは、製品のロードマップを遂行するために、エンジニアリング、デザイン、法務、カスタマーサポート、その他の部門と提携します。
戦略的感性: 業界の状況はどのように進化しているのか? その製品をどのように位置づければ、競合に打ち勝つことができるか? 1970 年代の Intel の有名な価格戦略は、大胆な戦略的行動の良い例です。当時、Intel は、販売台数を拡大すればするほど、自社のコストが大幅に削減されることを理解していました。販売台数を減少させれば、需要と数量が増加し、好循環が起こります。Intel は賢く、市場シェアをより早く拡大するために、原価を下回るコストで新しいシリコン製品を発売することにしました。その結果、同社の顧客は 2 年先まで予測していなかった数量を購入し、同社のコスト構造が大幅に低下したため、収益性が向上したのです。言い換えれば、彼らの低価格設定は、予測を何年も先取りした大量生産によって、自己実現的で持続可能なものとなったのです。
卓越したコミュニケーション能力: PM の仕事の多くは、トレードオフを理解し、それを多様な同僚や外部の関係者に伝えることに集約されます。
メトリクスを特定する能力とデータ駆動型アプローチ: 測定したものを構築します。プロダクトマネージャーの役割の 1 つは、エンジニアリングやデータサイエンスチームと協力して、プロダクトチームが追跡すべき一連の指標を定義することです。正しい指標を設定するのは難しいものです。そして正しい指標があっても、間違った行動を生むこともあります。
プロダクトマネージャーの 4 つのタイプ
採用するプロダクトマネージャーは、あなたの会社が取り組んでいる製品の種類によって異なります。多くの場合、企業は以下のミックスを必要とします。複数のタイプの PM として機能できる人もいれば、以下のうちの1つだけをうまくこなせる人もいます。
1. ビジネスプロダクトマネージャー
このようなプロダクトマネージャーは、社外の顧客からの要望を社内の製品ロードマップに統合することに長けています。ビジネス PM は、エンタープライズソフトウェア企業や、コンシューマー向けアプリケーションのパートナー向け部分を担当する企業で活躍する傾向があります。営業とうまく連携し、顧客にうまくプレゼンできる一方、エンジニアリングや設計と協力して、製品ロードマップと必要なエンジニアリングの労力をトレードオフできるほどの技術力も持ち合わせています。また、製品の価格設定、顧客セグメンテーション、顧客ニーズに対する鋭い洞察力を持っています。
2. テクニカルプロダクトマネージャー
テクニカルプロダクトマネージャーは、インフラ、検索品質、機械学習、または他の内向きの仕事のような分野でエンジニアリングと一緒に働くことができるレベルの高い技術者であることがよくあります (必ずしもそうとは限りませんが)。テクニカル PM は、必要なビジネススキルを習得し、製品において適切なトレードオフを行うための優れたユーザー直感を持っている限り、エンタープライズからコンシューマーまで幅広い製品に携わることができます。
3. デザインプロダクトマネージャー
消費者向けアプリケーションに携わるのが一般的で、デザイン中心型のプロダクトマネージャーはユーザー体験に重点を置いています。企業によっては、コンシューマー向け製品のためにデザイナーをプロダクトマネージャーに転換させることもあります。デザイナーは、ユーザー体験やビジュアルデザインにおいて非常に才能があることが多いのですが、ビジネスを運営するために必要なトレードオフ (広告モデルや価格設定など) を行う訓練を受けていない場合があります。一般的に、プロダクトマネージャーになったデザイナーは、製品の美しさとマーケティングの間の現実的なトレードオフにもっと焦点を当てるように再教育するのが良いでしょう。デザイン PM は、社内のエンジニアリングチームやデザインチームと過ごす時間が最も長く、社外向けのタスクやビジネス中心のタスクに費やす時間は短くなりがちです。
4. グロースプロダクトマネージャー
グロースプロダクトマネージャーは、定量的、分析的、数字に強い傾向があり、良いケースでは、創造的でアグレッシブです。グロース PM の焦点は、製品の採用と利用を促進するために必要な重要なレバーを決定し、次にそれらのレバーを操作することです。例えば、Facebook のグロースチームは、メールループ、ファネルの最適化、サインアップ、コンバージョン、その他のフローの大規模な多変量テストを通じて、数千万人のユーザーを増やしました。グロース PM は、エンジニアリング、マーケティング、ユーザー体験、そして場合によってはパートナーシップや取引チームと密接に仕事をする傾向があります。グロースマーケティングがグロースプロダクトマネジメントの役割を果たすこともあり、この役割はマーケティングに報告されます。
一般的に、技術的でバックエンドが重い製品であればあるほど、プロダクトマネージャーの数は少なくなります。データベース企業は、コンシューマー・インターネット企業よりもプロダクトマネージャーとエンジニアの比率が低いでしょう。私が Google にいたとき、検索インフラチームにはプロダクトマネージャーはほとんどいませんでしたが、より UI 中心でビジネス中心のモバイルチームには、その小規模なエンジニアリング組織にも関わらず、たくさんのプロダクトマネージャーがいました。
プロダクトマネージャーではないプロジェクトマネージャー
プロジェクトマネージャーをプロダクトマネージャーとして採用しないでください。プロジェクトマネージャーは、スケジュールを整理し、推進することには長けているかもしれませんが、機能の優先順位をつけたり、より大きな戦略的な質問をしたりする能力に欠けていることがよくあります。一般的に、高機能なソフトウェア組織ではプロジェクトマネージャーは必要なく、エンジニアリングマネージャーとプロダクトマネージャーが混在してプロジェクトマネジメントを担当します。プロジェクトマネージャーは、ハードウェア製品、外部パートナーの実装、またはベンダー固有のハードウェアの統合のために有用になるかもしれません。
アソシエイト・プロダクトマネージャー (APM) およびローテーション・プロダクトマネージャー (RPM)
Google と Facebook は、学部を卒業してすぐに入社する若手のプロダクトマネジャー向けに、大規模なプログラムを開発しました。Google のプログラムは 12 ヶ月のローテーションを 2 回、Facebook のプログラムは 6 ヶ月のローテーションを 3 回行います。各ローテーションで、APM または RPM は異なる製品組織 (広告、消費者製品、タイムライン、検索など) で働きます。APM と RPM のプログラムは、各企業の将来のプロダクトリーダーを社内で育てることを目的としています。会社の規模が 1,000 人以上になれば、APM のようなプログラムを検討する価値があるかもしれません。ただし、社内のシニアプロダクトマネジメントの組織が固まるまでは、実施しないでください。
プロダクトマネージャーとの面接
プロダクトマネージャーを面接する際には、採用する役割 (前項「プロダクトマネージャーの 4 つのタイプ」参照) だけでなく、すべてのプロダクトマネージャーに求められる一般的な能力 (「優れたプロダクトマネージャーの特徴」参照) やすべての採用者 (カルチャーフィットなど) を念頭に置くことが重要です。
面接でプロダクトマネジャーに聞くべき主な分野は次のとおりです。
製品についての洞察: 毎日使っている製品は何ですか? あなたなら X 製品をどのように変えますか? 特定のユーザーのためにX製品をどのようにデザインしますか? どのような機能を追加しますか? どの機能を排除または停止しますか? もしゼロから会社を立ち上げるとしたら、どの製品から始めますか? 例えば、子ども向けの携帯電話をどのようにデザインしますか?
過去に成功した製品への貢献: Google で働いていたとき、私はこれまで出会った中で最も強力な製品担当者たちと一緒に仕事をしました。また、たまたま適切な時に適切な場所にいた、ひどいプロダクトマネージャーたちとも一緒に仕事をしました。成功した製品のプロダクトマネージャーにインタビューするときは、彼らの具体的な貢献を掘り下げることが重要です。例えば製品の定義と立ち上げでどのような役割を果たしたのか? 誰がどの製品の機能を考え出したのか? 誰がその製品のアイデアを価格をつけるまで推進したのか?
優先順位付け: 優先順位付けに関する質問は、トレードオフそのものではなく、候補者がトレードオフを行うために使用するフレームワークに焦点を当てます。シナリオやケーススタディを提示することで、これらの質問を始めることができます。例えばあなたの会社には投資すべき製品パスの候補が複数ありますが、そのすべてに投資することはできません。このような場合のリアルワールドでの例を聞きます。その PM はこの意思決定の選択にどのようにアプローチするのか? どのような要素を考慮するか? どのようなデータを使うことができるか? エグゼクティブチームが要求した製品機能で、あなたが押し戻した、あるいは排除した例はあるか?
コミュニケーションとチームの対立: 前の会社のリーダーシップ・チームにビジョンや製品を売り込むことができたか? エンジニアリングや設計とどのような意見の相違や対立があったか? これらの意見の相違はどのように解決されたか? その PM は組織の他の部署とどのように積極的に関係を築くのか? どのようなコミュニケーション・アプローチを使っているか? いつ、何を伝えることが重要か? コミュニケーションのミスによって製品に問題が生じた例は? その問題をどう解決したか、また、その後プロセスの観点から何が変わったか? 一般的に、製品、デザイン、エンジニアリングの間には自然な緊張関係があります。ペースの速い環境では、対立が自然に生じることもあります。重要なのは、意見の相違を克服するためにいかに人間関係を構築するか、また、対立が生じた場合にいかに解決するかです。
指標とデータ: その PM は前回の製品でどのような指標を追跡したか? これらの指標はどのように選ばれたのか? その指標が発生させ得る好ましくない行動は何か、また、そのような行動をどのように避けるか? あなたの会社の製品については、どのような指標を追跡するか? なぜその指標が正しいのか? 指標はどのくらいの頻度で、どのような場面でレビューされるべきか? 製品ローンチが成功したかどうかをどのように評価するか?
すべての採用 PM のリファレンスチェックを
すべての採用者にとって、リファレンスチェックは非常に重要です。プロダクトマネージャーの場合はさらに重要です。エンジニア候補者の場合、面接で技術的な能力があるかどうかを明らかにすることができます。プロダクトマネージャーの場合、簡単にテストできる能力指標はありません。その代わり、過去の仕事が、その人が将来も成功するかどうかを見分ける最強の指標となります。適切に実行された非公式なバックチャンネルは、特に有意義である可能性があります。
最高のプロダクトマネージャーは、ともすると行き詰まっていたであろう製品や機能を立ち上げてきました。彼らは、製品の成功に貢献するトレードオフを行うためにエンジニアリングやデザインとうまく交渉し、ビジネスを成功に導く大きな戦略的視点を作り出します。