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

*この記事は、The Black Box of Product Managementを翻訳したものです。

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

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

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

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

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

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

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

• 私はプロジェクトマネージャーではない。そして、そうだと思われたら、怒るべきである。

• 私はプロジェクト・マネージャーではないので、「何を」「なぜ」ということを考える必要がある。

• 私はビジョナリーであるべきだ、顧客の声であるべきだ、ミスター・ゲット・シット・ダン(パッパとやる人)であるべきだ、などなど。

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

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

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

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

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

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

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

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

プロダクトマネジメントは、企業にとって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)」に掲載されました。

オリジナル記事はこちらからご覧ください。
プロダクトマネジメントのブラックボックス