プロダクトチームとフィーチャーチームの比較

この記事は多くの人を動揺させるに違いありません。

それは残念なことですが、テック企業におけるプロダクトの役割をめぐる継続的なノイズと混乱の度合いは、悪化の一途をたどっています。 さらに、プロダクト担当者のためのカンファレンスでの講演やトレーニングプログラム、いわゆる認定プログラムにおいて、問題点や問題行動が制度化されつつあるのを私は目の当たりにしています。

私は過去に何度かこの問題について話しており、特にEmpowered Product Teams(権限を与えられたプロダクトチーム)に関する記事と基調講演で述べています。 しかし、多くの人はその中で自分の聞きたいことだけを聞いており、私はもっと明確に伝える必要があることが分かってきました。

ですから、この記事は読むのが辛いかもしれませんが、もしあなたがプロダクトの世界の人々からの矛盾した混乱したメッセージにイライラしているなら、ここで我慢していただければ、私は必要な明瞭さを提供できるのではないかと期待しています。


翻訳者注:
この記事の翻訳にあたり、マーティ・ケーガンにお願いしたところ、この記事の内容は既にEMPOWEREDの中に記載されているとのことでした。しかし、この記事の内容より幅広く、深く学びたい場合は、INSPIREDとEMPOWEREDの本で勉強するのが良いと言及すれば記事を公開して大丈夫だろうとのことでしたので、以下にリンクをシェアしておきます。この記事は、以下の本の軽量版で、より深く広く勉強されたい方は下の本よりお願いします。

この記事は、『Product vs. Feature Teams』を著者の了解を得た上で翻訳したものです。

著者: Marty Cagan
翻訳者: 渡辺圭祐


技術者の世界では、大まかに言って3種類の「プロダクトチーム」が存在します。

最も一般的なのは、数の上ではプロダクトチームではなく、デリバリーチームです。「開発チーム」「スクラムチーム」「エンジニアリングチーム」とも呼ばれ、もしあなたの会社がSAFeのようなものを行っているなら、残念ながらこれはあなたのことです。 この状況では、何人かの開発者と、プロダクトオーナーがいます。 このモデルにおけるプロダクトオーナーは、私が「バックログマネージャー」と呼んでいるものです。 誰かがこのマネジメント作業を行う必要がありますが、これはアウトプットを提供するためのものであり、私が懸念している、顧客のための真の一貫したイノベーションの必要性とは、実はほとんど関係がないのです。 このモデルがなぜウォーターフォールを再パッケージ化したものに過ぎず、真のテックプロダクト企業では使われないのかについては、別のところで書きました。 そこで、この話は終わりにしましょう。

この記事は、他の2つのタイプのチームの違いについて書いているのです。

さて、これから非標準的で合意もされていない用語集を紹介することになるので、公正に警告しておきましょう。 しかし、今日、業界として、他の2種類のチームを「プロダクトチーム」または「スクワッド」と呼んでいるので、それらの用語集を使わなければならないのです。 しかし、これからわかるように、表面的なレベルでは似ていますが、特にプロダクトマネージャーの役割について話すと、両者は劇的に異なっているのです。

エンパワードプロダクトチーム(権限を与えられたプロダクトチーム)の良さについて書いたとき、私はここでプロダクトチームと呼び続けることにしました。 具体的には、プロダクト、デザイン、エンジニアリングのクロスファンクショナルであること、(アウトプットではなく)結果に焦点を当て、それによって評価されること、そして、解決するよう依頼された問題の最善の方法を見出す権限を与えられていること、です。

この意味でのプロダクトチームの目的は、顧客が好む方法で問題を解決し、かつ私たちのビジネスに役立つようにすることです。

そうでないことを望むかもしれませんが、世の中のチームのうち、このような意味でのプロダクト・チームはごく一部であることは分かっています。

多くの場合、チームにはまったく権限が与えられていません。 それに対して、彼らはビジネスに奉仕するために存在しています。

