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

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

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

私は過去に何度かこの問題について話しており、特に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

広告

プロダクトマネジャーのためのプロダクトポジショニング

プロダクトがどのように位置づけられるかを理解することが重要である理由

プロダクトマネージャーの重要な責務は、プロダクトがマーケットにおいてどのように位置づけられるかを定義することです。価格、ユーザーエクスペリエンス、機能、性能、ブランディング、カスタマーサービス、パートナーシップは、ターゲットとなる顧客が、既存のマーケットにおける代替品と比較して、あるプロダクトの価値をどのように認識するかに影響を及ぼします。

ポルシェ、アウディ、フォルクスワーゲンは、VWグループ内のポートフォリオとして、ユニークなプロダクトを持つグローバルブランドとして、同じ自動車マーケットに共存しています。これは、独自のプロダクトポジショニングの結果です。ポルシェを求める顧客がフォルクスワーゲンを検討することはないでしょうし、その逆もまた然りです。しかし、アウディのターゲットとなる顧客は、ポルシェとのつながりによって、より高い価値を感じるかもしれません。

▼ 本記事の内容
  1. ランド・アンド・エクスパンド戦略の解説
  2. プロダクトポジショニング – ケーススタディ – アーキモト
  3. プロダクトマネージャーにとって重要なこと
    1. 1. 複数のプロダクトにより、競合に対して、主要な価格帯でのプロダクトポジショニングを強化することができる
    2. 2. 複数プロダクト間のポジショニングを慎重に行うことで、特定のプロダクトに嗜好が偏るようなプロダクト戦略ができる
    3. 3. ポジショニングは、段階的に展開することで、戦略を促進させることもできる

この記事は、「Product Positioning for Product Managers」を著者の了解を得て翻訳したものです。
著者: Stephen Pittman
翻訳者: 渡辺圭

ランド・アンド・エクスパンド戦略の解説

新しいマーケットや破壊的なプロダクトは、顧客が認識し、求めるものを再定義する余地があります。例えば、キャッシュアプリ(Cash App)のユーザーは、友人や家族から払い戻しを受けるために無料アプリをダウンロードするかもしれませんが、その後、そのユーザー体験を好むと判断し、直接口座振込を追加します。次に、デビットカードを追加し、最終的にはETFやビットコインを購入するようになります。

地方銀行と競合するこれらのサービスはすべて、ピアツーピア決済のためにダウンロードした同じアプリで可能なのです。これは、プロダクトを試すための障壁が低い、いわゆる「ランド・アンド・エクスパンド」戦略です。時間の経過とともに、顧客の特定のニーズに対応するために収益を生むサービスが追加されます。そして、Cash Appのエコシステムは、親会社ブロック(Block)傘下のスクエア(Square)のエコシステムに効果的な顧客獲得戦略を提供します。

プロダクトポジショニング – ケーススタディ – アーキモト

アーキモト(Arcimoto) (NASDAQ: FUV) は、オレゴン州ユージーンに拠点を置く電気自動車会社です。同社の使命は、持続可能な交通システムへの移行を促進することです。しかし、このミッションにはひねりが加えられています。アーキモトは、このシフトは、大型で価格が高く汚染を引き起こす自動車から、適切なサイズで超効率的かつ手頃な価格の電気自動車(EV)へと移行したときに実現されると考えています。

マーク・フローンマイヤーは、アーキモトの創設者兼CEOです。彼は、ソフトウェア会社Garage Gamesを売却した後、より小型の車両デザインでEVマーケットを追求することを決意し、同社を設立しました。プロダクト戦略は、材料とバッテリーの必要量を減らすために、車両の重量を大幅に削減することでした。主な成果は、エネルギー効率の向上と材料費の削減です。これにより、最終的な小売価格と車両運用にかかる総費用を下げることができるのです。

彼らのプロダクトのひとつであるファン・ユーティリティ・ヴィークル(Fun Utility Vehicle: FUV)は、安定性を高めるためのリバーストライク構成の3輪に、前輪駆動、デュアルで独立した電気モーターを加えたタンデム2シーターです。低重心と1,300ポンドの車体重量が安全性をさらに高めています。また、スチールフレームは乗用車のルーフクラッシュ耐性をクリアしています。また、従来の自動車に比べ、重量が軽いため、エネルギー効率は173マイル/ガロン相当(MPGe)となっています。

FUVの目標小売価格は、2〜3年後のスケールアップ生産で12,000ドル前後からとなります。しかし、少量生産での現在の小売価格は17,900ドルからとなっています。より標準的な4輪EVの平均小売価格は約46,000ドルで、テスラ・モデルYのような人気モデルは62,990ドルからとなっています。FUVは、短時間の通勤や街中での用事のために、セカンドカーとしてより手頃な価格のEVの選択肢として位置づけられるでしょう。

アーキモトは、2021年1月にオレゴン州ユージーンのティルティングモーターワークスを買収し、特許取得済みのティルティングトライク技術をマイクロモビリティに焦点を当てた新プロダクトに使用することを発表しました。今年初め、マーク・フローンメイヤーは、操縦性を向上させるために傾斜技術を搭載した第3世代のプロトタイプeTrikeを公開しました。

アーキモトはこのeTrikeをミーンリーンマシン(Mean Lean Machine: MLM)と呼び、今年(2022年)の第4四半期を目標にプロダクトを発売します。MLMの販売開始価格はまだ発表されていませんが、eBikeを参考にすると、基本構成に含まれる内容によって、4,000〜7,000米ドルの範囲になると推測されます。

MLMの構成と価格は、FUVをより多く販売するために慎重に設定されるのだと思います。FUVにはもっとたくさんの機能があるけれども、MLMに比べると価格はそれなりに上がる、というのが価値観でしょう。MLMがFUVの販売台数とカニバリゼーションになるとは思えませんが、都市部の個人はよりコンパクトなデザインを好むかもしれません。マーケットが判断することです。また、MLMは生産台数が増えれば増えるほど、FUVよりも早く粗利率を改善できるかもしれません。

