プロダクトリーダーが失敗する理由

CPOやプロダクト責任者の仲間で、「ああ、私は今、絶好調です」と言う人にまだ会ったことがありません。プロダクトリーダー仲間との会話では、プロダクトリーダーの役割にまつわるミームが生まれ始めているほどです。それは、

「どうしてもクビになる前に、ポイントを稼ごうとするんだな」

では、典型的なCPOが自分の役割を、数年、つまりビジネスを少しでも助けるのに十分な期間生き残ろうとすることだと感じているとしたら、何がその原因なのでしょうか。なぜ、プロダクトリーダーとして耐えることがそんなに難しいのでしょうか?


▼ 本記事の内容
  1. 失敗モード 1:誰がプロダクトビジョンを持っているか?
  2. 失敗モード 2:専門知識と必要とされるプロダクト開発のタイプは一致しているか?
  3. 失敗モード 3:ニーズの変化に合わせてプロダクトリーダーを適応させることができるか?

この記事は、『Why Product Leaders Fail』を著者の了解を得た上で翻訳したものです。
著者: Casey Winters
翻訳者: 渡辺圭祐


私は、会社がどの程度の段階にあるかによって、3つの一般的な失敗モードがあると思います。会社のステージが早ければ早いほど、創業者・CEOとのズレが答えになることが多いようです。プロダクトリーダーがプロダクトリーダーの役割を引き受ける際に誰も言わない事は、十中八九、創業者やCEOはまだプロダクトのビジョンを推進したいと考えているということです。そして、そのビジョンの実行を支援することを望んでいます。そして、創業者が規模を拡大するにつれて、創業者の直感は、社内のプロダクトに関する専門知識と比較して、その有効性が薄れていきますが、創業者がそれを受け入れるには、長い時間がかかります。この移行期は、非常に不安定なものです。

レイターステージ企業の場合、CPOが得意とするのはある種のプロダクト業務だけであり、ビジネスに必要なプロダクト業務の種類は時間とともに変化していく、というのがより妥当な答えでしょう。これは、2つの形で現れます。プロダクトリーダーは、現在必要とされている仕事のタイプにマッチしないスキルを持っているか、あるいは、実行するにつれて必要とされるスキルが変化し、リーダーが適応できないか、です。プロダクトリーダーは、その新しい仕事に向いていないだけでなく、その仕事に興味を持つ可能性も低くなります。

それでは、これらの失敗モードについて、そして、その失敗をより少なくするためにプロダクトリーダーとCEOの双方ができることについてお話しましょう。

失敗モード 1:誰がプロダクトビジョンを持っているか?

創業者は、顧客やプロダクトについて非常に優れた直感を持っている傾向があります。なぜなら、率直に言って、誰も顧客とその問題について考えるのにそれほど多くの時間を費やしてこなかったからです。スタートアップがプロダクトリーダーを採用する場合、この種のリーダーを採用するのは初めてのことです。面接のプロセスは不器用で、最適化されておらず、創業者はまだ本当のニーズを明確にする方法を見つけ出せていません。一般的に、このプロセスで起こることは、創業者とプロダクトリーダー候補の両方が、将来のプロダクトビジョンについて意見を交わすことです。しかし、創業者にとっては、プロダクトリーダー候補が創業者をどれだけ助けてくれるのか、効果的なテストにはなりませんし、プロダクトリーダーにとっては、自分がプロダクトビジョンに大きな発言力を持つという誤った印象を与えかねません。

可能な限り、創業者は外部の専門家を活用して、この種の役割のリクルートと面接のプロセスを構成する必要があります。プロセスを開始する前に明確にしておくべき重要な質問の1つは、このリーダーがプロダクトビジョンの設定においてどのような役割を果たすのか、ということです。プロダクト/エンジニアリング/デザインを専門としない創業者であれば、ビジョンを定義するよう求められるかもしれません。プロダクト、技術、デザインのバックグラウンドを持つ創業者の場合、会社が大きくなるまでは、通常、そのようなことはありません。プロダクトエグゼクティブは、通常、創業者主導のビジョンにおいて、コンサルティングや実行の役割を担います。創業者は、候補者にそれがどちらであるかを伝える必要がありますし、候補者はそれを尋ねる必要があります。この2つは、どちらもあまり行われません。

創業者は、この質問に対する答えを理解したら、適切なスキルがあるかどうかを吟味する必要があります。本当に必要なのはビジョンを実行することであるなら、面接の多くをビジョンに費やすべきではありません。もちろん、候補者はビジョンを理解する必要がありますが、あなたが本当に学ぶべきは、あなたからビジョンを受け取り、それを無数の困難な方法で実現することに抵抗がないかということです。

失敗モード 2:専門知識と必要とされるプロダクト開発のタイプは一致しているか?

企業によって、長期的な成功を収めるために必要なプロダクト戦略へのアプローチは大きく異なります。私たちの多くは、プロダクト開発には様々な種類があることを理解しています。技術やプロセスの拡張、新しいプロダクト・マーケット・フィットを見つけるための新プロダクト開発、現在のプロダクト・マーケット・フィットを強化するための新機能の開発とユーザー体験の反復、そして、既存のプロダクト・マーケット・フィットを最大数のユーザーに体験してもらうためのグロースワークなどがあるのです。伝統的にプロダクトリーダーは、どちらかの専門家になることに傾いています。例えば、私は間違いなくグロースの専門家として最も知られています。

創業者は、プロダクトリーダーを採用しようとする際に、自分たちが実際に直面しているプロダクトの課題がどのようなものなのかを理解していないことが多いのです。ネットワークビジネスでは、新しい機能よりも、より多くのユーザーを獲得することがプロダクトをより強固にするため、グロースに重点を置く傾向があります。DTCのeコマース企業やブランドは、常に新プロダクトを発表しています。SaaSビジネスでは、時間をかけて多くの新機能を立ち上げる必要がある傾向があります。常に新しい機能を作りたがるプロダクト・リーダーをネットワーク・エフェクト・ビジネスに採用しても、うまくいかない可能性が高いのです。

失敗モード 3:ニーズの変化に合わせてプロダクトリーダーを適応させることができるか?

創業者が適切なタイミングで適切なスキルを持つリーダーを採用したとしても、企業の規模が大きくなるにつれて、そのスキルの比重を変化させる必要があります。今日、プロダクトリーダーの仕事は、ビジネスが必要とするものになることです。つまり、旧来のプロダクトリーダーがスペシャリストであるのに対し、新時代のプロダクトリーダーは、スケーリング、新プロダクト開発、機能追加、グロースなど、ビジネスのニーズに合わせたポートフォリオのバランスを取り、ビジネスニーズの変化に応じて、時間の経過と共にそのバランスを大きく変えていくカメレオンである必要があるのです。これは難しいことですが、プロダクトリーダーが企業内で長期的に成功するためには、必然的にそうやって進化していかなければならないのです。

グロース志向のリーダーとして、私はEventbriteでより多くの時間をスケーリング、機能、新プロダクトの拡張作業に費やしています。

プロダクト・リーダーシップは、非常に難しいものです。創業者とプロダクト・リーダーの両方が、役割を採用する前に期待することを一致させ、組織が今どの問題に焦点を当てているかを一致させることで、その難しさをある程度解消することができます。そして、プロダクトのニーズの変化に合わせて進化していけるかどうかは、プロダクトリーダーにかかっています。ニーズがいつ変化するかを理解し、それに合わせて組織を変化させることができるのは、どちらもプロダクトリーダーなのです。

現在、レオン・ヴァインホールの「レア、フォーエバー」を聴いています。


フォローして最新情報をチェック!

広告

プロダクトマネージャーの意思決定の極意

プロダクトマネージャーは、プロダクトの優先順位の決定、プロダクトデザインの決定、バグのトリアージの決定など、毎日多くの決定を下さなければなりません。そして、プロダクトマネージャーがそのような決定を下すプロセスによって、チームのダイナミズムが非常によく機能することもあれば、全く逆の結果になることもあります。

うまく機能しているとき、チームは最高のアイデアが、それがどこから来たかに関係なく、実行に移されるように感じられます。自分たちの意見を聞いてもらえるという実感があるのです。そして、いつ、どのように意思決定がなされるのか、明確に理解することができるのです。そして、時には間違った判断がなされることがあっても、適切な時にはそれを覆すことができることを知っています。また、意思決定の結果に必ずしも同意しないかもしれませんが、チームが正しい判断を下すことができると信じています。そして、チームは目の前にあるどんな難題にも挑戦し、効果的に解決できると信じているのです。

一方、意思決定のプロセスがうまくいかないと、チームは多くの決断に疑問を持ち始めます。そのような場合、チームは、その決定がすべての関連情報を考慮することなく、急いでなされたのではないかと考えるようになります。チームは、そのような意思決定がどのように行われるのかを理解しているとは思えず、チームがカバ(最も高い給料をもらっている人の意見)の意思決定に悩まされているとさえ思うかもしれません。そして、最終的にチームの正しい判断力を信頼していないのです。

うまく機能しているチームとそうでないチームの違いで驚くのは、実際に行われている意思決定ではなく、そうした意思決定が行われるプロセスや文化です。正しい意思決定を行う文化を構築するために、私はプロダクトマネージャーに以下のベストプラクティスに従うことを推奨しています。

▼本記事の内容
  1. 優れたアイデアの創造者ではなく、キュレーターとしての役割を確立する
  2. 人の意見を聞き入れることができる
  3. 意思決定のプロセスを伝える
  4. 明日の決断より今日の決断を優先する
  5. 決断を見直すプロセスを明確にする

この記事は、「The Art of Decision Making as a Product Manager」を著者の了解を得た上で翻訳したものです。

著者: Sachin Rekhi
翻訳者: 渡辺圭祐

優れたアイデアの創造者ではなく、キュレーターとしての役割を確立する

優れたプロダクトは優れたチームによって作られます。そのため、最高のアイデアはチームの誰からでも生まれる可能性があります。このことをチームが理解し、真摯に受け止めることが重要です。あなたの役割は、最高のアイデアをキュレーションして、それがトップに上がるようにすることだと信じれば、チームはそのプロセスに熱心に参加するようになります。

人の意見を聞き入れることができる

自分の役割を確立したら、最も重要なことは、人々の意見を聞くことを保証することです。つまり、チームからの意見を聞きやすい環境を整え、時間をかけてじっくりと検討することです。自分が納得できないアイデアをすぐに否定しないよう、注意してください。その代わり、相手の立場を理解し、自分の言葉で相手の提案を言い換えることで、相手が理解したことを実感できるようにしましょう。

意思決定のプロセスを伝える

重要な決断を下している最中には、意思決定のプロセスをチームに理解させることが重要です。まだ提案の候補を集めている段階であれば、そのことを明確にし、チームからアイデアを募りましょう。追加情報を待って決断する場合は、そのこともチームに伝え、決断に時間がかかる理由を知ってもらうことが大切です。そして、最終的に決断したら、その決断とその理由をチームに明確に伝え、次のチャレンジに進むようにしましょう。

明日の決断より今日の決断を優先する

意思決定の敵は「時間」です。今日の決断は今日中にプロダクトを前進させることができますが、将来の決断は単に学習を遅らせ、なぜこんなに時間がかかっているのかと疑問を抱かせ、実行速度を低下させるだけです。ですから、決断は後回しにせず、今日することが重要です。決断する前に待つべき明確な追加情報がない限り、常に今すぐ決断することを優先してください。

決断を見直すプロセスを明確にする

判断を誤り、再検討しなければならない状況に陥ることは避けられないでしょう。このような場合、自分自身に許容することが重要ですが、同時にそのための明確なプロセスを確立しておくことが大切です。私は、「以前に下した決断を見直す原因となる、新たな情報は何か」と常に問いかけるようにしています。これは、意思決定が常に見直され、翻弄されることがなく、かつ適切なときに軌道修正するメカニズムがあることを保証するための素晴らしい基準です。

これら5つのベストプラクティスを実践すれば、チーム内で正しい意思決定文化を確立し、チームダイナミクスが極めてよく機能するようになるはずです。