この記事では、この第3のクラスのチームをフィーチャー・チームと呼ぶことにします。 私は、フィーチャー・チームの確立された定義を少し曲げていますが、これらのチームがすべてアウトプットについてであるということを強調するのに役立つので、この用語を使用しています。 フィーチャー、そして時にはプロジェクトもそうです。 通常、ロードマップと呼ばれる優先順位付けされたリストという形でチームに提供されます。

しかし、ここでさらに深く掘り下げる必要があります。

プロダクトには常に4つのリスクがあることを思い出してください。

  • 価値リスク(人々はそれを買うか、あるいは使うことを選択するか?)
  • ユーザビリティリスク(使い方がわかるか?)
  • 実現可能性リスク(今ある時間、スキル、テクノロジーで構築可能か?)
  • ビジネス実行可能性リスク(このソリューションは、私たちのビジネスの様々な局面で有効か?)

プロダクトチームでは、プロダクトマネージャーは価値実行可能性を確保することに明確に責任を持ち、デザイナーはユーザビリティを確保することに責任を持ち、テックリードは実現可能性を確保することに責任を持ちます。 このようなチームでは、全員が納得できる解決策を見出すために、激しいギブアンドテイクで真に協力し合うのです。

私が、エンパワードプロダクトチームの真のプロダクトマネージャーであることがいかに大変であるかを話したり書いたりするとき、それはまさに価値と実行可能性を確保するのが難しいからです。 もし、これを簡単に考えているのなら、この記事をぜひ読んでみてください。

しかし、フィーチャーチーム(機能チーム)には、ユーザビリティを保証するデザイナーがいますし、実現可能性を保証するエンジニアもいます。しかし、これは理解すべき重要なことですが、ロードマップにその機能を要求したステークホルダーや経営者の責任は、価値とビジネスの実現性にあるのです。

もし彼らが「機能xを作って欲しい」と言えば、彼らは機能xがある程度の価値をもたらすと信じており、機能xがビジネスにとって実現可能なものだと信じているのです。

ステークホルダーは、価値と実行可能性に対して暗黙の責任を負っているにもかかわらず、彼らが期待した結果が実現されなかった場合、あなたとあなたのチームを非難する原因を探すことは、指摘しておく価値があります。 時間がかかりすぎた、デザインが悪かった、期日までに間に合わせるために重要な機能を削った、などなど。 そしてもちろん、あなたのチームは、そもそもこのプロダクトが作る価値があるとは思ってもいなかったでしょう。 この問題については、昔からよく言われていることで、私も何度も書いています。

表面的には、フィーチャーチームも真のエンパワーメントを受けたプロダクトチームも、どちらもスクワッドです。 そのため、両者は似ているように見えますが、その違いは深いのです。

まず、プロダクトマネージャーの役割から見ていきましょう。 エンパワードプロダクトチームでは、プロダクトマネージャーは価値と実行可能性を保証する必要があり、顧客、データ、業界、特にビジネス(セールス、マーケティング、財務、サポート、法務など)についての深い知識は絶対に譲れず、不可欠なものです。

しかし、フィーチャーチームでは、その知識は(せいぜい)関係者の間で分散しているのが現状です。

いずれにせよ、このモデルにおけるプロダクトマネージャーの責任は、フィーチャーチームの場合、非常に異なることがおわかりいただけると思います。

フィーチャーチームのプロダクトマネージャーの仕事は、最も一般的には、機能をデザインし提供するための「猫の群れ」、または、特定の何かに責任を持つわけではない、漠然とした弱いクロスファンクショナルリーダーという形で説明されます。 このようなフィーチャーチームは、しばしば自分たちがプロダクト発掘を行っていると思っていますが、実際には単なるデザインとちょっとしたユーザビリティ・テストのようなものです。

しかし、フィーチャーチームがプロダクトマネージャーの役割に与える影響は他にもあります。