近年、eBikeの人気は高まっており、その大半は1,000~4,000米ドルの価格で販売されています。しかし、バッテリーの大きさ、航続距離、2輪での安定性などの面で制約があります。また、従来の自転車よりもはるかに重いのですが、坂道を登るのを助けてくれます。アーキモトは、eBikeを検討している消費者に、より安定性と航続距離のあるeTrikeをアップセルすることができると予測しているのでしょう。アーキモトMLMは、風雨からライダーを保護するオプションやタンデム構成も含む予定です。

価格だけを見れば、アーキモトはMLMやFUVなどのコンシューマー向けから、デリベレーター(Deliverator)やラピッドレスポンダー(Rapid Responder)などの企業向けまで、3輪をベースにしたオプションを揃え、EVを倍増させています。また、旅行先でFUVをレンタルする企業向けには、フリート販売も可能です。DoorDash、UberEats、Grubhub、Postmatesなどのブランド向けのデリベレーターフリートは、主要マーケットにおけるギグ・エコノミー向けのレンタルを可能にします。

アーキモトのプロダクトのポジショニング


上図は、4 輪EVの平均価格が 46,000 ドルであるのに対し、アーキモトMLM (eTrike)、FUV、デリベレーター、ラピッドレスポンダーの3輪構成が、推定 4,000 ドルから 35,000 ドルという価格で、複数の用途に対応していることを示しています。

アーキモトは、GMC e-Hummer 1 台の材料とバッテリーで、Tesla EV 2 台、アーキモトFUV 8 台、アーキモトMLM 100 台を製造できると見積もっています。アーキモトは持続可能なエネルギーへの移行に向け、自律走行型 EV の Robotaxis が1 マイルあたり 1 ドル以下の価格で大規模なライドシェアに容易に利用できるようになるまで、4 輪 EV が高い小売価格で達成できることを加速させます。

リチウムイオン電池と半導体チップは、EVの需要が指数関数的に増加する一方で、近中期的には供給制約が続くと思われます。テスラは昨年からEVの価格を複数回引き上げ、需給のバランスを取っています。ガソリン価格が上昇を続ければ、そのEV需要はさらに加速する可能性が高いです。

供給制約が続き、価格が上昇すれば、アーキモトの省資源・低価格のオプションの需要が高まる可能性があります。つまり、持続可能なエネルギーへの移行を加速させるためには、3輪のプロダクトポジショニングにおいて、リバーストライクEVがより重要になる可能性があるのです。MLMは、高価格のFUVには乗りたくないが、自転車では無理な合理的な通勤のためにEVを導入したいという見込み客を転換させる重要な役割を果たす可能性があります。

また、デリベレーターは、都市部でのラストワンマイル配送のニーズに応えるため、ブランドEVフリートに対して強力な価値を提供します。食品、食料品、薬、花、パッケージ商品、電子機器などは、従来の4輪車の選択肢を覆すこのEVの構成で簡単に配達することができます。そして、より高いデリベレーターの価格設定は、ビジネスユースケースによって支えられています。

MLMの最小限のフォームファクターは、FUVのより多くの機能がより高価であるべきということをサポートします。また、デリベレーターの価格が高いことで、量産によってFUVの初期価格がMLMの価格帯に近づくまで、現在の17,900ドルの初期価格を維持することができるのです。MLMとデリベレーターは、FUVの価格設定をサポートするブックエンドとして機能します。

アーキモトのポジショニング

アメリカ北東部のような多くの地域では、EVを囲う付属品があっても、冬季の天候が問題になります。これらのEVは、小さな子供のいる家庭や、通勤時間が長い人にとって、主要な車の代わりとなるものではありません。しかし、通勤時間が短い家庭や、用事を済ませるためのセカンドカーとしてなら、アーキモトEVは有力な選択肢となります。現在、アーキモトEVは、アリゾナ、カリフォルニア、フロリダ、ネバダ、オレゴン、ワシントンのみで販売されていますが、アーキモトが新施設で生産規模を拡大するにつれて、他の州への販売も拡大していく予定です。

アーキモトの 1~2 人乗り 3 輪リバーストライク EV は、従来の 4 輪クーペ、セダン、SUV、ピックアップトラック、バン、スポーツカーのデザインから大幅に軸足を移したものです。しかし、推定4,000ドルから35,000ドルの価格帯で展開するアーキモトのEVプロダクトラインは、適切な価格であれば、FUVデザインだけよりもはるかに早く収益の成長を促進することができます。

また、デリベレーターとラピッドレスポンダーは、EV生産の大部分を効率化するために、FUVのシャーシの上に最終的な構成を載せたものに過ぎないのです。今年は、2025年までに第一工場で週1,000台のFUV(デリベレーター、ラピッドレスポンダー、FUVシャーシをベースにした他のデザインを含む)を生産する目標に向けて、アーキモトにとって重要な年になるでしょう。

プロダクトマネージャーにとって重要なこと

それでは、アーキモトのケーススタディやプロダクトポジショニングから得られる重要なポイントは何でしょうか。

1. 複数のプロダクトにより、競合に対して、主要な価格帯でのプロダクトポジショニングを強化することができる
プロダクトポジショニングにおける複数プロダクト

上図は、X軸が価格の上昇、Y軸が性能の上昇で、複数のプロダクトが図示されています。つまり、左下がローエンドプロダクト、右上がハイエンドプロダクトということになる。

「X」、「Y」、「Z」は、より高性能で高価格なプロダクトの採用を目指すプロダクトポートフォリオ戦略です。「Z」は「Y」と大きな価格差をつける位置づけにあります。 そのため、同クラスで高性能な「Y」は「Z 」に対してお得感があります。そして、「X」は、「Y」の優位性をさらに確立しつつ、提供される性能に対してより良い価格設定でローエンドマーケットにも対応する、という位置づけになります。

この戦略は、よりプレミアムなプロダクトでより高い粗利を追求するのに適しているでしょう。ブランドは重要であり、高性能プロダクト間のシナジーを活用して、中性能プロダクトをサポートする必要があります。これは、共通のプラットフォームやブランドの核となる技術を使うことで実現できます。

2. 複数プロダクト間のポジショニングを慎重に行うことで、特定のプロダクトに嗜好が偏るようなプロダクト戦略ができる