関連エッセイ

私は、15年以上にわたるプロダクトの経験を凝縮し、PMがその技術を習得するのを助けるために作られた新しいコースをついに発表しました。22年夏に開催される「プロダクトマネジメントを習得する」コースにご参加ください。


フォローして最新情報をチェック!

データではなく、インサイトを提供する

データ戦略の重要性を苦労して知った方法

IoTプロダクトは、大量のデータを生成することで知られています。IoTプロダクトを導入する理由は、このデータを生成・収集するためであり、データそのものが価値を提供するものだと主張する人さえいます。私はそうは思いません。IoTプロダクトはインサイトを提供する必要があるのです。

この記事では、データ戦略を持つことの重要性を説明し、私がどのようにこのことを苦労して発見したかを共有します。

▼本記事の内容
  1. あなたのデータ戦略とは?
  2. データは多ければ多いほど良いのか?
  3. 常にデータ戦略でリードする
  4. 業界知識の重要性
  5. 結論 インサイトを提供する

この記事は、「Provide Insights, Not Data」を著者の了承を得た上で翻訳したものです。

著者: Daniel Elizalde
翻訳者: 渡辺圭祐

あなたのデータ戦略とは?

結局のところ、IoTプロダクトも、顧客から見れば他のプロダクトと変わりません。価値を提供するかしないかです。そのプロダクトが果たすべき仕事を解決するか、しないかです。

なぜ、このような話をするのでしょうか。なぜなら、企業がIoTプロダクトを構築する際に直面する最大の課題の1つは、データ戦略、つまりデータからどのように価値を引き出すかについての計画を持つことだからです。

データ戦略とは、データの収集と管理にとどまりません。プロダクトで達成したい最終目標を定義することから始まり、IoTテクノロジースタックを用いて、スタックの各レイヤーで収集、保存、分析、転送する必要があるデータを理解することができます。これは、IoT意思決定フレームワークのData Decision Areaを通過する際の重要な目的の1つです。

データは多ければ多いほど良いのか?

そうではありません。明確なデータ戦略を持つことの重要性について、あるエピソードを紹介しましょう。

私はキャリアの初期に、ある半導体製造会社向けにターンキーIoTソリューションを開発しました。顧客は(仮)ケビンといい、新しいハードウェア・チップの特性評価プロセスを自動化するために、私の勤める会社に依頼しました。キャラクタライズとは、コンピュータ・チップに想像しうるあらゆる入力を与え、その出力を記録して、エンジニアがチップを設計する際に使用した数学モデルにできるだけ近い性能を確保することを意味します。

手作業であらゆる入力の組み合わせを設定するのは不可能な作業です。しかし、もしコンピュータに入力を代行させ、すべての出力データをクラウドに保存することができれば、多くの時間を節約し、プロダクト全体の品質を向上させることができるはずです。そこで、私たちが登場したのです。

ソリューションのインストールとプロビジョニングが完了すると、ケビンと彼のチームは非常に興奮しました。プロジェクトは大成功でした。

数ヵ月後、ケビンから助けを求める電話がかかってきました。「データがあふれかえっていて、どうしたらいいか分からない」。私たちが開発したシステムには、高速のセンサーやアクチュエーターがたくさんあり、1秒間に何ギガバイトものデータを生成していたのです。そう、1秒間に。

ほんの数分システムを動かすだけで、膨大なデータが作成され、その新しい情報を理解するのに数週間を要します。可視化の問題は解決されましたが、その一方で、大量のデータを管理、分析、処理することができないという、別の(おそらくより大きな)問題を生み出してしまったのです。

常にデータ戦略でリードする

後悔先に立たずとはよく言ったものです。今日、私は、このカスタムソリューションで顧客が要求するものを提供するだけでなく、顧客の最終的な目標を理解するためにもっと良い仕事をするべきだったということがよくわかります。

誤解しないでいただきたいのですが、私の会社から見れば、この展開は成功でした。時間通りに予算内で納品し、お客様はピカピカの新システムに喜んでサインしてくれました。しかし、実際には、私たちは問題を悪化させてしまったのです。

この話は1回限りではありません。実際、私は世界中のプロダクト担当者と話をする中で、このようなことが何度も起こっているのを目の当たりにしています。企業は、お客様が本当に成し遂げようとしていることを深く掘り下げるのではなく、問題の症状に対処することに重点を置きすぎているのです。また、インサイト(洞察)ではなく、単なるデータを提供することに重きを置いている場合も少なくありません。

幸運なことに、ケビンは私の会社を信頼してくれて、データが多すぎるという問題を解決するために、プロジェクトの第2段階を手伝ってくれることになったのです。今回は、彼のチームだけでなく、会社全体のニーズを深く掘り下げることに気をつけました。

すると、彼らはデータ操作の専門知識を持たず、データアナリストもおらず、私たちが開発したシステムを引き継ぐのに必要な知識もないことがすぐにわかりました。

私はその後数カ月間、彼らと共にデータ戦略とデータ管理ソリューションを導入し、これらの懸念に対処しました。データ量を減らし、すべてのデータ(他部門からのデータも含む)をプライベートクラウドに一元化し、分析・可視化レイヤーを追加しました。その後、物事はずっとよく見えるようになりました。

この教訓は決して忘れないでしょう。

機械や “モノ “は、膨大な量のデータを生成することができます。疲れることはないので、昼も夜もデータを出し続けることができます。ノンストップです。明確なデータ戦略と、そのデータを使って価値を提供するための明確な道筋がなければ、IoTソリューションは役に立ちません。ノイズを増やすだけです。

業界知識の重要性

古いジョークにこんなものがあります。羊飼いが羊の世話をしていると、突然スポーツカーに乗った青年が立ち寄った。羊飼いが羊の世話をしていると、突然スポーツカーに乗った青年が通りかかり、「羊の数を当てたら、1匹飼ってもいいですか?羊飼いは同意する。羊飼いはそれを受け入れ、青年は最新鋭の計算機で計算を始める。「羊の数は280匹です」。

羊飼いはため息をつきながら、「あなたの職業を当てたら、羊を返してもらってもいいですか」と青年に言った。羊飼いはため息をつきながら、青年に言った。羊飼いは、「あなたはコンサルタントですね」と言う。青年は驚いて、「どうしてわかったんですか!」と聞く。「まあ、あなたは私に高額な料金を請求しているし、私がすでに知っていることを話している。そして、私の犬を取り上げているのだから、明らかにあなたは私のビジネスについて何も知らないのだ」と。

この話は、プロダクトマネージャーにも当てはまる。そのため、解決する必要のない問題を解決してしまったり、多くのデータを出すだけで価値のないものを作ってしまったりすることがよくあるのです。

今思えば、ケビンのシステム構築の際も、業界知識のなさが問題を引き起こしました。私(と私の会社)にとっては、新しい業界でした。私たちは、他の業界向けに高性能なIoTソリューションを構築する方法を知っており、ソリューション空間は非常によく翻訳されましたが、問題空間は全く異なっていました。

私たちは、お客様について、またお客様の抱える問題について、十分な時間をかけて学んできましたが、その業界の課題に対する参照枠を持っていなかったのです。その結果、部分的には価値のあるプロダクトでしたが、問題を完全に解決することはできませんでした。

では、この羊飼いとコンサルタントの物語から得られる教訓は何でしょうか。

顧客の業界を知ること。プロダクトマネジャーは、顧客のビジネスについてできる限り理解する必要があります。言い換えれば、深い業界の知識を持つ必要があるのです。

顧客とその業界の同業者が直面する課題の専門家になれば、プロダクトについてより良い質問と判断ができるようになり、ひいては顧客により多くの価値を提供することができるようになるのです。

結論 インサイトを提供する

今日の多くのIoTプロダクトは、インサイトではなく、データを生成することに重点を置いています。その結果、ソリューションの価値を活かせず、データから有用な情報を抽出するために余分な作業を強いられ、失望するお客様が続出しています。

プロダクトマネージャーは、ターゲットとする業界の最も一般的な課題を理解するなど、お客様の世界を理解する責任があります。そうして初めて、顧客のニーズを解決するための確固たるデータ戦略を構築することができるのです。

原文はiotforall.comに掲載されています。


フォローして最新情報をチェック!

MVPM: 有用なプロダクトマネージャーになるためにフォーカスしてはならないこと

この図をご覧になったことがある方もいらっしゃるでしょう。プロダクトマネジメントが多様なスキルセットの交差点であることをエレガントに示しています。

Originally from http://www.mindtheproduct.com/2011/10/what-exactly-is-a-product-manager/

そのシンプルさゆえに、この言葉はプロダクトマネジメントのミームとして最も成功を収め、プロダクトマネジメントという学問にとって良い影響を与えてきました。

昔、若いPMの卵であった私は、この言葉によって、学習の幅を広げるために構成する必要があることに気づきました。しかし、どこに焦点を当てるべきかということについては、教えてくれませんでした。私はすべてを学ぼうとし始めましたが、今にして思えばそれは間違いでした。

この3つの円についてすべてを学ぶには、この地球上に十分な時間はありませんので、この図が役に立つとしても、結局は非現実的なものになってしまいます。

そうですね…あまり参考にならないですね

それよりも、その交点を構成するものが何であるかを知る方がずっと役に立ちます。

この交差点は、私がMVPM(Minimum Viable Product Manager)と呼んでいるもので、効果的なジェネラリストプロダクトマネージャーになるために役立つ一連のスキルや知識を定義しており、ほとんどすべての問題に取り組むことができる人たちです。

MVPMは、決して、効果的になるためにそのスキルを習得する必要があることを意味するものではありません。それはこれから始める人にとって非現実的であり、逆効果です。その代わりに、この本は、存在しないプロダクトマネジメントのコースのシラバスのようなものと考えてください。

私は、若き日の自分、新米プロダクトマネージャー、そしてレベルアップを目指す経験豊富なPMのために、この本を書きました。図と対称になるように、スキルは分野ごとのセクションに分けられています。ここでは、注力すべき3つの重要なコンセプトとスキル、そして注力すべきではない1つのスキルを取り上げています。できるだけ平易な言葉で、どの分野にも冷静に取り組もうとする人向けに書いています。


▼本記事の内容
  1. テクノロジー
  2. ビジネス
  3. ユーザーエクスペリエンス

この記事は、MVPM: Minimum Viable Product Managerを、著者の了承を得た上で翻訳したものです。
著者: Brandon Chu
翻訳者: 渡辺圭祐

テクノロジー

1. スタック

エンジニアが「スタック」と呼ぶのは、プロダクトに機能を提供する(つまりプロダクトを動作させる)ために使用されるテクノロジーのレイヤーのことを指します。お客様がランディングページを開いた瞬間から、アカウントを削除するまでの間、スタック内のテクノロジーがすべてを処理します。

最速の学習方法 – エンジニアに頼んで、スタックを高レベルで説明してもらう。各技術の名前を書き留めておく。これらの用語を素早くググれば、選択した各技術の高レベルの利点とトレードオフ、およびそれらがどのように調和して動作するかを学ぶことができます。簡単にウサギの穴に落ちてしまうので、ハイレベルなものにとどめておきましょう(検索キーワードに「トレードオフ+メリット+対(trade offs + benefits + vs)」を追加してください)。

どうすればより良いPMになれるのか?– エンジニアが何かを構築する方法について議論しているとき、専門用語が部屋中に飛び交います。スタックを知っていれば、少なくともそれについていくことができますし、時間が経つにつれて、スタックのどの深さを指しているのか理解できるようになります。一般的に、スタックの中で触らなければならない層が多いほど、あるいは層が深いほど、変更はより複雑でリスクの高いものになります。これを知ることで、問題を解決するための別の方法を再度検討するようになるかもしれません。

2. システムアーキテクチャー

スタックがどのような技術を使用しているかを表すとすれば、システム・アーキテクチャは、それらの技術がどのように構成され、プロダクトを提供するために連携しているかを表します。スタックが主に生の技術的能力であるのに対し、プロダクトのアーキテクチャは顧客が意図する動作を設計に取り入れるものである。