チームに権限が与えられていないため、(はっきり言えば、アウトプットを提供するように言われても、意味のある権限は与えられていない真のプロダクトデザイナー(サービスデザイン、インタラクションデザイン、ビジュアルデザイン、ユーザーリサーチに長けた人)を惹きつけ、維持することは非常に難しいのです。

フィーチャーチームがある場合、デザイナーは(もしいれば)グラフィックデザイナーであることがほとんどです。 グラフィックデザインやビジュアルデザインが重要でないわけではありませんが、ここで重要なのは、誰かが少なくともインタラクションデザインを理解し、できればユーザーリサーチを行う必要があるという大きなギャップがあることです。 したがって、このモデルでは、これらのギャップを埋めようとするプロダクトマネージャーへのプレッシャーが非常によく見られます。

デザイナーが使うツールを学ぶことは難しくありませんが、良いデザインとユーザーリサーチの方法を学ぶことは難しいからです。 悲しいことに、多くのプロダクトマネージャーは、本物のプロのプロダクトデザイナーと仕事をする機会がないため、自分が何を失っているのかさえわかっていないのです。

幸運にも、あなたのチームに真のプロダクトデザイナーがいる場合(少なくとも、彼らがそのスキルを十分に発揮できる会社に転職するまでは)、彼らは通常(そして当然)プロダクトマネージャーの目的とは何かを疑問に思うでしょう。

その結果、フィーチャーチームでは、プロダクトマネージャーの役割は主にプロジェクトマネージャーであり、一部(未熟な)デザイナーであるということになります。

エンジニアにも同じようなフラストレーションがあります。 プロジェクトマネージャーであるプロダクトマネージャーは、エンジニアが考える仕事のやり方としばしば対立します。 言うまでもなく、このモデルではエンジニアは納品に追いやられており、何度も言うように、もしそうであれば、エンジニアの本当の価値は半分程度しか得られません(したがって、優秀なエンジニアは退職して、本当に自分の技術を発揮できる、エンパワードプロダクトチームに入りたいと思うでしょう)。

プロダクトマネージャーは「会社で最も強力な人材の一人である」必要があり、「CEOはプロダクトマネージャーを会社の将来のリーダー候補とみなすべきである」、そして「強力なプロダクトマネージャーはプロダクトのCEOである」と私が書くとき、私は間違いなくフィーチャーチームのプロダクトマネージャーについて話しているのではありません

この時点で、あなたがフィーチャー・チーム・モデルで仕事をしているのか、それともエンパワーメントされたプロダクト・チーム・モデルで仕事をしているのかが分かっていればいいのですが、私は、人々がしばしば、自分がフィーチャー・チーム・モデルであることを認めたがらないことを学びました。

そこで、あなたのチームに適用できるテストをいくつか紹介しましょう。

  • 優先順位をつけた機能と日程が記載されたロードマップが提供されているか、または、ビジネス上の成果とともに解決すべき問題が割り当てられているか?
  • あなたとデザイナーの間に役割の混乱があるか?
  • あなたとデリバリー・マネージャーの間に役割分担の混乱はあるか?
  • 一日の大半をプロジェクトマネジメントに費やしていないか?
  • OKRを使用したが、結局拒否されるか、成果と機能を意図的にマッシュアップして納品するのか、混乱したか?
  • あなたのチームには、宣教師や傭兵がいるか?
  • 説明責任のレベルはどの程度か?

フィーチャーチームとプロダクトチームは、表面的には非常によく似ていますが、その運営方法、権限委譲と説明責任のレベル、そして特にプロダクトマネージャーの責任において、劇的に異なっています。

私は、いくつかの例外を除いて、最高の企業の最高のプロダクトチームは、エンパワードプロダクトチームモデルであると断言します。 しかし、私が最高のプロダクト会社と考える会社であっても、すべてのプロダクトチームが権限を与えられているわけではないことを認めます。 実際、いくつかのチームはフィーチャーチームです。 通常、それはリーダーシップがその特定のチームをまだ信頼していないためです。 信頼を得るには、まずその信頼が必要な場合もあります。 また、リーダーが解決策を指示することが問題である場合もあります。

私は、真にエンパワードプロダクトチームに対する強い偏見を、これまで隠そうとはしてきませんでした。 しかし、私は、単にエンパワードチームを支持するだけでなく、フィーチャー・チームや、彼らが引き起こす問題、そして、彼らがもたらす悪い結果を呼び起こす必要があると信じています。

今日、数え切れないほどの企業が、デリバリー・チーム・モデルの無駄さに気づき、テクノロジーを駆使した真のプロダクト・カンパニーに変身する必要があることを知りながら、フィーチャー・チームに移行するための表面的な変更で「その条件を満たせる」と思っているのです。

最後に、フィーチャーチームのプロダクトマネージャー権限を与えられたプロダクトチームとの違いを強調しておきたいと思います。 これは、全く異なる仕事であり、全く異なるスキルセットを必要とします。 おそらく、同じ職種であるべきでさえないでしょう。

多くのデザイナーやエンジニアが、真のプロダクトマネージャーに触れたことがなく、真にエンパワーメントされたチームで働くことができないのは、私にとって悲しいことです。 だからこそ私は、世の中には十分に活用されていない人材がたくさんいると主張し、優れた企業が行っているような働き方をするよう説得を続けているのです。

今すぐできることの1つは、次にプロダクト関連の記事やツイートを読んだり、カンファレンスの講演に参加したり、プロダクトトレーニングに参加したりするときに、著者や講演者やトレーナーが、エンパワードプロダクトチームモデルについて話しているか、それともフィーチャーチームモデルについて話しているか、考えてみることです。

更新: この投稿に関して寄せられた多くの質問に対応するフォローアップ記事を投稿しました。

マーティ・ケーガン

SVPG 創設者・パートナー・プロダクト担当


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

Marty Caganの他の記事を読む 👀

👉 Marty Cagan

広告

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

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でより多くの時間をスケーリング、機能、新プロダクトの拡張作業に費やしています。

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

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


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

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

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

プロダクトとは何か?

この記事は、へそ曲がりのようなものではないことをお約束します。 これは、重要かつ基本的なトピックに関する非常に現実的な記事となります。

*この記事は「What is a Product?」を、著者の了承を得た上で翻訳したものです。

著者: Marty Cagan
翻訳者: 渡辺圭祐

権限を与えられたプロダクトチームに関する以前の記事が人気を博した結果の1つは、プロダクトに関して混乱しているいくつかの重要な領域が明らかになったことです。

プロダクトとは何かという一般的な話題には多くの重要な側面がありますが、この記事では、真に機能横断的なプロダクトチームであることが、単なる業界の流行語ではなく、なぜ非常に重要なのかについてお話したいと思います。

少し背景を説明すると、プロダクトが初めて説明されたとき、私は非常にエンジニアリング中心の会社(HP Labs)でエンジニアをしていました。 もしあなたが何らかのエンジニアでないなら、一般的に頭でっかちだと思われていました。 デザイナーでさえ、自分のことを「ヒューマンファクターズエンジニア」と呼んでいました。

私がテックリーダーとしての指導を受けていたとき、エンジニアリング・マネージャーは、実世界に向けたプロダクトを作るときにはエンジニアリングだけでは不十分であることを理解するよう求めました。 彼はホワイトボードに、非常にシンプルですが重要な方程式を書きました。

プロダクト=カスタマー×ビジネス×テクノロジー

そして、成功するテックプロダクトは、顧客の課題を解決し、我々のビジネスの課題を解決し、技術の課題を解決しなければならない、と説明したのです。

この方程式は、テックプロダクトにおける4つの大きなリスクに対応しています。ユーザビリティ・リスクへの対応は、顧客に対するソリューションの一部であり、実現可能性リスクへの対応は、技術に対するソリューションの一部であり、事業実現性リスクへの対応は、事業に対するソリューションの一部なのです。 そして、価値リスクは、この3つすべての関数です。

さらに、この3つのうち1つでも対処できなければ、結果(プロダクト)は失敗に終わることを指摘しました(数学が苦手な人のために、ゼロの何倍でもゼロである)。

そして、ビジネスを解決するプロダクトマネージャーの役割、顧客を解決するデザイナーの役割、そして、技術を解決するエンジニアの役割について、私はすでにかなり熟知していると説明しました。

さらに、この3つの領域は深く絡み合っていると説明しました。

技術的な決断は、デザイナーができることに(良くも悪くも)劇的な影響を与えます。 同様に、デザイン上の決定は、ビジネス上の考慮事項に大きな影響を与える可能性があります。 そしてもちろん、ビジネス上の制約は、デザインやテクノロジーの選択肢に影響を与える可能性があるでしょう。

私が技術責任者になったことで、彼は私に、私の仕事はもはやエンジニアリングだけではない、と強調しました。 私は、プロダクト・マネージャーやデザイナーと協力し、効果的な解決策を見出さなければならないのです。

願わくば、ほとんどの皆さんにとって、これが「プロダクト101」のすべてだと思います。 いずれにせよ、もうお分かりだと思います。 しかし、プロダクトの世界にいる多くの人は、そうではないと言えるでしょう。

私は常に、ビジネスモデルが全てだと考えているスタートアップの創業者やプロダクトマネージャーに会っています。 彼らは、大金を稼ぐことが確実な美しいビジネスを示す、すべて記入された(しかし検証されていない)ビジネスモデルのキャンバスを持ってきます。 価格設定、コスト構造、価値提案、市場参入戦略など、すべて考え尽くされています。 必要なのは、アプリを作成できる代理店の名前だけです。 今書いたことが大げさであればいいのですが。

また、私はあまりにも多くのデザイナー、そして一部のデザインリーダー(そして少なからぬプロダクトマネージャー)に出会いますが、プロダクトはユーザー体験がすべてだと考えています。 彼らは、顧客を満足させれば成功すると信じているのです。 そんな簡単なことならいいのですが。 彼らは、収益、コスト、販売、マーケティング、法律、プライバシーなど、経済やその他のビジネス上の考慮事項について、関心があるふりをすることさえしません。

また、プロダクトマネジメントにもデザインにも意味を見出さないエンジニアがたくさんいることも周知の事実です。

プロダクトマネジメント、ユーザー・エクスペリエンス・デザイン、エンジニアリングの各リーダーが、このプロダクトの基本的な方程式を深く理解し、プロダクトマネージャー、デザイナー、エンジニアにも積極的に指導することが絶対に必要です。

この点を強調するために、ここではっきりと言います。

もし、あなたの会社のCEOが、プロダクトマネージャーの一人または数人が、ビジネスの本当の仕組みを全く理解していないと考えたら、その人は信頼され、力を与えられる望みはほとんどないでしょう。 CEOは、この点に関してプロダクトマネージャーを判断しており、もし彼らがナイーブであるとか、もっと悪いと思われたら、その認識を覆すのは非常に難しくなるでしょう。 ですから、私は新任のプロダクトマネージャーには、絶対に下調べをする必要があると、かなり執拗に言っています。

さらに、もしCEOがプロダクト、デザイン、エンジニアリングのリーダーの一人または複数を、ビジネスの解決に何が必要かを理解していないと見なすなら、そのリーダーは重要な決定がなされるときにテーブルにつくチャンスはほとんどないでしょう。

だから、ビジネスがすべてだとか、顧客がすべてだとか、技術がすべてだとか、そんなことは言わせません。 プロダクトはそれよりも難しいのです。 この3つがすべてなのです。

この記事の原稿を手伝ってくれたSVPGパートナーのクリス・ジョーンズに特別な謝意を表します。


この記事の著者であるMarty Caganは、PMにとって有名な一冊である『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』の著者でもあります。PMについて興味のある方は、こちらからご確認ください。


Marty Caganの他の記事を読む👀

👉 Marty Cagan

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

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

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

この記事や添付されているプロダクトマネジメントの記事をただ読んで終わりにするのではなく、共感したところをハイライトして、感想や学びを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


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

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

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

最初の部分は、プロダクトマネジャーの役割と責任についてです。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人のブロガーが「いいね」をつけました。