上図の「XX」は、ローエンドでは「x」に対して性能面で、価格面では「yy」に対して相対的に競争力のある位置にあります。そして、「yy」は「Y」に対して、価格面でより有利な価格設定になっています。つまり、「XX」と「yy」の両プロダクトは、そのポジショニングと連動して、より低価格でマーケットが大きそうな「XX」を中心に売上を伸ばしているのです。プロダクトZのポジショニングは、「XX」と「yy」の売上に焦点を当てたこの戦略にはあまり影響を及ぼしません。

戦略を促進するポジショニング
3. ポジショニングは、段階的に展開することで、戦略を促進させることもできる

ウェアラブルやスマートデバイスなどのスマートハードウェア技術に関連したプロダクト販売やサービスでは、主要なビジネスの前提条件を検証するために、初期展開の範囲や条件について交渉する必要があります。プロダクト会社によっては、無償トライアルを実施し、顧客企業の負担を軽減しています。

私は、クライアントには発注書を持ってゲームに参加してほしいと思っています。しかし、新しいもののリスクを軽減するために、私は「アルファ展開」を提案することも好きです。これは、たとえ多くの企業で使われているプロダクトであっても、特定の顧客に対して初めて導入するものだからです。90日間のトライアルで終了するのではなく、最低90日間の継続的な導入の最前線となります。その後、「ベータ展開」にアップグレードされるか、30日前に通知してキャンセルされるまで、月ごとに自動更新されます。

90日間に限定され、その後は月単位となり、規模は50~100台程度となるため、サブスクリプションサービスの価格は上図の「A」のように高く、デバイスは定価で販売されます。しかし、規模を小さくすることで、トータルコストは抑えられます。価格については、範囲(例:12ヶ月)や規模(例:1,000台)を大きくすることで安くなります。

しかし、これらの「アルファ展開」を成功させる鍵は、以下の通りです。

  1. 8週間のプログラムで顧客の成功を検証するための目標を定義する。
  2. 8週間を2週間のスプリントに分割して展開する。各スプリントには、8週間の目標に対する進捗を追跡するための重要な結果を設定する。
  3. ラーニングプランを使用して、何がうまくいっていないか、何がうまくいっているか、プロダクト機能、トレーニング、コミュニケーションなどの改善方法に関するフィードバックなど、主要なインサイトを収集する。
  4. スプリント後のアップデートやデータレビューを行い、主要なステークホルダーが進捗や次のステップに関与できるようにする。
  5. 8週間プログラムの結果をもとに、「ベータ展開」スケーリングプランの推奨事項を、途中経過と完全な形で提示する。サブスクリプションサービスは、上の図の「B」のように、より多くの範囲と規模を持つ低価格のサービスです。10倍のステップアップは、より詳細な目的をテストするためです。


プロダクト、セールス、カスタマーサクセス、エンジニアリングの各チームが協力し合い、主要アカウント内での展開が拡大するにつれ、プロダクト体験とサービスのパフォーマンスが顧客固有のニーズと比較して向上していきます。このように、キーステップごとに導入規模が10倍になると、「A」→「B」→「C」→「D」のように、パフォーマンスが向上する一方でサブスクリプション価格が低下することがあります。 このように、共通の目標に向かって協力し合うことで、ウィンウィンの結果を得ることができるのです。そして、100台のデバイスから始まる「アルファ展開」は、「D」の「デルタ展開」に到達すると10万台のデバイスになり、大企業のアカウントでも同じプロセスでスケーリングを続けることができるようになるのです。


ステファンは、マサチューセッツ州ケンブリッジに拠点を置き、睡眠時無呼吸症候群とその関連疾患の新規治療法の発見に取り組む臨床段階の企業、アプニメッド社のウェアラブル担当ゼネラルマネージャーを務めています。それ以前は、自身の会社であるSD Pittman & CoやLuminopia、Philips、Respironicsを通じて、ウェアラブル、デジタル治療薬、医療機器に関する顧客のプロダクトをリードしてきました。チュレーン大学で生物医学工学の理学士号と理学修士号を取得しています。

ステファン・ピットマン(Stephen Pittman)

sdpittman.substack.com


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

プロダクトの機能の肥大化をどのように防ぐか?

プロダクトを作るとき、どの機能を作り、どの機能を手放すかの線引きが難しいことがあります。この線引きがうまくいかないと、「フィーチャー・ブロート(Feature Bloat)」という、プロダクトが遭遇する最も恐ろしい用語に行き着くことになります。

フィーチャークリープ、フィーチャーファイト、フィーチャーオーバーロードとも呼ばれるように、機能が多すぎることは、すべてのチームが気をつけなければならないことです。顧客離れ、複雑すぎるプロダクト、そして予期せぬ技術的負債につながる可能性があります。

このような罠を回避し、目的を持って機能を構築する方法について、以下にいくつかのヒントをまとめました。

ポイント
  • 問題を解決しようとするときは、常に「何を」「なぜ」と問うこと。
  • チームが機会を特定するのに役立つプロダクト問題テンプレートを使用する。
  • フィードバックを重視し、リクエストを実行に移さないことで、偏りを避ける。
  • 目的を念頭に置き、ロードマップの優先順位を決める。
  • 光り物よりもユーザビリティを優先する。
▼本記事の内容
  1. 機能の「何を」「なぜ」作るか
  2. プロダクト問題テンプレート
  3. 検証をやめ、無効化を始める
  4. フィードバック vs リクエスト
  5. すでに知っていることを検証しない
  6. ロードマップの優先順位をつける
  7. ユーザビリティを優先する

この記事は「How To Avoid Feature Bloat」を翻訳したものです。
著者: Andrea Saez
翻訳者: 渡辺圭祐

機能の「何を」「なぜ」作るか

次に何に注力すべきかを考えるとき、プロダクトマネージャーは常に2つの重要な質問をする必要があります。

  • 私たちが解決しようとしているのは、どんな問題なのか?
  • なぜ、それを解決しようとするのか?

これにより、チームはアウトプットや解決策ではなく、プロダクト戦略に集中することができます。言い換えれば、最終結果ではなく、目的にフォーカスを置くということです。

これにより、チームは適切な発見を行い、仮説を立て、実験を行い、アイデアを進める価値が実際にあるかどうかを理解することができるようになるのです。