最速の学習方法 – エンジニアにアーキテクチャを描くように頼む。このような答えが返ってくるでしょう。

「なぜトリプルストアというものは2つしかないのか?」

まず、慌てないことです。システムの各コンポーネント(ボックス)が何をするのか、説明してもらってください。あるものはインターネットのリクエストを処理し、あるものは「ビジネスロジック」を収容し、さらにあるものは保存されるデータを保持します(シリンダー)。

次に、信じられないかもしれませんが、これはあなたにとって非常に有益なことです。

アーキテクチャを理解すると、プロダクトをシステムのように考えるようになり、それは一般的にエンジニアも同じように考えるでしょう。システム内の各コンポーネントが全体にどのように寄与しているかを理解することで、より良い意思決定やトレードオフを行うことができるようになります。

一般的に、システムの中で最も接続の多い部品は、データや機能を依存しているものが多いため、変更が最も複雑になります。ビルドを完了するために変更しなければならないコンポーネントが多ければ多いほど、依存関係も増え、プロジェクトの実行は困難になります。

大企業では、扱うコンポーネントの数は、対話が必要なチームやグループの数と同義であることが多く、プロジェクトを実行するために必要な調整も多くなります。

3. データモデルとそのAPI

データモデルは、プロダクトが使用する情報を整理し、その情報の断片が互いにどのように関連しているかを標準化するものです。「情報」とは、ユーザープロダクトクレジットカードなどのことを指し、これらを総称して「エンティティ」と呼びます。これらのエンティティは、特定の構造化された方法で互いに関連付けることができます。例えば、ユーザーは多くのプロダクトを持つことができますが、クレジットカードは1つしか持つことができません。

データモデルは、特定のエンティティが特定のコンポーネントに「住んでいる」という点で、システムアーキテクチャと密接に関係しています。ユーザーモデルはコンポーネントAにあり、商品データもそうかもしれませんが、クレジットカードはその機密性から、コンポーネントBに置かれます。しかし、その中でどのユーザーがクレジットカードを保持しているかを知る必要がある場合、データを共有するためにコンポーネントAからコンポーネントBに接続する必要があります。それはより難しく、それを達成するためにAPI(アプリケーション・プログラミング・インターフェース)が必要になります。

APIはデータモデルの上に構築され、任意の2つのコンポーネントが互いに会話し、その基礎となるモデルに関する情報を交換する方法を表します。重要なのは、APIによって外部のコンポーネントと対話できるようになることです。GoogleマップからUberを呼び出すとき、GoogleマップアプリはUberのコンポーネントと会話しているのです。ほとんどのアプリケーションには、パブリックAPIとプライベートAPIがあり、それぞれインターネット上の誰でも使えるものと、指定した人だけが使えるものがあります。公開APIを知ることは、あなたのプロダクトが外部とどのように相互作用できるかを理解するために重要です。

最速の学習方法 – まず、パブリックAPIについて理解することに集中すべきです。これらは通常簡単に見つけることができ、多くの場合、あなたのウェブサイトの開発者向けドキュメントに掲載されています。それらを見たとき、コードを見ることになるので、あなたのバックグラウンドによっては、それが怖かったり、そうでなかったりするかもしれませんが、ドキュメントが中途半端であれば、それは関係なく、問題なく読むことができるはずです。APIを研究することの良さは、APIが基本的なデータモデルのほとんどを表していることが多いので、一石二鳥であることです。

どうすればより良いPMになれるのか?– データモデルを知ることは、より良いプロダクトを作るためにどのような情報を利用できるか、そしてその情報にアクセスすることがどれだけ難しいかを知る能力を拡大します。APIを知ることは、パートナーやサードパーティの開発者があなたのアプリケーションから取得できる情報の種類を理解し、どのような種類の統合が可能かを理解することを意味します。ソフトウェアの拡張性は、最も価値のある特性の1つであり、他のプロダクト(あなたの顧客が毎日使っている可能性のあるプロダクト)とうまく連携できることは、すぐにテーブルステークスとなりつつあるのです。

4. 注力すべきではない分野

プログラミング。誤解しないでください、私はプログラミングが好きですし、より良くするのに役立ちますが、高度に技術的なプロダクトでない限り、効果的なPMになるためにプログラミングは必要ありません。もしあなたがPMとしてコーディングをしていることに気づいたら、実際にレバレッジの高い仕事をしているのか、他に何をすべきなのか、自問自答する必要があるかもしれません。とはいえ、少なくとも1つのアプリを作り、本番環境に出荷した経験は、非常に価値があり、楽しいものだと思います。

ビジネス

1.プロジェクトマネジメント

退屈ですよね。私も嫌いですが、本当に大切なことです。プロジェクトをうまく運営できなければ、良いPMになることはできない。その通りです。

最速の学習方法 – これは難しい。効果的なプロジェクトマネージャーになるには、多くの経験と時間が必要です。本を読めばいくらでもわかるが、結局は人間の行動の問題なのです。一緒に仕事をすることになる様々な性格について学ぶには時間がかかりますし、どのようにアプローチするかについてのアドバイスも、その人の性格に左右されることが多いのです。

とはいえ、学習曲線を加速させるために投資できるソフトウェア特有のものがいくつかあります。

  1. プロダクト開発の基本を理解し、チームと共感できるようにする。バージョン管理(Git)、共同プログラミング(GitHub)、品質保証プロセス、そして、いつどのようにコードがユーザーにデプロイされるのかについて、高いレベルで学ぶことができます。
  2. ソフトウェアチームを悩ませる一般的な問題と、それを解決するために他の人々が開発したプロセスについて学ぶ。アジャイル、スクラム、カンバンといったものを目にすることがあるでしょう。自分の会社が使っているかどうかに関わらず、それらのアプローチの背後にある哲学を学ぶことには価値があります。
  3. 会社での意思決定を理解し、ステークホルダーをマッピングする。ステークホルダーとは、顧客、上司、チームメンバーの上司、他のPMのことです。プロジェクトがどのような状況、方向性で進んでいるのかを、ステークホルダーが気にするレベルで全員が把握できるような方法を見つける(これも自分で見つける必要があります)。

どうすればより良いPMになれるのか?– チームとより多くのことを成し遂げられるようになり、人々はあなたと一緒に働くことを楽しむようになる。なぜなら、誰もが管理の悪いプロジェクトを嫌うからです。

2. インパクトのモデル化

測定されないものがうまくいくことはほとんどありません。すべてのプロダクトは、ユーザーの成長、機能の採用、収益など、最終的な成功に結びつく定量的な目標を持っている必要があります。

あなたのチームが次に作ることができる最も高いレバレッジのものを議論しているとき、そのプロダクトがこれらの測定基準でどのようにダイヤルを動かすかのモデルを開発できることが重要です。

最速の学習方法-スプレッドシートを使うときが来たのです。良いモデルは、2つのことを明確に示しています。

プロダクトのユニットエコノミクスと、それを生み出す仮定

  • 新規顧客の獲得にいくらかかるか?
  • プロダクトの提供にはどれくらいの費用がかかるか?
  • コンバージョンは目標の針路をどれだけ変えるのか?

予測される影響とそれを生み出す前提条件

  • このプロダクトは今後1年間でどれだけの効果をもたらすか?次の3年間は?
  • このプロダクトを強化し、サポートするために何人の従業員が必要か?
  • コスト削減、インフレ、競争などの市場原理を長期的にどのように考慮するのか?
偽物のモデル成長率が大好きだ

どうすればより良いPMになれるのか?– プロダクトのモデルを構築することは、直感的な仮定をテストし、プロダクトが十分な可能性を持ち、それを実行する価値があることを確認するための素晴らしい方法です。また、ステークホルダーが納得する形でプロジェクトを正当化したり、他のプロジェクトとの機会損失を簡単に比較できるようになるため、仕事もやりやすくなります。

3. データ収集と分析

迅速な意思決定を行うためには、独自にデータを収集することが不可欠です。なぜなら、分析に携わったことのある人なら誰でも、インサイトはデータの反復的な探索によって得られるものであり、自分で考えた完璧なレポートではないことを知っているからです。

また、重要な時にデータに基づいた意思決定を行う能力も低下させます。ほぼ毎日、あるシナリオでプロダクトがどのように振る舞うべきかという決定が飛び込んできますが、決定をサポートするデータがあれば、あなたとあなたのチームは正しい方向に向かっていると自信を持つことが簡単にできます。

最速の学習方法 – 目標はデータの独立性。SQLクエリーを書く必要があるか、ドラッグ&ドロップのインターフェースを使うかは、会社のデータインフラに依存します。それが何であれ、利用可能なツールを学ぶために投資する必要があります。ググってみてください。

どうすればより良いPMになれるのか?– データに簡単にアクセスでき、それを快適に利用できれば、より多くのデータを利用でき、より反復的な作業ができるようになります。次に何を作るかを検討しているときでも、発売したプロダクトがどうなっているかを見ているときでも、データを重要なインプットとして意思決定に利用する反射神経が身につき、その結果、より良いプロダクトが生まれるのです。

4. 注力すべきでない分野

経営学部の出身者から言わせてもらうと、戦略的なビジネスケースや3年計画など、MBAの成果物を作って時間を浪費しないでほしいのです。私はそれをデタラメとまでは言いませんが、ソフトウェアで成功するための方法ではありません。ビジョンを理解し、それを達成するために解決すべき問題を見つけ、それを解決するための仮説を立て、実際の顧客とできるだけ早くそれを検証する。同じことを繰り返す。

ユーザーエクスペリエンス

1. プロダクトのデザインパターンを知る

ほとんどのプロダクトは、計画的かどうかにかかわらず、時間の経過とともにデザインパターンを発達させます。パターンとは、プロダクトの中で同じビジュアルやインタラクティブなコンポーネントを一貫して使用することです。ボタンのテキストはすべてフォントサイズ25px、フォームのフィールドは3つ以内、エラーが発生するたびに爆発音を鳴らし、ユーザーに詳細をメールで通知する、これらはすべてパターンです。

ランダムな例、thenextweb.comのマテリアルデザイン

プロダクトのパターンを知ることは、ユーザーがプロダクトをどのように頭の中でマッピングしているかを理解し、時間をかけて効果的に新機能を与えるには非常に重要です。いつもは「新しい機能を追加する」という緑色のボタンをユーザーに与えているのに、今回は「あなたの心を揺さぶる」というオレンジ色のボタンに切り替えたら、ユーザーは混乱するでしょう。

プロダクトが成長するにつれ、パターンの一貫した使用はさらに重要になります。なぜなら、パターンを使用することで、チームは互いに独立して作業しながらも、まとまりを感じるプロダクトを構築できるからです。

デザインパターンはまた、スタイルガイドやコンポーネントなどのテクニカルパターンと調和して開発されるのが一般的です。

最速の学習方法 – デザイナーは、これらのパターンを熟知しているはずですし、スタイルガイドへのリンクも教えてくれるはずです。また、フロントエンドエンジニアに相談すれば、パターンライブラリへのリンクを教えてくれるでしょう。

どうすればより良いPMになれるのか?– 簡単に言うと、パターンに基づいてプロダクトを設計することは、はるかに簡単で迅速です。パターンによって、あなたのチームが過去に行った設計上の決定、つまり、顧客にとって使いやすいプロダクトを実現するための決定の上に立つことができるのです。もし、既存のパターンを壊す必要があるのなら(もちろんそうする正当な理由もありますが)、プロダクトの長期的な健全性のためにそれが必要であるという正当な理由を用意しておいてください。

2. ユーザー・エクスペリエンス・リサーチの実行方法を知る

PMは顧客の声であることが前提です。ユーザーを理解しなければ、優れたプロダクトを作ることはできません。一人の人間に直接インタビューすることから、何百万ものユーザーの行動を定量的に分析することまで、優れたリサーチの基本を理解することは、あなたの仕事にとって不可欠なことなのです。

最速の学習方法 – 効果的なリサーチは非常に大きな分野なので、ウサギの穴に行かせるのではなく、次のことを理解することに集中することをお勧めします。

  • サンプルサイズと統計的有意差の計算方法を理解する。
  • サンプルを正規化する方法と、それがなぜ重要なのかを理解する。
  • 調査やインタビューにおいて、偏りのない、誘導的でない質問をする方法を理解する。
  • 結果を統合し、誤った結論を出さないようにする方法を理解する。