プロダクト問題テンプレート

手始めとして、プロダクト問題のテンプレートを使用することから始めるとよいでしょう。このテンプレートは、チームの誰もが新しいアイデアを提案するときに使うことができます。

  • どのような問題を解決しようとしているのか?
  • 仮説
  • ユーザーにとってどんな価値があるのか?
  • 私たちの会社にどんな価値をもたらすか?

では、実際に誰かが送ってきそうなアイデアを例にとって考えてみましょう。

顧客のための社内コミュニティを作ろう。

なぜ、これが問題提起ではなく、解決策なのかわかりますか?

上の提案は、「××をしよう」という一点だけに焦点を当てています。理由を説明しておらず、単に何かをするための生の発言です。

代わりに、チームにテンプレートに記入してもらうことができます。上の例をとると、次のようなものになるでしょう。

  • どのような問題を解決しようとしているのか?
    私たちは、顧客とより密接に関わり合いたいと考えています。
  • 仮説
    もし、ユーザーとのより良い関わり方を見つけることができれば、彼らの知識を活用し、より多くの質問をし、より多くの実験を行い、より良い関係を築くことができるようになるはずです。これがあれば、解約を減らし、初期ユーザーを適用させることができるのです!
  • ユーザーにとってどんな価値があるのか?
    当社とのコミュニケーションと透明性が高まります。
  • 私たちの会社にどんな価値をもたらすか?
    より多くの顧客と話し、発見し、彼らの問題を理解することができる。

上記のようなシンプルなテンプレートがあれば、チーム全体が成果や解決すべき問題について考えるようになります。「Xをやろう」という会話から、「この問題を解決するにはどうしたらいいか」という会話に変わり、組織全体でプロダクトシンキングを確立することができるのです。

この時点で初めて、オーディエンス(コミュニティもその一つかもしれません)を巻き込む方法に焦点を当て、最終的な解決策のためにあらゆる可能性を模索することができるのです。

検証をやめ、無効化を始める

機能追加を評価する際、プロダクトマネージャーはしばしば顧客の声を参考にします。

しかし、多くのチームが2つの重大な間違いを犯しているのを私はまだ見ています。

  1. 「要件」と「新機能のリクエスト」を集めようとする。
  2. すでに知っていることを検証しようとする

これこそが、多くのプロダクトチームが不要な機能のループに陥っている原因です。

ここでは、その対策について説明します。

フィードバック vs リクエスト

プロダクトマネジメントとは、フィードバックを受けることであり、リクエストを受けることではありません(もちろん、代理店で働いている場合は別ですが)。

その会話を変え、「機能リクエスト」という言葉を捨てましょう。

代わりに、これらの機能リクエストを「顧客フィードバック」と呼ぶようにしましょう。

これは、リクエストに基づいて新しい機能を構築するのではなく、お客様のフィードバックに基づいて機能追加を慎重に検討することを意味します。これにより、質問をして問題を理解し、顧客とプロダクトに利益をもたらす解決策を実行することも可能になります。

覚えておいてほしいのは、顧客は自分の現在の経験に基づいて機能追加を依頼する傾向があるということです。彼らは問題があることを知っていますが、最善の解決策は何かを定義するのはあなた次第なのです。

すでに知っていることを検証しない

フィードバックを分析し、すでに知っていることに基づいて質問をすると、自分自身を牽制することになり、まったく何も学べません。

そうではなく、今までとは違うアプローチで、自分が知っていることを無効にするような質問を始めてみてください。そうすることで、プロダクト機能を追加することを避けることができるかもしれません。悪い機能は、偏見や狭い視野から生まれることが多いのです。

適切な顧客調査によってこのサイクルを断ち切り、現在の仮説がいかに間違っているかを理解することができます。

ロードマップの優先順位をつける

明確なロードマップを持って、ファネルの一番上の意思決定プロセスから始めることで、作る必要があると思われるものの半分に優先順位をつけることができます。

ロードマップの作成には、遅延によるコストの分析、マーケットリサーチ、競合他社の分析など、多くのことが必要ですが、シンプルで堅実なスタート地点は、明確な目標を設定することです。

この目標を設定することで、組織全体が集中力を維持し、実際にプロセスの早い段階で機能の肥大化を避けることができます。

つまり、もしあなたが作ろうと思っているものが、現在その目的に合っていなければ、すぐに選択肢として捨てることができるのです。

ユーザビリティを優先する

新しいプロダクトをデザインする場合、機能を増やしたからといって、ユーザーが幸せになるとは限りません。

顧客にとっての使いやすさを優先することで、ソリューションの複雑さをある程度取り除いてください。

言い換えれば、あなたは、世界中のすべてのベルとホイッスルと魔法のユニコーンをデザインすることができますが、それはあなたがそれを構築する必要があることを意味するものではありません。

実際に役立つものを最も現実的で本質的な形で作り、顧客に提示し、次のイテレーションで再評価を行います。

これを「構築、測定、学習」のループと呼びます。

構築、測定、学習のループ

  • あなたのユニコーンの最小限の愛すべきバージョンを構築する。
  • 作ったものの成功を測定する。
  • その経験から学習する。

そして、必要であれば、その上にさらに構築することができます。多くの場合、人々が欲しがっていると考えていた光り輝くものの半分が、そもそも必要でなかったことがわかります。

おめでとうございます!あなたのチームは機能の肥大化を避けることができました。

– – – – –

原文はUserpilot Blogに掲載されています。


フォローして最新記事をチェック!

プロダクトの出荷の時間価値

「シッピング・アズ・ア・フィーチャー」がフレームワークを取得

シッピング・イズ・ア・フィーチャー(Shipping is a Feature)」は、プロダクトマネージャーにとって核となる原則である。完璧なプロダクトを作ることはできないので、不完全なプロダクトをいつ、どのように出荷するかを学ぶ必要がある、というものです。

私は、この原則をPMとしての自分の努力の指針として使ってきましたが、ステークホルダーに対して実行可能な最小限のプロダクト(MVP)を管理し合理化するための具体的なフレームワークが欠けているといつも感じていました。