どうすればより良いPMになれるのか?– 一貫して頻繁にプロダクトを顧客にテストすることで、プロダクト開発における当て推量(およびリスク)の多くを取り除くことができます。プロジェクトが始まる前から、解決しようと考えている問題が本当にあるのかどうかを検証するために、テストを行うべきです。デザインと開発の段階では、プロダクトのデザインが使いやすく、顧客の問題を解決する可能性が高いかどうかをテストする必要があります。リリース後は、解決したかった顧客の問題が解決されたかどうかを検証する必要があります。

3. アイデアをプロトタイプ化する方法を知っておく

プロトタイピングとは、アイデアを効果的に表現するためのビジュアルモックアップを作成できることを意味します。プロトタイプは、以下のことを実現するのに十分なものでなければなりません。

プロダクトコンセプトを明確に伝える

プロダクトの体験を口頭や文章で伝えることは非常に困難です。プロトタイプは、人々が見ることができ、できれば対話できるもの(コードなしで可能)であれば、10倍以上の効果があります。

これには2つの理由があります。第一に、顧客が実際に操作するものという観点からプロダクトを明確にしなければならないこと、第二に、人間は本来視覚的に考えるものなので、プロトタイプは、チームの全員が同じ言葉で話し、それぞれの視点を効果的に伝えることができるように、競争の場を平準化するためです。

デザインの遅れや欠落がある場合、チームのブロックを解除する

多くのプロジェクトでは、プロダクトのデザインが開発に先行していることが重要です。デザイナーが「開発の先を行く」ことを心がけるのは、開発者が特定の方向性でプロダクトを作り始めると、その切り替えコストが格段に高くなるためです。

プロダクトデザインの多くは反復的で、開発と並行して行われるため、挫折(例えば、ユーザー調査によってデザインが効果的でないと判断された場合など)があると、デザインはすぐに遅れをとることになります。そんなときこそ、PMは腕まくりをしてリードデザイナーの「デザインインターン」となり、エンジニアが開発を続けられるよう、ピクセルのプッシュやモックアップの出荷をサポートしなければならないのです。

最速の学習方法 – これを正当化するために時間を費やすことはしませんが、Sketchを使い始めるといいでしょう。

どうすればより良いPMになれるのか?– プロトタイプを作成し、自分の考えていることを人に見せることで、相手が理解していると思い込むのではなく、自分のアイデアに対してチームからより良いフィードバックが得られるようになり、誤ったコミュニケーションによって無駄な労力を費やすリスクを減らすことができるのです。また、たまには実際に目に見えるものを作ってみるのもいいものです。

4. 注力すべきでない分野

優れたビジュアルデザイナーであることにこだわらないことです。洗練されたインターフェイスを作る能力は、プロダクトデザインという深い技術を学ぶためにキャリアを積んできた人にとっては、冗長で無力なものです。あなたがデザインに精通しているのであれば別ですが(もちろん、そういう人もいます)、おそらくあなたは自分が優れていると思っているだけで、実際は最低なのです。

MVPM

このようなことを学ぶことを矮小化したいわけではありません。簡単なことではありませんし、多くの時間がかかるので、少しずつ取り組んで、学ぶことを楽しんでください。この記事が、あなたが優れたプロダクトマネジャーになるための探求において、少しでも効率的であることを願っています。


他におすすめの記事はこちらです。

プロダクトマネジメントのブラックボックス

7 Heuristics for being a Product Director

The Time Value of Shipping


Brandon Chuの他の記事を読む👀

👉 Brandon Chu

フォローして最新情報をチェック!

プロダクトマネージャーのキャリアパス

プロダクトマネージャーの仕事もさることながら、そのキャリアパスもまた曖昧なものです。プロダクトマネージャーを目指すなら、どうすればいいのか?そして、プロダクトマネージャーという仕事のゴールは何なのか。世間では「プロダクトマネージャー」とだけ言われていますが、プロダクトマネージャーにもいろいろな種類があり、それぞれ専門的になることができます。今回は、プロダクトマネージャーのキャリアパスの全体像、専門性、ステップアップの方法、ヒエラルキーなどを紹介する記事をリストアップしてみました。

この記事や添付されているプロダクトマネジメントの記事をただ読んで終わりにするのではなく、共感したところをハイライトして、感想や学びをGlaspに残しておきましょう。そうすれば、いつでも見返すことができ、私たち皆が同時に学習することができます。
私のプロダクトマネジメントに関する記事のリーディングリストはこちらから参照ください。👉 Glasp – Product Management

準備ができたら、さっそく始めましょう。

▼本記事の内容
  1. プロダクトマネジャーのキャリアパス
  2. プロダクトマネジャーの専門性
  3. (アソシエイト) プロダクトマネージャーになるには
  4. プロダクトマネージャーからシニアプロダクトマネージャーへ
  5. シニアプロダクトマネージャーからプロダクトリーダーへ
  6. プロダクトマネージャー – 階層

この記事はProduct Manager’s Career Pathを翻訳したものです。
著者・翻訳者: 渡辺圭祐

プロダクトマネジャーのキャリアパス

プロダクトマネージャーのキャリアパスとは? (What is the Product Manager Career Path?)
https://www.productplan.com/learn/product-manager-career-path/
By: ProductPlan (@ProductPlan)

画像1
Source: What is the Product Manager Career Path?

アソシエイトプロダクトマネージャー
アソシエイト・プロダクトマネージャーは、プロダクトマネージャーが行うすべてのことを行いますが、その規模は小さいです。プロジェクトの優先順位を決める必要はありますが、プロダクト戦略やロードマップを定義する必要はありません。

この役割では、ユーザーへの共感を示し、問題発見と問題定義の能力をアピールする必要があります。また、他の人と協力し、あらゆる方面の話に耳を傾けることができることを示す必要があります。

仕事中は、関係するすべてのステークホルダーにプロダクトの状況を伝える必要があります。ビジネスの目標と顧客のニーズを調整し、利益とのバランスを保つ必要があります。

アソシエイト・プロダクト・マネージャーは、「これは我々がやっていることで、なぜそれをやっているのか」という質問に絶えず答えています。彼らは、成功を決定するための指標を頼りにしているのです。

採用担当者は、候補者がユーザーへの明確な興味と情熱を持っていることを望んでいます。CS、ビジネス、その他関連分野の学士号を取得している傾向があります。

💡 プロダクトマネージャーになるには?
「上記の活動を完全に把握する必要があります。あなたは、プロダクトセットに関する「頼りになる」人物としての地位を確立していることでしょう。さらに、エンジニアリング、UX、マーケティング、その他のチームと優れた協力関係を構築している必要があります。」

プロダクトマネージャー
プロダクトマネージャーは、他のチームメンバーにとって「頼りになる」存在です。戦術的な動きやプロセス、人間関係を聞かれることが多いでしょう。そして、あなたはデータによってよく知られているはずです。このポジションに就くには、ある程度の専門的な経験と、コラボレーション、優先順位付け、コミュニケーションなどのスキルが必要です。

💡 シニアプロダクトマネージャーになるには?
• 経営陣が自信を持って仕事ができるように、あなたのプロダクトによる顧客の利益を示し、目標達成に貢献できれば最高です。そして、具体的なユーザーの問題を定義し、それをプロダクトの指標やビジネスゴールと結びつけることができることです。そして、すべてが適切に運用され、スムーズに動く必要があります。
• キャリアを加速させるために忙しいからといって、反応的なタスク/質問ではなく、戦略的な意思決定に多くの時間を割けるようになると良いでしょう。

シニアプロダクトマネージャー
シニアプロダクトマネージャーの多くは、アソシエイトプロダクトマネージャーやプロダクトマネージャーと同じ職務を担当します。しかし、シニアプロダクトマネージャーの職務は、より影響力が強く、より可視性の高いプロダクトです。そして、彼らはより広いプロダクトプロセスを見ています。

シニアプロダクトマネージャーは、自分自身で検討する能力を示す専門的な経験を持っているべきであり、それは相互依存的な要素を持つ説明可能でデータ駆動型の意思決定であるべきです。

シニアプロダクトマネージャーは、経営者やその他の主要なステークホルダーを巻き込みながら、依存関係にあるチームとプロダクト戦略を共有する必要があります。

言うまでもなく、シニアプロダクトマネージャーは、プロダクトおよび市場に関する深い知識を持っている必要があります。

そして、シニアプロダクトマネージャーは、アソシエイトプロダクトマネージャーやミッドレベルプロダクトマネージャーを指導することができます。

💡 プロダクト・ディレクターになるには?
2つの要件を満たす必要があります。ひとつは、他のプロダクトマネジャーにとって重要なアドバイスの源となることです。そしてもうひとつは、シニアリーダーシップに対してプロダクトチームを擁護する存在になることです。

プロダクト・ディレクター
プロダクト担当ディレクターには、リーダーシップの経験が必要です。そして、役員へのプレゼンの経験や、以前行った仕事をするためのチーム作りの能力が必要です。

プロダクトのディレクターは、より良いプロセスを作り、チーム全体のパフォーマンスを上げ、組織全体のコンセンサスを構築することに重点を置いています。そして、定期的に社内のメンバーと会い、物事が起きていることとその理由、プロダクトに必要なものなどを説明するのです。そのため、この役割はデータに依存します。

市場の動向、最新情報、競合の動き、新プロダクトのベストプラクティス、プロダクト開発プロセスの改善方法など、プロダクト担当ディレクターは多くの市場調査を行っています。

プロダクト・ディレクターは、他のプロダクト・マネージャーのメンターでもあります。プロダクトマネージャーのメンターとしてだけでなく、プロダクトチームの強みを見つけ、それを彼らのために発揮する必要があります。

そして、会社や市場のエグゼクティブレベルで起こっていることをすべてチームが理解できるようにするのです。

プロダクト担当副社長
プロダクト担当副社長は、プロダクト組織のハイレベルなサポートリソースであり、プロダクトビジョン全体とそれが組織にどのようにフィットするかについて責任を負います。

プロダクト担当副社長の仕事と責任は、プロダクト組織の予算を管理し、プロダクトに関する戦略的な決定がビジネスゴールと一致していることを確認し、社内政治や内紛からチームを保護することです。

通常、プロダクト担当副社長は、1年後にチームに何が必要かを検討することに時間を費やします。そして、その目標を達成するために、チームを組織し、戦術的に行動させる必要があります。

プロダクト担当副社長は、ほとんどの場合、プロダクト管理における10年以上の実務経験が必要です。そして、少なくとも5年以上、開発チームと仕事をし、管理し、プロダクトマネージャー、デザイナー、エンジニアを率いてきたことが必要です。

チーフ・プロダクト・オフィサー
チーフ・プロダクト・オフィサー(最高プロダクト責任者)は、通常、プロダクトリーダーとして多くのプロダクト担当副社長を管理する人か、プロダクト担当副社長の単なる拡大版のどちらかです。

チーフ・プロダクト・オフィサーは、プロダクトポートフォリオに目を配り、予算、人員リソース、リサーチが適切に投資され、ROIが最大化されることを確認します。

3年から5年の時間枠の中で戦略的な意思決定をするのです。そして、チームを鼓舞するためにプロダクト目標を設定するのです。

組織全体のパフォーマンスを上げるために、人を指導し、動機づけをする責任があります。この役割で成功するためには、客観的な基準に基づいて開発、測定、改善する必要があります。

この役割の経験要件は様々ですが、通常10年以上から15年以上、あるいは20年以上となります。

プロダクトマネジャーの専門性

専門化が進むプロダクトマネジメント (The Growing Specialization of Product Management)
https://www.reforge.com/blog/product-specializations
By: Adam Fishman (@fishmanaf) and Keya Patel (Linkedin @keyapat)