出荷の時間価値は、この原則を適用するためのフレームワークです。これは、貨幣の時間価値と呼ばれる金融の基本的な概念を借用したもので、簡単に言うと次のようなことを提唱しています。

今日の1ドルは明日の1ドルよりも価値がある。

なぜなら、物価は時間とともにインフレになり、将来あなたの1ドルで買えるものは少なくなるからです。


▼ 本記事の内容
  1. 出荷の時間価値
    1. グラフからわかること
    2. スタートラインに立つ、もうひとつのレンズ

*この記事は、「The Time Value of Shipping」を著者の了承を得た上で翻訳したものです。
著者: Brandon Chu
翻訳者: 渡辺圭祐


簡単な例

今日、バスケットボールが12ドルだとします。毎月1ドルずつ稼げば、1年後には12ドルになりますが、それでもインフレのせいで買えません。

仮にインフレ率が5%だとすると、1年後には12.60ドル(+5%)、2年後には13.23ドル、・・・というように、バスケットボールの値段は上がっていくことになります。

13ヶ月目の給料日まで、コートに立つのを待たなければなりません。

プロダクトに例えると

  1. バスケットボールを買うのは、顧客に出荷するとき。通常はMVPです。
  2. バスケットボールの価格は、ユーザーがそのプロダクトに期待するものです(任意の時点で)。
  3. あなたのチームが時間をかけて築き上げた顧客価値の合計があなたの収入となります。

あなたの仕事は、バスケットボールを購入するのに十分な価値を、時間をかけて構築することです。これをグラフにすると、ほとんどの組織がプロダクト価値とMVPをどのように見ているかがわかります。

The Time Value of Shipping

このグラフの大きな特徴は、顧客の期待が平坦で静的であることです。つまり、プロジェクトを開始したときに顧客が望むものは、出荷するときにも顧客が望むものであるということを意味しています。このような考え方に陥るのは無理もないことですが…。

「調査によって、ユーザーは最低でもxとyを欲しがっていることがわかったので、xとyが揃い、それ以外のものがなければ、すぐに出荷する」。

この考え方は非常に合理的に聞こえますが、顧客の期待に与える時間の影響について深く掘り下げて考えてみる必要があります。

出荷の時間価値

このグラフに時間の効果を加えて描き直してみましょう。

お金の時間価値と同様に、出荷の時間価値もシンプルな考え方です:今、顧客価値を提供することは、後で価値を提供することよりも価値がある。

もし、後で価値を提供することを選択した場合、ユーザーの期待のインフレを考慮する必要があり、それを補うために最終的なプロダクトがより良いものである必要があります。

顧客の期待曲線と価値曲線の軌跡の違いは、はっきりと見て取れます。前者は時間とともに指数関数的に成長し、後者は平坦になります。

顧客価値は、PMが最もインパクトのある仕事を優先させるため、時間の経過とともに価値の伸びは当然低下する。

顧客の期待の成長は加速する。なぜなら、顧客が問題解決を待つ時間が長ければ長いほど、代替プロダクトに乗り換える時間が増えるからである。そのような顧客を引き留めるには、今欲しいものだけでなく、将来(選択肢がさらに豊富になったとき)にも欲しいものを提供する必要があります。

このフレームワークを140字以内でシンプルに考えるなら、

最低限実現可能なプロダクトの範囲は、出荷に時間がかかればかかるほど大きくなる。

グラフからわかること

出荷の時間価値を適用した場合、MVPはまだ簡単に識別できます(この場合、曲線の接線にあります)。

しかし、いくつかの条件を調整し始めると、グラフはフレームワークの興味深い影響を示唆しています。

第一に、上記の例のように、出荷してユーザーを満足させることができるのは、ある時点(接線)だけかもしれません。

PMとしては、それは怖いですね。

第二に、もしあなたのチームがスケジュールでスリップしたら、こんなことが起こります。

価値曲線全体が下がり、顧客の期待に応えられるだけの価値を提供できなくなるということです。その時点で、2つの行動方針があります。

  • プロジェクトを放棄し、ある時点で顧客の期待に応えられるようなプロジェクトに移行するか、あるいは、
  • より多くのリソースを投入して、価値曲線を無理やり交点に戻す。

この「運命の分かれ目」こそが、ほとんどのプロダクトピボットの根底にあるものです。企業は、その特定の業界のペースではイノベーションを起こせないことに気づき、顧客の期待をより達成しやすいところに移動するのです。

PMとして、それは本当に怖いことです

最後に、常にMVPを出荷するべきではありません(つまり、常に曲線の最初の交差点で出荷すべきではありません)。

その代わり、価値と期待の間の最大スプレッドで出荷することです。

これはMVPの福音に反することですが、出荷の時間価値は、時には(期待に応えていても)発売を控えることが最適であることを示唆しています。

最初の交差点でローンチし、代わりに反復すべきではないでしょうか?

もし、あなたがティッピングポイントを信じるのであれば、発売を延期することは全く合理的です。最高のプロダクトは、顧客のニーズを満たすだけでなく、ユーザーを喜ばせることでバイラルという報酬を得ることができるのです。このことは、発売後のネットワーク効果によって強調され、最初のマーケティングプッシュの後、リターンが減少していくことになります。

PMとしては、それが一番怖いのです。

スタートラインに立つ、もうひとつのレンズ

競争力が曲線にどのように影響するかなど、(簡潔にするために)カバーしなかった興味深いことがたくさんありますが、もしこれを面白いと思う人がいれば、別の投稿に取っておくことにします。

もし、出荷の時間価値という目標がPMにとって現実的な成果であるならば、これは小さな一歩なのです。現実の世界できれいな曲線を描くことは、多くの場合、思い込みの上に成り立っていて、迷走しています。

しかし、これはPMが毎日行っている複雑で多変数の意思決定に、別のレンズを追加することなのです。私たちが直感と呼ぶものの集合体です。

ですから、次にロードマップを計画するときは、顧客が今何を望んでいるかを問うだけでなく、出荷するまでに何を望むかを考えてみてください。

以下は、あなたが気に入るかもしれない他の記事です。

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

7 Heuristics for being a Product Director

Product Partnerships (pt. 1/2)— The Making of a Partnership