PMには専門分野があるにもかかわらず、多くの人はPMには標準的なタイプがあり、その役割は同等であると考えています。これは、PMのキャリアが浅かったり、PMへの理解が浅かったりするために起こることです。しかし、PMの役割がすべて同じだと考えてしまうと、問題が生じてきます。

1.ツールが伝わらない: PMは、どのような問題に対しても、自分が使い慣れた同じツールやアプローチを適用します。

2.地道な努力の積み重ね: PMにとって新しいプロダクト分野である場合、PMは苦労し始める可能性があります。

3. 集中の低下: PMの役割が均等であれば、どこに焦点を合わせればいいのかがわかりません。その結果、プロダクトマネジャーの学習は通常遅くなります。

4. 才能の混乱: 具体的な専門分野やスキルを確認せず、他組織での実績に基づいてPMを採用します。

5. 競合する同僚: 企業や採用担当者が、頭の片隅でPMを比較します。

PMの役割はそれぞれ異なりますが、どのPMにも共通して求められるスキルがあります。それは、通常、

「分析、ダッシュボードや主要なコールアウトの解釈、指標や財務目標の理解・設定、開発者・データサイエンスとの協働などに関する技術的・データ的な快適さ。」
コミュニケーションとコラボレーション: 部門横断的なチームを動機付け、目標に向かって導くと同時に、他者(他のチームや経営幹部など)からの賛同を得る。」
「曖昧なプロダクト・顧客ニーズを分解し、適切な解決策を見つけるために実験や反復を行う問題解決力。」
「エンドユーザーと共感し、耳を傾け、共創して、既存のペインポイントを解決したり、新しいペインポイントを特定するユーザー理解。」
「チーム、プロダクト、組織にまたがる多くの可動部分を考慮に入れながら、より大局的な組織、ユーザー、投資家の目標に集中するための戦略的思考。」

そして、PMの専門性には4つのタイプがあります。

画像2

フィーチャー・ワーク
PMの仕事の大半はフィーチャー・ワークです。通常、プロダクトマネージャーはこの分野でキャリアをスタートさせます。

グロースワーク
グロースプロダクトの仕事は、既存の市場をより多く獲得することで価値を創造し、獲得します。」

スケーリングワーク
「スケーリングは、プロダクトチームが機能、成長、プロダクト・マーケット・フィット拡大作業にわたって新しいものを出荷する能力を維持することを保証します。」

プロダクト・マーケット・フィットの拡大
「プロダクト・マーケット・フィットの拡張は、隣接市場、隣接プロダクト、またはその両方に拡張するために、非増加的な方法でプロダクト・マーケット・フィットの上限を増やすことです。」

最後に、これらのプロダクトワークの各領域が、PMのスペシャリティにどのように直接マッピングされるかを見てみましょう。

フィーチャー・ワーク → コアPM
「プロダクトの特徴的な作業を主に行うプロダクトマネージャーはコアPMと呼ばれます。コアPMは、顧客のペインポイントやニーズを解決することにレーザーフォーカスしています。」

グロースワーク → グロースPM
「グロースPMは通常、獲得、CAC、サインアップ、無料トライアル開始、コンバージョン/購入率、マネタイズ、ARPU、リテンションなどのビジネス指標を通して、プロダクトと顧客の旅にレーザーフォーカスしています。」

スケーリング → プラットフォームPM
「プラットフォームPMは、プロダクトワークのスケーリングにフォーカスしています。プラットフォームPMは、組織の継続的な成長のために、社内の顧客/ニーズに焦点を当て、社内のプラットフォームやサービスの拡張を行います。」

プロダクト・マーケット・フィットの拡大 → イノベーションPM
「イノベーションPMは、プロダクト・マーケット・フィットに到達し、それを拡大するための新しい機会を特定し、実験することにレーザーフォーカスしています。」

(アソシエイト) プロダクトマネージャーになるには

HubSpotのPMが語る、プロダクトマネージャーになるための方法 (How to Become a Product Manager, Straight From a HubSpot PM)
https://blog.hubspot.com/service/become-product-manager
By: Scott Judson

(アソシエイト)プロダクトマネージャーになるには、創造的な問題解決能力、戦略的な考え方、協調的な姿勢、卓越したコミュニケーション能力、高い共感力などのスキルが必要です。しかし、これらのスキルは経験を通じて成長させることができますので、それを高めていく姿勢が必要です。

まだプロダクトマネージャーになっていない人は、基本的にプロダクトマネージャーになるには2つの方法があります。1つ目は、今働いていない会社でプロダクトマネージャーになる方法です。おそらく、こちらの方法の方が一般的であることは想像がつくと思います。では、その手順をみていきましょう。

1. 役割について調べ、現役のプロダクトマネージャーと話をする

リンクトインで既存のプロダクトマネージャーとつながったり、YouTubeでプロダクトマネージャーが自分の役割を説明しているビデオを見たりしてもよいでしょう。そうすることで、その仕事に何が必要なのか、また、プロダクトマネージャーを募集しているのはどのような企業なのか、よりよく理解できるようになるはずです。

2. プロダクトマネジメントの認定コースを受講する

PMの役割は外から見ると複雑そうで、それについて調べるのも大変だと思うので、プロダクトマネジメントのコースを受講することをお勧めします。

また、資格を持っていれば、他の候補者の履歴書と差をつけることができます。

3. サイドプロジェクトを立ち上げ、失敗も含めて記録する

サイドプロジェクトを始め、それを最初から最後まで監督することは、あなたにできる最良のことです。プロジェクトを最初から最後まで管理したのですから、プロダクトの開発から発売までのライフサイクルを管理することができます。プロジェクトを通してどのように問題を解決したかを示すだけでなく、失敗や間違いを伝えることで、あなたがそれを学び、プロダクト開発のライフサイクルを管理するスキルを持っていることを証明することができるのです。

4. コミュニケーションとストーリーテリングのスキルを磨く

プロダクトマネジメントには、高いインパクトを与えながらアイデアを簡潔に伝えることができるよう、強いコミュニケーション能力とストーリーテリング能力が必要です。

5. 技術的なバックグラウンドを身につける

プロダクトマネージャーは通常、技術系企業で働くため、初歩的な技術的バックグラウンドを持っていると良いでしょう。そして、この知識を得ることで、必要に応じて新しい技術的なことを学ぶ意欲があることを将来の雇用主に示すことができます。

6. 該当する場合は、アソシエイト・プロダクト・マネジメント・プログラムに応募する

アソシエイト・プロダクト・マネジメント(APM)プログラムは、新卒や早期キャリアのプロフェッショナルに、プロダクトマネジメント分野に参入する機会を提供します。未経験者でも応募可能です。ポジションは一時的なものですが、多くのプログラムは企業内の正社員につながるものです。

7. PM職への応募

APMプログラムに合格した場合は、このステップを行う必要はありません。しかし、キャリアが進んでいる方やAPMプログラムに参加しなかった方は、今こそPMのポジションに応募する時です。小規模な組織から始めて、より大きな企業や有名な企業へとステップアップしていくことをお勧めします。

2つ目の方法は、現在働いている会社でプロダクト・マネージャーになることです。あなたの会社にプロダクト・マネジメント・チームがあれば、このステップを踏むことができます。

1. 仕事でエンド・ツー・エンドで自分の担当できるプロジェクトを見つける

プロダクトマネージャーの認定コースを受講しているのであれば、その例になります。コースだけでなく、会社でも、自分が最後までオーナーになれるプロジェクトがあるかもしれません。あるいは、自分でビジネスを始めることもできます。ただ、大事なのは、新しいアイデアを試して失敗してもいいように、問題設定に取り組むことです。プロダクトマネージャーへの道程で、役に立つヒントを拾ってください。

2. 職場のサイドプロジェクトとして、ボランティアで問題解決に取り組む

企業は、スタートアップ企業であろうと大手組織であろうと、最も困難な課題に取り組む権限を労働者に与えています。本業とは関係のない課題に取り組む自主性や時間がない場合は、自分と上司がやりがいを感じられる課題を見つけるまで模索を続けましょう。

問題を特定したり、チームメイトや上司に問い合わせたりすることも可能です。通常の業務に加え、自分が所有するソリューションの研究、テスト、実装などの雑務を引き受けましょう。

3.困難な問題に取り組み、調査を行い、部門を超えたコラボレーションを主導する実績を作る

会社でも、資格取得コースでも、困難な問題はたくさんあります。プロダクトマネージャー候補として、協働することが必要です。そして大切なことは、取り組んでいるプロジェクトや実験を記録し、発見したことを記録し、学んだことを活かして、プロダクトチームとのネットワーク作りを始めることなのです。また、現在の会社以外でPMのポジションを求めている場合は、個人のブログやリンクトインのプロフィールに自分の成果を記録しておくとよいでしょう。

4. 会社のPM職の募集に応募する

上記のような経験や実績があれば、あなたの会社のプロダクトマネージャーの求人に応募することができます。見込み客や顧客と気楽に話ができる、応募するプロダクトの役割について専門知識がある、測定・分析し、社内の関係者に重要な結果をパッケージングできる、などのスキルをアピールすることができます。そして、これらのスキル、成功や失敗の経験、部門を超えたコラボレーション、プロジェクトのオーナーシップが、面接でのあなたのアピールポイントになることでしょう。

プロダクトマネージャーからシニアプロダクトマネージャーへ

シニアプロダクトマネージャーになるには (Becoming a senior Product Manager)
https://www.lennysnewsletter.com/p/senior-product-manager
By: Lenny Rachitsky (@lennysan) and Jackie Bavaro (@jackiebo)

プロダクトマネージャーのキャリアは神秘的です。個人の貢献者としてスタートし、CPOやプロダクト担当の副社長になるために出世する、という認識を私たちは共有しています。しかし、その中間はどうなっているのでしょうか?

Jackie Bavaroは、シニアPMにレベルアップするために何にフォーカスすべきか、最高のフレーミングを説明します。シニアPMには、3つの最も重要な差別化要因があります。

1. 戦略
シニアプロダクトマネージャーは、プロダクトの長期的な戦略をどれだけ推進するかによって、仕事の優先順位を決めます。
戦略には3つの部分があります。(1)ビジョン、(2)戦略フレームワーク、(3)ロードマップ。どれから始めても構いません。

2. 自律性
優れたシニアPMは、多くのフィードバックやアドバイスを求めますが、上司の助けがなくても、チームを率い、ステークホルダーに対応し、問題を処理し、優れたプロダクトを出荷することができます。彼らは、与えられた指示をそのまま受け入れるのではなく、どのタイミングでそれに異議を唱えるべきかを理解しています。

自律性とは、単に能力が高いということではなく、自律的に機能するために必要な信頼を勝ち取ることを意味します。そのためには、積極的なコミュニケーションと、立ち上げを成功させた実績が必要です。上司と意図的に仕事を共有することも必要でしょう。

3. ニュアンス
上級になればなるほど、「ケース・状況による」が正しい答えのはずなのに、判断を迫られることが多くなります。これらの判断を認識し、整理して推論するのがシニアPMです。彼らは、混乱した状況や難しいトレードオフに対処することができます。

彼らは、プロダクトに関する専門知識と高度なメンタルモデルを持っているので、思考プロセスを数分で書き出すことができます。彼らは、混乱した問題領域で取り組むべき最も重要な課題を素早く特定することができます。

同僚や関係者は、あなたが洗練された思考に磨きをかけるための理想的なガイドです。彼らの悩みを真剣に受け止め、その裏にある複雑さに目を向けてください。彼らが正しいと思う条件とは何でしょうか?

シニアプロダクトマネージャーからプロダクトリーダーへ

渓谷を渡る。プロダクトマネージャーからプロダクトリーダーへ – リフォージ (Crossing the Canyon: Product Manager to Product Leader — Reforge)
Crossing the Canyon: Product Manager to Product Leader — Reforge Navigating a product manager career path can be tough. Our ex www.reforge.com By: Fareed Mosavat (@far33d) and Casey Winters (@onecaseman)