Brandon Chuの他の記事を読む👀

👉 Brandon Chu

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

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

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に掲載されています。


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

プロダクトの機会を評価する

最近、私はプロダクトスペックの再発明について、また、プロダクトスペックの基礎として、重量のあるPRDから軽量の高忠実度プロトタイプに移行する理由について書きました。しかし、このようなアイデアはどこから来るのでしょうか。また、そもそもプロダクトを作りたいかどうか、どのように判断するのでしょうか。

*この記事は「Assessing Product Opportunities」を、著者の了承を得て翻訳したものです。
著者: マーティ・ケーガン(Marty Cagan)
翻訳者: 渡辺圭祐

新しいプロダクトを生み出すチャンスは、成熟したマーケットも含め、あらゆるところに存在します。なぜなら、何が可能であるかは常に変化しているからです。常に新しい技術が生まれ、新しい才能を持った人が会社に加わり、競合他社が現れては消えていきます。プロダクトマネージャーは、どれが有望でどれがそうでないか、魅力的に見えるものについては、どれを追求すべきか、どれを他の人に任せるのが最善か、どのアイデアはまだプロダクト化の準備ができていないかを判断するために、素早く機会を評価する能力が必要なのです。

多くの企業では、「このプロダクトはどうしてもやらなければならない」と上から降ってくるだけです。また、マーケティング部門がどのようなプロダクトが必要かを決定する企業もあります。

いずれの場合も、プロダクトを作るかどうかを決めるプロセスが直感に任されていることが多すぎます(もっとひどいのは、大口の顧客が「特別な」資金を提供すると言い出し、それがプロダクト化への取り組みの基礎になることです)。

通常、ビジネスサイドまたはマーケティング担当者は、解決すべき問題を記述することを目的とした何らかの形式のマーケット要求文書(MRD)を作成し、ビジネスの正当性も含めて記述します。MRDの目的は機会を説明することであり、解決策を説明することではありません。少なくとも理論的にはそうです。実際には、多くの企業はMRDを作成しませんし、作成したとしても、それはMRDと呼ばれるプロダクトスペックであることがほとんどです。MRDを作成した場合、PRDと同じような問題が発生します。書くのに時間がかかりすぎ、読まれず、必要な質問に答えられないことがよくあります。

その結果、多くのプロダクトマネジャーがMRDを無視してしまうのです。しかし、何もせず、ただプロダクトに飛びつくことの問題点は、一般的に、飛びつく前に見ることが良いということです。課題は、これを素早く、軽量で、しかも効果的な方法で行うことです。

私は、この「プロダクト機会評価」を、プロダクトマネジャーの極めて重要な責務と考えています。良いプロダクト機会評価の目的は、a) 会社が悪い機会に時間とお金を浪費するのを防ぐこと、b) 良い機会については、成功するために何が必要かを理解すること、のいずれかである。

幸いなことに、有用なプロダクト機会評価を行うことはそれほど難しいことではありません。私はプロダクトマネージャーに10の基本的な質問に答えるようお願いしています。

  1. このプロダクトはどんな問題を解決するのか?(価値提案)
  2. 誰のためにその問題を解決するのか?(ターゲットマーケット)
  3. その機会はどのくらい大きいか?(マーケット規模)
  4. どのような代替案があるのか?(競合状況)
  5. なぜ、私たちはこれを追求するのに最適なのか?(差別化要因)
  6. なぜ今なのか?(マーケットの窓)
  7. このプロダクトをどのように市場に投入するのか?(マーケット参入戦略)
  8. このプロダクトの成功/収益をどのように測定するのか?(測定基準/収益戦略)
  9. 成功のために重要な要素は何か?(ソリューション要件)
  10. 上記を踏まえた上で、おすすめは?(GoかNo-Goか)

答えるのが最も難しい質問は、たいてい最初のものです。しかし、ほとんどのプロダクトマネージャーは、そのプロダクトが解決しようとする問題は何かと尋ねると、解決しようとする問題についての明確で説得力のある説明ではなく、機能や性能のとりとめのないリストが返ってくるのが普通です。

もう一つの難しい問題は、機会の大きさを評価することです。この点については、業界アナリスト、業界団体、財務担当者、そして自分自身のボトムアップの計算から、考えを得ることができます。しかし、今は、保守的に考え、すべての機会が10億ドルのマーケットである必要はないことを認識する必要があります。

「Go-to-market」戦略は、このプロダクトがどのように販売されるかを示すものであり、プロダクト要件に非常に大きな影響を与えるため、特に重要です。

ソリューション要件は、調査中に特定された特別なニーズや要件を指します。ここでも、プロダクトを説明するのではなく、依存関係や制約を明確にします。例えば、システムインテグレーターを通じて販売されるプロダクトであれば、この種のパートナーは、提供するプロダクトの拡張性に関する要件を持っています。同様に、ブランディングやパートナーシップの要件もあります。

プロダクト組織は、良い機会を追求し、優れたプロダクトソリューションを提供することが全てです。新プロダクトを生み出すチャンスはどこにでもあります。プロダクトマネージャーは、新しいチャンスを効果的に評価し、会社にとって最も可能性のあるものを見極めることができることが重要です。また、悪いプロダクトのアイデアを追って多大な時間とコストが失われる前に、この段階で見極めることも同様に重要です。追求すべきプロダクトを正しく選択することは、企業にとって最も重要な決定の一つです。

プロダクト機会評価の結果を上層部に提示し、議論することが重要です。そして、この機会を満たすプロダクトを追求するかどうか、会社として明確にGoかNoかの判断を下すことが必要です。もし、プロダクト開発を進めることになれば、自分が何をしようとしているのか、成功するためには何が必要なのか、より詳しい情報を得ることができます。

では、CEOから「我々はこれをやっているのだから、早くプロダクトに取りかかれ」と言われたら、どうすればいいのでしょうか。まず、プロダクトをやることには戦略的な理由がある場合もあり、マーケットで成功しそうにない場合でもプロダクトを追求する必要がある場合があることを認識してください。とはいえ、このように軽量で迅速なプロダクト機会評価を行うことは、このプロダクトがどのようなものかをより良く知ることができるという点で価値があると私は考えています。しかし、少なくとも、成功するために自分が直面している問題を知ることができるのです。