シニアプロダクトマネージャーとプロダクトリーダーの間には、峡谷があります。シニアプロダクトマネージャーからプロダクトリーダーへの移行で、数多くのキャリアが行き詰まるのを目の当たりにします。なぜなら、それはほとんど別の仕事であり、いくつかの新しいスキルが必要だからです。また、シニアプロダクトマネージャーとプロダクトリーダーのインセンティブが一致していないため、難しいのです。

アソシエイト・プロダクト・マネージャーからシニア・プロダクト・マネージャーになると、同じような問題を解決し続けることになりますが、問題は難しくなっていきます。

シニアプロダクトマネージャーからプロダクトリーダーへの移行で重要なのは、
1つのタイプのプロダクトワークの深さ→複数のタイプのプロダクトワークの広さ。

プロダクトマネジメントには、1.フィーチャー・ワーク、2.グロースワーク、3.スケーリングワーク、4.PMF拡大ワークという4つのタイプの仕事があります。このうちのどれかの分野で専門性と深みを身につけるのです。

プロダクトリーダーとして成功するために、
• プロダクトの問題点に対して広い視野を持つ。
• さまざまなタイプのプロダクトワークでROIを最大化する。
• I字型からT字型へ。

自分の仕事をうまくやること → 他人の仕事をうまくやるように訓練すること。

プロダクトリーダーとしてのあなたの価値は、あなたのアウトプットではなく、チームのトータルアウトプットで評価されます。そのため、他の人を上手に育てることが必要です。しかし、あなたが生まれ持った強みというのは、教えるのが最も難しいということを覚えておいてください。

そして、これが招く最も一般的な罠は、最も重要なプロジェクトを自分のために残しておくことです。これは、マネージャーのデス・スパイラルと呼ばれるものです。

今ある資源で解決する → 資源を配分し、周囲に影響を与えることで解決する。

組織横断的にリーダーワークをプロデュースする。自分の直接のコントロール範囲外の問題を解決するために、組織内の他者に影響を与える必要があります。しかし、通常、難しいのは、1.上にも横にも影響を与えることは新しいスキルであり、2. 自分が成功したかどうかを判断されることがない

個人のスコープを広げる → 組織のスコープを広げる。

プロダクトリーダーとして、新しいチームを可能にするために、自分の責任の一部を脱ぎ捨てて、自分の範囲を狭める必要があるのです。そして、軌道修正やエスカレーションを行うべき問題を特定するために、十分なコンテクストを取得し、一貫して十分なコンテクストを提供できるようなシステムを構築する必要があるのです。

プロダクトマネージャー – 階層

クワンの「プロダクトニーズの階層構造」。プロダクトマネジャーの4つのレベル Kwan’s Hierarchy of Product Needs: The Four Levels of Product Managers
https://www.heavybit.com/library/blog/kwans-hierarchy-of-product-needs-the-four-levels-of-product-managers/
By: Connie Kwan (@Conniekwan_)

プロダクトマネージャーの仕事は、意思決定をすることです。意思決定のリスクが高ければ高いほど、その意思決定をサポートするプロダクト・マネージャーには、より多くの経験を積ませたいものです。このように、プロダクトマネージャーには4つのレベルがあります。

画像3

レベル1:出荷⛵️(PM)

「PMが満たすべき最も基本的なニーズは、機能を出荷することです。」このレベルの仕事には、正しい仕様について設計と議論し、顧客のニーズを持ついくつかの機能をテストすることが含まれます。また、エンジニアと仕様についてコミュニケーションをとりながら、日々エンジニアと協力してプロダクトを成功裏にリリースしていきます。

レベル2:企画 🚂(シニアPM)

プロダクト・マーケット・フィットに挑戦し続け、3〜6ヶ月の中期的なビジョンを持ってチームをマネジメントしていく役割です。そして、顧客の真のニーズを引き出す必要があります。また、複数のインプットを用いてプロダクトのビジョンを描き、そのビジョンに基づいてチームをまとめることが求められます。

レベル3 戦略的 ✈️(ディレクター〜VP)

戦略PMは、会社のビジョンを掲げ、BHGへの道筋を見える化します。各経路の検証を行い、テストやリスク低減の方法を見出します。

レベル4戦略的パートナー 🚀(CPO)

企業が急成長するとき、CPOは必要です。CPOは、会社のプロダクト文化を設定し、強化するのに役立ちます。また、CPOはCEOやCFOと社外とのパートナーシップの機会をもたらします。また、CPOは、チーム、取締役会、ユーザーに対して、プロダクトストーリーを作り、伝え、会社の収益と資金調達の流れを維持する手助けをします。

この記事が、プロダクトマネージャーのキャリアパスの全体像を理解する一助となれば幸いです。何か質問があれば、TwitterLinkedInのDMでお願いします。

次に何をすべきか覚えていますか?

この記事や添付されているプロダクトマネジメントの記事をただ読んで終わりにするのではなく、共感したところをハイライトして、感想や学びをGlaspに残しておきましょう。そうすれば、いつでも見返すことができ、私たち皆が同時に学習することができます。
私のプロダクトマネジメントに関する記事のリーディングリストはこちらから参照ください。👉 Glasp – Product Management

では、また次回。

Kei


フォローして最新情報をチェック!

プロダクト開発の見方を変える15のアイデア

プロダクトマネージャーのためのアイデアとメンタルモデル

▼本記事の内容

*この記事は、15 Ideas That Will Shape Your View Of Building Productsを著者の了解を得た上で翻訳したものです。

著者: Alex Pedicini
翻訳者: 渡辺圭祐

1. Whyから始める (Start with Why)

「人々は、あなたが何をしたかを買うのではなく、なぜそれをしたかを買うのだ」。サイモン・シネックのリーダーシップの教えは、リーダーやプロダクトマネージャーがコミュニケーションやインスピレーションを得るための素晴らしいモデルとなっています。多くのリーダーはWhat(プロダクトやソリューション)から始めますが、シネックはWhy(存在意義)とHow(行動の指針となる理念や価値観)から始めることを提唱しています。

画像1
The Golden Circle — Start With Why

2. パレートの法則 (Pareto principle)

80/20の法則とも呼ばれ、結果の大部分は少数の原因から生まれるという考え方です。ビジネスに与える影響の大部分を占める機能や顧客を絞り込み、その機能の改善とユーザーの喜びに焦点を当てます。

3. ドッグフーディング (Eating your own dogfood)

これは自社プロダクトをテストし、使用することで、顧客に共感し、機会領域を特定する練習です。一般的なユーザーと同じ環境や状況でプロダクトをテストすることができれば、さらに効果的です。

4. ベロシティ(速度) (Velocity)

スピードとベロシティは同じではありません。スピードは方向に関係なく進む速さを表し、ベロシティは変位した距離を表します。プロダクト開発では、ベロシティが必要であり、進むべき方向は戦略に向かっているのです。ベロシティを上げるには、優先順位をつけ、戦略に貢献しないタスクやプロジェクトにはノーと言うことが必要です。

画像2

5. 二次的思考(セカンド・オーダー・シンキング (Second-order thinking)

目の前の決断の因果関係を考える一次思考とは対照的に、二次思考では「次に何が起こるか」を考えます。この思考法では、主に、変化や決断がもたらす予期せぬ結果や影響を理解する必要があります。10-10-10ルールは、自分の決定が2次、3次に及ぼす影響を理解するために特に役立ちます。

6. 可逆的な意思決定と不可逆的な意思決定 (Reversible vs. Irreversible decisions)

これは、ジェフ・ベゾスが2016年の株主への手紙で書いていることです。意思決定には、意思決定の大部分を占め、後で簡単に変更できる可逆的なものと、変更しにくい不可逆的なものがあるという考え方です。可逆的な意思決定は、すぐに軌道修正できるので、完全な情報がなくても素早く行うべきです。不可逆的な意思決定は慎重に行うべきで、結論を出すまでに、より広範な情報収集が必要です。重要なのは、自分がどちらのタイプの決断をしているのかをあらかじめ知っておくことです。

7. 機会費用 (Opportunity costs)

すべての決断にはトレードオフがつきものです。あるものを選択することで、別のものにノーと言うことになるのです。これは、優先順位をつけるときやロードマップを作成するときに特に当てはまります。優先順位をつける最も簡単な方法は、「今すぐやるべき、もっと価値のあることはないか」と問うことです。- もし答えがイエスなら、そのもっと価値のあることに取りかかればいいのです。

8. 選択のパラドックス (Paradox of choice)

選択肢が多ければ多いほど、必ずしも顧客が幸せになるとは限りません。人々は提示された選択肢に圧倒され、優柔不断になり、満足度が低くなる可能性があります。それよりも、よりスマートなデフォルト設定と、適切なタイミングで適切な選択肢を提示することに注力し、意思決定の疲労を回避することが重要です。

9. 逆転の思考 (Inversion)

問題に対して異なる視点を持つには、しばしばその問題を逆から考えることが有効です。何かがうまくいく理由を考え抜くのではなく、うまくいかない理由を考えるのです。また、現状から将来を予測するのではなく、最終目標から逆算してバックキャスティングしてみる。このようなことを促進するために、プロジェクトを始める前に「プレモルテム(Premortem)」を実施することが有効なテクニックです。

10. 確率的思考 (Probabilistic thinking)

プロダクト開発では、仮定と不完全な情報に基づいて意思決定を行う必要があります。確率論的思考とは、論理と推定を駆使して、ある事象がどのような結果をもたらすかを推測するプロセスです。このような思考は、どのような問題を解決し、どのようなソリューションを構築するかについて、どこに賭けるべきかの判断材料となります。

11. スケールしないことをする (Do things that don’t scale)

ソフトウェアによって私たちは信じられないほどのスケールで物事を行うことができますが、すべてのプロダクトや企業は小さなところから始まったことを忘れないでください。スケールしないことをするのは、手作業で仕事をすることが、学習への近道であることを思い出させるためです。そうすることで、あなたが目指している問題や顧客に近づくことができますし、そうしなければ見逃してしまうような別の機会も見えてくるかもしれません。時間が経ち、成功すれば、これらの作業を自動化することができます。

12. 前線基地を確保する (Secure the beachhead)

Geoffrey Moore氏は、著書「Crossing the Chasm」の中で、テクノロジー採用のライフサイクルの橋渡しについて述べています。この本では、まずターゲットとなる顧客層の小さなセグメントを特定して販売することで、アーリーアダプターからメインストリーム消費者へとプロダクトを移行させる方法について論じています。この考え方は、まずニッチな市場を見つけ、その狭い市場を満足させてからプロダクトや顧客層を広げていくことに似ています。

13. ビタミン剤と鎮痛剤 (Vitamins vs. Painkillers)

あなたのプロダクトが「あると便利なもの」(ビタミン剤)なのか「なくてはならないもの」(鎮痛剤)なのかを理解しましょう。プロダクトのポジショニングと販売の鍵は、あなたのプロダクトが解決する真のペインポイント、その問題を経験する人、そしてその問題を引き起こす「きっかけ」を特定することです。

14. マズローの欲求階層説 (Maslow’s Hierarchy of Needs)

マズローの欲求階層説は、人間の5つの基本的な動機と欲求を説明したものです。人間の欲求はほとんど変化しませんが、その欲求を達成するための解決策は頻繁に変化します。成功するソフトウェア製品はすべて、これらの基本的欲求のうち少なくとも1つを満たしていることに結びつけることができます。

画像3

15. 制約条件の理論 (Theory of constraints)

「鎖はもっとも弱い輪の部分以上は強くない」。 ボトルネックを特定し、その制約を減らしたり取り除いたりする作業を行うことで、単位時間当たりの処理能力を向上させることができます。このモデルは、あなたが作っているプロダクトであれ、あなたが依存しているプロセスであれ、作業中のあらゆるシステムに適用することができます。

−−−−−−−−−−−−−−−−−

1. Start with Why (Whyから始める)
2. Pareto principle (パレートの法則)
3. Eating your own dogfood (ドッグフーディング)
4. Velocity (ベロシティ)
5. Second-order thinking (二次的思考)
6. Reversible vs. Irreversible decisions (可逆的な意思決定と不可逆的な意思決定)
7. Opportunity costs (機会費用)
8. Paradox of choice (選択のパラドックス)
9. Inversion (逆転の思考)
10. Probabilistic thinking (確率的思考)
11. Do things that don’t scale (スケールしないことをする)
12. Secure the beachhead (前線基地を確保する)
13. Vitamins vs. Painkillers (ビタミン剤と鎮痛剤)
14. Maslow’s Hierarchy of Needs (マズローの欲求階層説)
15. Theory of constraints (制約条件の理論)


フォローして最新情報をチェック!

プロダクトマネージャーの役割とスキル

プロダクトマネージャーについて解説した記事はたくさんありますが、私にとって、たくさんの記事は部分最適に過ぎず、通常、全体像を理解することは難しいものです。そこで、プロダクトマネージャーの役割とスキルに関する記事をリストアップし、全体像がわかるように構成してみました。

最初の部分は、プロダクトマネジャーの役割と責任についてです。2つ目は、プロダクトマネージャーのスキルについてです。

この記事や添付されているプロダクトマネジメントの記事をただ読んで終わりにするのではなく、共感したところをハイライトして、感想や学びをGlaspに残しておきましょう。そうすれば、いつでも見返すことができ、私たち皆が同時に学習することができます。

それでは、さっそく始めましょう。


目次

  1. プロダクトマネージャーの役割
  2. プロダクトマネージャー – スキル

*この記事は「Product Manager’s Role and Skills」を翻訳したものです。

著者・翻訳者: 渡辺圭祐


プロダクトマネージャーの役割

プロダクトマネジメント – スタートはここから (Product Management — Start Here)
https://svpg.com/product-management-start-here/
著者: Marty Cagan (@cagan)

優れたプロダクトは、ユーザーや顧客の真の問題を解決し、顧客に愛され、かつ我々のビジネスに役立つ方法で提供されます。

プロダクトマネージャーは、開発されるものが価値あるものであり、かつ実現可能なものであることを確認する役割を担っています。そして、プロダクトディスカバリーとは、ユーザーにとって価値があって、使い勝手がよく、実現可能で、実行可能なソリューションを発見することです。これがプロダクトマネジメントの核心です。

もし、プロダクトの機能をディスカバーする権限がなかったり、プロダクトをアップデートする権限がなければ、あなたがいるのはフィーチャーチームやデリバリーチームということになります。真のプロダクトマネージャーになりたいのであれば、その違いと重要性を理解している企業に転職する必要がありそうです。

プロダクトマネージャーの仕事
https://joshelman.medium.com/a-product-managers-job-63c09a43d0ec
著者: Josh Elman (@joshelman)

プロダクトマネージャーの仕事は、あなたのチーム (そして会社) が正しいプロダクトをユーザーに出荷できるようにすることです。

ソース: A Product Manager’s Job

プロダクトマネジメントとは、価値があって、使えて、実現可能で、実行可能なソリューションを見つけることです。そして、プロダクトマネージャーとは、チームや会社のためになる優先順位の高いことに全時間を費やす人なのです。プロダクトマネージャーは、会社全体の目標と目的を正確に理解し、ビジョンに自分のチームを適合させる方法を理解する必要があります。

1) チームを助ける: 優れたプロダクトマネージャーは、自分のチームにとって最も重要なタスクに全神経を注ぎます。これには基本的に、(a)コーディネーション: チームが明確な目標と焦点を持って計画し、決定を下し、うまく協力していることを確認すること、(b)コミュニケーション: チームが互いに効果的にコミュニケーションをとり、何がいつ起こり、なぜそれが起こっているのか、特に状況が変化する中で理解していることを確認すること、が含まれます。最も優れたプロダクトマネージャーは、チームメンバー全員からインプットを受け、議論を表面化させ、時には結束を断ち切り、選択する際には合意を得る (あるいは最低でも全員が計画にコミットする) 責任を負います。

2) (と会社) : プロダクトマネージャーとして、会社の一般的な目的と目標、そして自分のチームが全体像の中でどのように位置づけられるかを意識する必要があります。そして、チームメンバーが会社にとって必要だと考えるものを提供するのではなく、他のチームと協力しながら会社にとって必要なものを提供し、貢献していると感じてもらわなければなりません。

3) 出荷: 顧客にプロダクトを届けることほど重要なことはありません。優れたプロダクトマネージャーは、完璧に仕上げることと、出荷することの間で微妙なバランスを保たなければならないことを知っています。ゴールと目的が明確で、ユーザーとユーザーに達成してほしいことをよく理解しているチームは、究極のトレードオフを強いられるかもしれません。このタスクを達成するのを助けるのが、優れたプロダクトマネジメントです。

4) 適切なプロダクト: 出荷は重要ですが、優れたプロダクトマネージャーはチームと協力して、プロダクトが適切なものであることを保証します。優れたプロダクトマネージャーは、何が正しいか、何が間違っていると思われるかについて確かな感覚を持っており、また、テスターや他の試用者からの初期の意見に効果的に耳を傾けています。さらに重要なのは、プロダクトが出荷された後、優れたプロダクトマネージャーはそれが正しいプロダクトであるかどうかを評価することができるということです。

5) ユーザーのために: プロダクトを作る上で最も難しいのは、主要なユースケースを表現すること、つまり、誰がなぜそのプロダクトを使うべきかというストーリーを伝えることです。最高のプロダクトマネージャーは、消費者の代弁者として、プロダクトに関するあらゆるやりとりの中で消費者の声を代弁します。そのためには、ターゲットとなる消費者、彼らが抱える問題や困難、そして彼らが求める価値や喜びをどのように提供すべきかを徹底的に把握することが必要です。

プロダクトマネジメントのトライアングル
https://productlogic.org/2014/06/22/the-product-management-triangle/
著者: Dan Schmidt (@danielfschmidt)

プロダクトマネジメントの責任には、「余白を埋める」ことや、部門を超えたチーム間の「接着剤の役割を果たす」ことが含まれます。正しいプロダクトをユーザーに届けるためには、多くのチームメンバーが関係しているため、それぞれの役割の間にギャップが生じます。

下の図は「プロダクトネットワーク」と呼ばれるもので、ソフトウェアプロダクトのコンテクストの基本的な要素を描いたものです。企業では、プロダクトネットワークに欠落したリンクを意味するホワイトスペースが残ります。もし、それが埋まっていれば、プロダクトネットワークがより良く機能し、より成功したプロダクトにつながります。

プロダクトマネージャーの責任は、プロダクトネットワーク内の4つの領域すべての健全な機能を維持することです。そのため、プロダクトマネージャーは、重要なホワイトスペースを認識し、リンクとして機能するか、それを埋める方法を見つけることによって、これらの重要なリンクを維持する必要があります。そのためには、プロダクトマネージャーは、ウェブ解析やプロジェクトマネジメントなど、プロダクトマネジメントに関連するすべての役割を担うことができなければなりません。

領域Aは、開発者、プロダクト、ユーザーの間に存在するホワイトスペースです。開発者とユーザーでは、プロダクトに関するメンタルモデルが異なります。ユーザーはユーザーインターフェースを通してしかプロダクトを見ることができませんが、開発者はコードを覗き込むことができます。この余白を埋められるのがデザイナーです。

領域Bは、ユーザー、プロダクト、ビジネスの間にあるホワイトスペースです。この領域では、人々がプロダクトを使って見出した価値を、利益に変換していきます。ビジネスモデルに応じて、この領域の複雑さは異なります。

領域Cは、開発者、プロダクト、ビジネスの間に存在します。この領域では、企業のリソースと努力の焦点を決定することができます。

プロダクトマネジメントではないもの
https://svpg.com/what-product-management-is-not/
著者: Josh Elman (@joshelman)

上記の記事で紹介したように、プロダクトマネジメントとは、価値があって、使えて、実現可能なソリューションを発見し、出荷することです。しかし、多くの企業にとって、プロダクトマネジメントという仕事自体が曖昧なものです。だから、プロダクトマネージャーを求める声が多いのですが、求めていることはプロダクトマネージャーの仕事ではないことが多々あります。何がプロダクトマネジャーの仕事ではないのか、リストを一つずつ見ていきましょう。

プロダクトマネジメントはビジネスケースを定義することではない
ビジネスケースを定義するプロダクトマネージャーもいますが、それは実際のプロダクト作りに何ら貢献しません。経営陣が投資の選択をする際に、それを必要とするため、それを行っているだけでしょう。

プロダクトマネジメントは市場要求事項を定義するものではない
多くの企業は、プロダクトマネージャーが市場の要求を決定し、エンジニアがその要件を満たすプロダクトを作ると考えています。しかし、このプロダクトの定義を行う責任者は、個人的にこれらの人々(ユーザー/顧客)と話をしなければなりません。そして、プロダクトマネジメントの目的はプロダクト・マーケット・フィットを見つけることであり、そのためには市場の要求と技術力の両方を十分に把握する必要があります。したがって、プロダクトマネージャーはプロダクト要件と市場要件を別々に考えてはなりません。

プロダクトマネジメントは要件収集ではない
プロダクトマネジャーは、顧客のニーズを通じてプロダクトの要件を文書化するのではありません。真のプロダクト組織は、顧客が解決すべき問題を抱えていることを理解していますが、プロダクトの仕様を指示することはできません。別の言い方をすれば、顧客の要求とプロダクトの要求を混同してはいけないということです。

プロダクトマネジメントはプロジェクトマネジメントではない
企業によっては、プロダクトマネージャーとは、要件を収集・文書化し、構想から出荷までを取りまとめる人だと考えているところもあります。しかし、プロダクトマネジメントがプロジェクトマネジメントと異なるのは、価値ある、使用可能な、実現可能な、解決策を発見する、プロダクトディスカバリープロセスであることです。

プロダクトマネジメントはプロダクトマーケティングではない
人々は、価格設定、プロモーション、ポジショニング、メッセージなどのプロダクトマーケティングや、プロダクトの発売活動を期待しています。しかし、実はこれらはプロダクトマネジャーの仕事ではありません。何度も言いますが、価値があり、使用可能で、実現・実行可能な、ソリューションを発見するのがプロダクトマネージャーの仕事です。

プロダクトマネージャー – スキル

プロダクトマネージャーのスキル(年功序列) – 詳細
https://medium.com/agileinsider/product-manager-skills-by-seniority-level-a-deep-breakdown-cd0690f76d10
著者: Brent Tworetzky (@tworetzky)

XO Groupは、プロダクトマネージャーの6つのスキルエリアを分解しました。

以下は、プロダクトマネージャーのキャリアパスの選択肢を、個人貢献者 (左側) とマネージャー (右側) の場合で示したものです。

ソース: Product Manager Skills by Seniority Level — A Deep Breakdown

スキル1:戦略的思考

ソース: Product Manager Skills by Seniority Level — A Deep Breakdown

これは、「ますます大きくなる問題やプロダクト領域に対して、社内のソート・リーダーシップを発揮して答えを導き出す能力です。含まれるものは、ブレーンストーミング、思考の構造化、戦略の推進、専門家になること」です。

アソシエイト・プロダクト・マネージャーには、「他者と建設的にブレーンストーミングを行う」スキルが求められます。このレベルでは、より高度な戦略的思考は必要ありませんが、ユーザーへの共感を示すことが必要です。

スキル2:コミュニケーション

ソース: Product Manager Skills by Seniority Level — A Deep Breakdown

コミュニケーションは、「より大きな、より高い利害関係のある人々に対して、明確な文章と口頭でのコミュニケーション。この中には、明確なメールを書くこと、直接会って明確にコミュニケーションをとること、文章を書くこと、プレゼンテーションを行うことが含まれる」と説明されています。

コミュニケーションはどのレベルのプロダクトマネージャーにとっても重要ですが、レベルが上がれば上がるほど、グループミーティングや、プレゼンテーションのスキルが必要となります。

スキル3: コラボレーション

ソース: Product Manager Skills by Seniority Level — A Deep Breakdown

コラボレーションは、「チーム内外で、より多くのファシリテーションを行い、物事を成し遂げることができるようになります。含まれるもの: 会議への積極的な参加、会議の主導、班のプロセスの運営、他のチームとの問題解決、適切に対立を回避させること」と説明されています。