マーティ・ケーガン

SVPGの創業者兼プロダクト担当パートナー


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


Marty Caganの他の記事を読む👀

👉 Marty Cagan

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

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


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

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

PMは「なぜ存在するのか」と問われると悲しくなる

プロダクトマネジメントの世界には、すべてのPMが経験したことのある通過儀礼があります。

「プロダクトマネージャーって何する人?」

私は、この質問をするデザイナーやエンジニアに共感します。なぜなら、プロダクトマネージャーの活動は断片的であり、真の規律が見えてこないからです。

プロダクトマネジメントを始めた当初は、自分がやっていることすら知りませんでした。それどころか、私は初めての創業者で、「スタートアップをやっている」だけだと思っていました。

その後、PMの仕事の面接を受けたとき、より有能な人たちが、私は実際にプロダクトマネジメントをやっているのだと教えてくれたのです。そして、私はその仕事に就きました。その仕事を始めて間もない頃、私は上記のような悪名高い質問を受けました。私は気分を害することなく、むしろ彼らと同じように興味を持ち、プロダクトマネジメントについて(何度も)読みました。インターネット上では、さまざまなことが言われていました。

  • 私はプロジェクトマネージャーではない。そして、そうだと思われたら、怒るべきである。
  • 私はプロジェクト・マネージャーではないので、「何を」「なぜ」ということを考える必要がある。
  • 私はビジョナリーであるべきだ、顧客の声であるべきだ、ミスター・ゲット・シット・ダン(パッパとやる人)であるべきだ、などなど。

私はそのすべてを吸収しました。最初の数ヶ月は、私のプロダクトマネジメントのバイブルである『Good Product Manager, Bad Product Manager』を毎週のように読み返しました。

そして、何度もプロダクトを出荷しました。そして、すぐに役立つと感じるようになりました。

その仕事を始めて数年後、私は他のプロダクトチームを管理するようになりました。他のPMは私に、彼らがなぜ存在するのかという質問に答えることができるように、それを定義してくれることを期待するようになりました。私は、これまで読んだ最高の投稿のカクテルと、長年にわたって経験した例を提供しました。

私は現在Shopifyにおり、3つ目のプロダクトマネージャーの役割を担っていますが、改めて自分が本当にやっていることは何なのか、前提を見直すことになりました。Shopifyは真のエンジニアリング文化であり、会社の規模に比してプロダクトマネージャーは非常に少数です。ちなみに、私が以前勤めていた会社では、PMと社員の比率は1:10でした。Shopifyは(ディレクターも含めて)1:80に近いです。

私が入社した最初の週に、あるエンジニアから「あの質問」をされました。

ここで働いていてよかったと思うことのひとつは、プロダクトをいかに効率的に構築し出荷するかという、別のアプローチを観察することができたことです。Shopifyのエンジニアやデザイナーは、非常に才能があり、意見がはっきりしていて、自立しています。

また、変えてはいけないものを見つけ出し、そうすることで「なぜ」を優先し、「何」を抽象化することを余儀なくされました。この記事はShopifyについてでもなく、効果的なプロダクトマネージャーになるための方法についてでもありません。なぜプロダクトマネージメントが存在するのかについてです。

▼本記事の内容
  1. なぜプロダクトマネジメントなのか
  2. スピード
  3. スケール
  4. カオスのカクテル
  5. なぜプロダクトマネージャーなのか
  6. 良いプロダクトを開発するのは難しい
  7. プロダクトマネージャーは複合的である
  8. なぜブラックボックスは存在し続けるのか

*この記事は、The Black Box of Product Managementを著者の了解を得た上で翻訳したものです。

著者: Brandon Chu
翻訳者: 渡辺圭祐

なぜプロダクトマネジメントなのか

プロダクトマネジメントは、企業にとって2つの指数関数的な力が作用した副産物です。

スピード: 技術革新のスピードが加速している業界に存在する企業。
スケール: プロダクト、組織、顧客の成長により、複雑性が増している。

スピードは指数関数的な力であり、一定期間ごとに、前回よりも多くの変化が起きている。スケールについても同様で、機能、従業員、ユーザーが増えるたびに、前よりも複雑さが増していきます。

プロダクトマネジメントという職業が主にソフトウェア会社で普及してきたのは、ソフトウェアが本質的にスピードとスケーラビリティの点において優れているからです。

スピード

インターネットは、ソフトウェア製品を市場に送り出す方法を変えました。毎年リリースされ、段ボール箱が棚に並んでいた時代はとうに過ぎ去りました。この20年間、チームはコードを書き、それを配備し、すべての顧客に即座にアップデートを提供してきました。

ソフトウェア開発そのものへの参入障壁が低くなったのです。高度なプログラミング言語が持つ親しみやすさと、オープンソースライブラリの普及により、開発者はかつてないほどの生産性を手に入れました。同時に、機能的なプロダクトを構築し、それを配備するためのインフラコストは、基本的にゼロになりました。

つまり、世の中のあらゆる大きな問題は、何百もの独立したチームがその解決に取り組んでいる可能性が高いのです。

このように、スピードには2つの意味があります。ソフトウェア開発で何かを市場に投入する速さと、(重要なことですが)企業が生き残るためにいかに速くすることを競争によって強いられるかということです。

スケール

50人以下のスタートアップがプロダクトマネージャーをほとんど持たない理由は、その複雑さがまだ管理可能であるからです。CEOと共同創業者は、集中した問題に向けて会社を調整し、スクラップなスタートアップの力をその問題に解放することができるのです。

しかし、会社が成長するにつれ、機能が追加され、顧客が多様化し、チームが大きくなるにつれて、複雑さが出てきます。そして、その複雑さは指数関数的に大きくなっていきます。

例えば、20人のスタートアップがどれだけのミーティングを行えると思いますか?

その答えは、なぜ私たちが指数関数的な概念を苦手としているのかを示しています。

会社が解決する問題も同様に複雑さを増していきます。チームが高度な問題を解決すると、何百もの派生的な問題が生まれ、そのすべてが解決されることを待ち望んでいます。しかし、会社はそのすべてを解決することはできません。何百もの解決すべき問題に直面したとき、どこに焦点を当てるかは、企業にとって最も重要な決定となります。