上位のプロダクトマネージャーには、組織内の幹部や幅広いチームと連携し、リードやファシリテーションを行うスキルが求められます。

スキル4:テクニカル

ソース: Product Manager Skills by Seniority Level — A Deep Breakdown

テクニカルスキルとは、「プロダクトマネジメントとパートナー機能 (エンジニアリング、デザイン) のツールを使い、チーム全体でうまく連携することです。含まれるものは、ストーリーを書くこと、分析すること、プロトタイプの構築・実行、SEOの理解」です。

テクニカルスキルはプロダクトマネージャーにとって重要であり、ミドルレベルのプロダクトマネージャーであってもプロトタイプをうまく構築することが求められます。

スキル5:詳細と品質

ソース: Product Manager Skills by Seniority Level — A Deep Breakdown

これは、「拡大するスコープの中で結果を出し、ミスをキャッチする。ユースケースを含む明確な仕様書の作成、大小のプロダクトを期限内にバグの少ない状態で出荷すること、障害に対処するための選択肢を操り、成果を上げることが含まれます。」です

アソシエイトプロダクトマネージャーの場合、担当するのはプロダクトの小さな領域ですが、機能の仕様書を書き、それを出荷するスキルが求められます。

スキル6:ユーザーサイエンスと共感

ソース: Product Manager Skills by Seniority Level — A Deep Breakdown

ユーザーサイエンスと共感は、「ユーザーをより理解し、ユーザーのニーズや行動にプロダクトを適合させるため、ユーザーサイエンスのツールキットを習得する。含まれるのは、調査、インタビュー、プロトタイピング、A/Bテスト、分析ツールをきちんと実行できること、異なるユーザータイプとそのニーズを理解し表現すること、ユーザーサイエンスをインサイトに統合すること」です。

表の一番上にあるように、ユーザーへの共感がプロダクトマネージャーの基本であることが理解できます。

スキル7:マネジメント

ソース: Product Manager Skills by Seniority Level — A Deep Breakdown

マネジメントは「人と組織をうまく成長させることです。含まれるものは、メンタリング、マネジメント、チームの成長、組織の成長」です。

アソシエイトマネージャーやプロダクトマネージャーの場合、デザイナーやエンジニアなどのチームメンバーがプロダクトマネージャーの下で働くことはないため、このスキルは必要ありません。しかし、シニアプロダクトマネージャーであれば、他のジュニアプロダクトマネージャーを指導する必要があります。

プロダクトマネージャーとテクニカルスキル…ディールについて
https://productschool.com/blog/product-management-2/technical-skills-product-managers/
著者: Product School (@productschool)

プロダクトマネジャーになるには、実は技術的なスキルは必要ありません。調べてみると、そのようなスキルは必要ないと安心させる記事や資料がたくさん見つかるでしょう。しかし、新任のプロダクトマネージャーはテクニカルスキルがないことを恐れているのです。もちろん、テクニカルスキルがあるに越したことはありません。核となるテクニカルスキルは、コーディングとプログラミングになります。基本的なスキルは以下です。

• コーディング・プログラミングの知識:  HTML、CSS、Javascript、C+、Pythonなど
• SQL: データの管理・操作に活用
• データ構造とアルゴリズム

プロダクトマネジメントは、デザイン、ビジネス、テクノロジーの間に存在します。この3つのうち1つでも長けていて、他の2つを学ぶ意欲があれば、プロダクトマネージャーを目指す上で大きなプラスになるはずです。以下は、Product Schoolのプロダクトマネージャーの技術力に関するQ&Aです。

Q: プロダクトマネージャーは技術系出身でなければならないのでしょうか?
A: いいえ。すべての道はプロダクトに通じており、最強の開発チームにはあらゆる経歴を持つプロフェッショナルがいます。

Q: プロダクトマネージャーの役割には、技術的な要件があるものもあるのでしょうか。
A: はい。一部の職務では、CSの学位や、職務に必要なテクニカルスキルの実証的な知識が必要とされます。

Q: プロダクトマネージャーはコードを書く必要がありますか?
A: 理解しているに越したことはありませんが、あなたの仕事はソフトウェア開発者ではありません。テクニカルプロダクトマネージャーには、もちろんコードの知識が求められます。

Q: では、プロダクトマネジャーになるために大学に戻ってCSの学位を取得する必要はないのでしょうか?
A: いいえ。CSの学位を必要とする職種のほとんどは、そうでない類似の職種があります。例えば、Googleのあるチームはプロダクト・マネージャーに技術的なバックグラウンドを求めますが、そうでないチームもあります。

Q&Aにあるように、プロダクトマネージャーにとって技術的なスキルは必ずしも必要なものではありません。プロダクトマネージャーとテクニカルスキルの関係は、プロダクトマネージャーとデザインスキルの関係にも似ています。プロダクトマネージャーは、実際のデザイン作業を行うわけではありませんが、デザイナーと協力して、デザインが必要なプロダクトを管理・実現することになります。デザインに対する理解が深ければ、その貢献度はより高いものになるでしょう。

プロダクトマネージャーの重要な特徴のひとつに、「好奇心」があります。好奇心は、テクニカルの世界での成功へとあなたを導きます。

技術力を一から身につけるなら以下が参考になります。

• CS50: コンピュータサイエンスの基礎を学べます。ハーバード大学が提供する無料のオンラインコースです。
• Codecademy: 入門するには、このコースの受講がおすすめです。さまざまな学習パスやプロジェクトが無料で提供されています。


優れたプロダクトマネジャーになるために必要なこと
https://hbr.org/2017/12/what-it-takes-to-become-a-great-product-manager
著者: Julia Austin (@austinfish)

プロダクトマネージャーを目指す場合、その役割を評価する上で、「コアコンピテンシー」「EQ (感情知能)」「会社への適合性」という3つの大きな要素について考える必要があります。

コア・コンピテンシー: すべてのPMが持っていなければならないコア・コンピテンシーは以下のものです。

• 顧客インタビューとユーザーテストの実施
• デザインスプリントの実施
• 機能の優先順位付けとロードマップの計画
• リソース配分の技術 (科学ではありません!)
• マーケットアセスメントの実施
• ビジネス要件と技術要件、またはその逆の変換
• 価格設定と収益のモデル化
• 成功指標の定義と追跡

優れたプロダクトマネージャーは、長年にわたってプロダクトを定義し、出荷し、反復することで、これらのスキルを磨き続けています。

エモーショナルインテリジェンス(EQ): インタビューにおいて、一流のPMは顧客に共感し、彼らのボディランゲージや感情を察知し、そのプロダクトや機能が解決すべき苦悩を推し量ることができます。ダニエル・ゴールマンは、EQの4つの主要な特徴を定義しました。次に、それらがPMの役割とどのように関連しているかを見てみましょう。

1. リレーションシップ・マネジメント: 成功するPMの最も重要な特性の1つです。優れたPMは、社内外のステークホルダーと誠実で信頼できる関係を築くことで、人々のモチベーションを高め、その潜在能力を最大限に発揮できるようにします。

2. 自己認識: 公平であり続け、自分の個人的な好みをプロダクトに投影することを避けるために、PMは自己認識を持っている必要があります。自己認識が欠けていると、他の本質的な目標が頓挫したり、機能が十分に評価されない場合にエンジニアとの関係が悪化し、PMへの信頼が失われる可能性があります。

3. 自己管理: 最高のプロダクトマネージャーは、緊急性がある中でも恐怖やストレスを感じることなく、正しい優先順位で積極的に物事を進めていく方法を知っています。また、一歩下がって立て直しを図るタイミングも心得ています。

4. 社会的認識: プロダクトマネージャーは、共感、組織意識、そしてサービスという社会的な意識を持つべきです。プロダクトマネージャーは、顧客のプロダクトに対する気持ちや悩み、営業チームの売り方に対する悩み、サポートチームのサポートに対する悩み、エンジニアリングチームの開発に対する悩みを理解しなければなりません。このような社会的な認識を持つことで、優れたプロダクトマネジャーは、顧客のやるべき仕事を処理するプロダクトを提供することができ、それがプロダクト・マーケット・フィットにつながります。

企業フィット: コアコンピテンシーと高いEQだけでなく、企業との適合性もプロダクトマネージャーのキャリアを成功に導きます。企業のタイプによってプロダクトマネジャーに求められるものは異なります。

1. PMがエンジニアリングを推進する(企業): PMはニーズを収集し、古典的なプロダクト要件書を作成し、それをエンジニアリングに渡して、技術要件を仕様化する「壁越し」手法をとります。

2. エンジニアリングがプロダクトを動かす: エンジニアはその分野の技術を発展させ、PMはソリューションのテストやフロントエンドのアクセスポイント (UI、API) の設計などを行う、より技術的にフォーカスしたプロダクト企業 (クラウド、ビッグデータ、ネットワーク) ではこのスタイルになります。

PMとエンジニアリングのパートナーシップ: このような状況では、PMとエンジニアリングは、相互に発見し、意思決定し、責任を共有する、強い陰陽の関係を持っています。エンジニアはPMと一緒に顧客インタビューに参加し、PMはスプリントミーティングに参加してタスクのブロック解除や要件の説明をサポートします。

また、会社のステージや役員との関係によって、プロダクトマネージャーの役割も以下のように異なります。

スタートアップ: プロダクトマネージャーは、プロダクトの発見、定義、出荷だけでなく、プロダクトの価格、マーケティング、サポート、そして販売まで担当することがあります。プロダクト・マーケット・フィットを目指し、規模に応じた機能を身につけるため、プロダクトマネージャーはスクラップ的な雰囲気の中で成長し、あいまいさや頻繁な方向転換にも対応できる必要があります。

長所: PMは企業戦略に関与する可能性が高く、シニアリーダーや取締役会にアクセスでき、より大きなリスクと影響力を行使することができます。また、会社のリソースに対してより大きなパワーとコントロールを持つことができます。

短所: 組織内には通常、メンターやロールモデル、ベストプラクティスがほとんど存在しません。予算が限られていることが多く、プロダクトマネージャーは与えられた仕事をこなすのに必要な経験が不足していることがあります。

成熟した企業: PMの役割はより限定的になり、価格設定や市場参入戦略などを担当する社員がいる場合があります。プロダクトマネージャーは、より広範なプロダクトマネジメントチームの一員となることがほとんどでしょう。

• 長所: メンターやロールモデル、開発標準やベストプラクティスがPMに提 供される可能性が高くなります。

• 短所: PMは企業戦略に対する理解が浅く、消費者の声の一つに過ぎません。PMは企業戦略への理解が浅く、消費者の声の一つに過ぎないため、政治的・経済的な制約を受ける可能性があります。


創業者/CTO/CEOとPMの関係: 
創業者/CEO/CTOがプロダクト開発プロセスにどれだけ積極的であるかを知ることは、特に初期段階の組織では非常に重要です。創業者・CEO・CTOが非常に積極的であれば、PMの役割は自らアイデアを出し、それを押し進めるというより、創業者等のアイデアを具体化する手助けや顧客とコンセプトを確認するといったサポート的なものになるかもしれません。

長所: 創業者やチーフレベル役員と一緒にプロダクトイノベーションに取り組むのが好きな人にとっては、とても楽しい仕事となります。

短所: プロダクトの方向性をより大きくコントロールしたいPMにとっては、フラストレーションがたまるかもしれません。また、より技術的な創業者やチーフレベルの人々がエンジニアと直接仕事をすることを好む場合、PMにとっては仲間外れになるなど、困難が伴います。

この記事が、プロダクトマネージャーの役割とスキルの全体像を理解する一助となれば幸いです。何か質問があれば、TwitterLinkedInでDMをください。

次に何をすべきか覚えているでしょうか?

この記事や添付されているプロダクトマネジメントの記事をただ読んで終わりにするのではなく、共感したところをハイライトして、感想や学びをGlaspに残しておきましょう。そうすれば、いつでも見返すことができ、私たち皆が同時に学習することができます。

それでは、また次回お会いしましょう。

Kei


フォローして最新情報をチェック!

%d人のブロガーが「いいね」をつけました。