カオスのカクテル

スピードとスケールが同時に企業に与える影響を考えると、企業の全体像を考える人がいなければ、最終的に物事が脱線してしまうことは容易に想像がつくでしょう。最終的にその役割を担うのはCEOですが、CEOがマルチタスクの限界に達したとき、他の誰がその穴を埋められるでしょうか?

なぜプロダクトマネージャーなのか

確かに、プロダクトにはある程度の管理が必要です。では、なぜプロダクトを管理できるように全員を訓練するのではなく、特定の役割を担う人を採用するのでしょうか。

簡単に言うと、プロダクトを管理するのは想像以上に難しく、できるようになるには長年の経験が必要だからです。長い答えはこうです。

良いプロダクトを開発するのは難しい

プロダクトマネージャーのコアコンピテンシーは、プロダクト開発を真に理解することです。つまり、どのような問題を解決すべきかを見極め、それを解決するためにどのようにチームと協働するかということです。

何度か立ち上げを経験した人なら、教科書とは裏腹に、以下のような直線的なプロダクト開発プロセスがおとぎ話であることを知っています。

たとえ、各ステップ間にフィードバックループを設けたとしても、機能チームがチェックリストを通じて協力し合うという、整然とした連続したステップという考え方は欠陥があります。テクノロジーが指数関数的に進歩する世界には、単純にそぐわないのです。

世の中の変化が速すぎて、3カ月前のリサーチ結果を元に開発することはできません。

私は、現代のプロダクト開発は、ユーザーの要望を実現するために、相互に関連する分野がネットワークで連携したシステムであると考えます。プロダクトマネージャーは、このネットワークにおけるコミュニケーションを促進するAPIです。

各ノードは、専門分野の幅広いバケットを表し、それぞれが、それを習得するために人々がキャリアを捧げるほどの深みを備えています。これは、スピードとスケールがクリティカルマスに達した企業におけるプロダクト開発の重要な品質です。あまりにも多くのことを知らなければならないので、あるチームだけが効果的にプロダクトを提供することができたのです。

プロダクト開発のプロセスは、このシステムが時間軸の中でどのように動くかを示すものです。

プロダクトマネージャーは、問題の特定からプロダクトの発売まで、このシステムの指揮を執り、ネットワーク内の各ノードが他のノードの進捗を認識し、ユーザーが開発中のプロダクトをますます欲しくなるようにします。

最後に、組織の規模が大きくなると、複数のチームが必要になります。そして、効果的なプロダクト開発システムは、それらのチームを調整し、企業のビジョンに焦点を当てます。

プロダクト開発のAPIとして、プロダクトマネージャーは、重複する作業を排除し、他のチームがより速く開発できるようにインフラを共有することで、会社全体の効率化をサポートします。

プロダクトマネージャーは複合的である

プロダクトマネージャーは、このシステムの責任者として必要なスキルを身につけるために何年も費やします。複合的で、深さよりも広さを重視した学習方法です。

私はこれまで、プログラミング、UIデザイン、UXリサーチ、ファイナンシャル・モデリング、ビジネス開発、サポート、コピーライティング、会計、法務、契約交渉、レポート、マーケティング、ブログ記事、FAQ、プロダクトコピーなど、あらゆることをやってきました。

どの分野もエキスパートにはなれなかったし、いくつかの分野では境界線上の能力を獲得しました。APIとして役に立つだけの知識はあっても、(良い意味で)危険な知識はありませんでした。これこそがプロダクトマネージャーのスキルセットの真骨頂であり、開発者タイプの人々にとってPMがもたらす価値を正確に理解することを難しくしています。

PMは、プロダクト開発システム全体に責任を持つために、各分野についてただ十分であるというレベルで知識を備えています。

PMは、各分野に精通し、プロダクト開発システム全体に責任を持つことができるため、チーム全体に効果的に情報を伝達するために必要なあらゆる言語でコミュニケーションすることができます。

また、システム全体における変化の影響を評価する上でも、最適な立場にあります。最近、ShopifyのCEOと交わした会話で、彼はこのことを非常に簡潔に表現していました。

「優れたプロダクト担当者は、世の中の仕組みの変化がログファイルにどのような影響を与えるかを理解しています。そして、彼らはその影響をリアルタイムで察知することができるのです。」
トビ・リュトケ (言い直されています)

まさにその通りです。

スピードがキングであり、世界が指数関数的に変化している世界では、行動の前に合意を形成する時間を持つことは、しばしば贅沢なことなのです。チームはスピードを維持するために日々重要な決定を下す必要があり、それらの決定には大きなトレードオフや利害関係者間の対立があります。

そのような意思決定を推進するのは、プロダクトマネージャー以外の誰の仕事でもないのです。

なぜブラックボックスは存在し続けるのか

エンジニアやデザイナーの仕事は、PMの影響を短期的に観察することが難しいため、定量化しやすいのですが、プロダクトマネジメントにまつわる曖昧さは、しばらく残ります。

いつか、大学院で学位を取得し、プロダクトマネジメントへの明確なキャリアパスができるかもしれませんが、今はまだそうではありません。それまでは、企業の規模は拡大し続け、世界はより速くなり続け、遅かれ早かれ「これを管理する人が必要だ」と提案されることになるでしょう。

もしあなたがPMなら、次に誰かがあなたの存在に異議を唱えたとしても、腹を立てないでください。曖昧さを受け入れ(結局、あなたはPMなのですから)、自分の目的に自信を持ってください。

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

そういえば、Shopifyは採用活動をしています。

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

7 Heuristics for being a Product Director (プロダクトディレクターになるための7つのヒューリスティック)

Product Partnerships (pt. 1/2)— The Making of a Partnership (プロダクト・パートナーシップ (pt. 1/2) – パートナーシップの成り立ち)

The Time Value of Shipping (配送の時間的価値)

#SWLH (Startups, Wanderlust, and Life Hacking)」に掲載されました。


Brandon Chuの他の記事を読む👀

👉 Brandon Chu

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

プロダクト開発の見方を変える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人のブロガーが「いいね」をつけました。