第7章：プロダクトマネージャーを管理する
会社の核となるチームを作り上げる
私は、長いこと、プロダクトマネージャーには高い水準を要求しよう、と主張してきた。というのは、プロダクトマネージャーが、製品開発の成功、そして事業の成功の決め手となるからだ。ところが、プロダクトマネージャーを管理する人たちの話では、プロダクトマネージャーという肩書きの人間の多くが、実はプロダクトマーケティング畑の人たちである、という状態がずっと続いているらしい。プロダクトマネージャーを名乗る人たちは、これまでの章で述べてきたようなさまざまな問題を抱えていて、これをどうにかしようともがいている。
そこで、この章では、プロダクトマネージャーを管理する立場にある人の役割と責任について議論したい。
プロダクトマネージャーを管理する人は、通常、プロダクトマネジメント部門のディレクターとか VP (ヴァイスプレジデント) という肩書きを与えられる。この仕事は、ハイテク企業ではいちばん重要なポジションの 1つである。プロダクトマネジメント部門のリーダーほど、会社の将来に影響を与える職務はほとんどない。ある製品の成功が文字どおり会社の将来を決めることもあれば、ある製品の失敗が会社を傾けることもある。というわけで、普通は、プロダクトマネジメントには大成功か大失敗のどちらかしかなく、その中間はないと言っていい。
プロダクトマネジメント部門のリーダーは、2つの重要な責任を負っている。強力なプロダクトマネージャーのチームを率いる責任と、会社全体の製品戦略や会社の製品ラインに対する責任である。そこで、それぞれについて順番に議論していこう。
プロダクトマネジメントチームを組織する
部門長やチームリーダーが第一にやるべきことは、自分が率いる部門やチームの能力を高めて発展させていくことである。プロダクトマネジメント部門のリーダーにとっては、この任務はことのほか重要だ。それは、プロダクトマネージャーというものが、大きな影響力を持つ存在であるからだ。プロダクトマネージャーが実力不足であれば、売れる製品を作るのはまず無理で、製品サイクルは無駄となり、ユーザーをイライラさせ、顧客を失うこととなる。社内の業務の多くは、できの悪い人がやっても他のだれかに穴埋めしてもらえるので、平均以下の社員という烙印を押されるぐらいで済む。でも、プロダクトマネージャーの場合、各製品に 1人しかいないので、まずそうはならない。プロダクトマネージャーに十分な実力がない場合は、製品開発チームのだれか別の人 (たぶん、主任エンジニア) がプロダクトマネージャーの代わりに必要なことをやってくれるのを期待するしかない。
みなさんがプロダクトマネージャーを管理する立場にあり、その中に職務を全うできない人がいるならば、すぐにどうにかしなければいけない。プロダクトマネージャーとして成功するのはまず無理、というタイプの人もいる。そういう人はとにかくプロダクトマネージャーには向いていないので、どんなに訓練や指導を受けたところで変わらないだろう。でも、これまでの実例からは、実際には、多くのプロダクトマネージャーについて、その能力をすさまじく向上させることができそうだということもわかっている。これは虫のいい話でもなんでもない。というのは、私は、多くの時間を費やして、さまざまな会社が社内のプロダクトマネージャーの能力を向上させるのを手伝っているが、能力が上がるのは紛れもない事実だ。どっちにしても、プロダクトマネジメント部門のリーダーは、プロダクトマネージャー全員が仕事をきちんとこなせるレベルになれるようにしなければならない。
新米のプロダクトマネージャーは全員、実際の製品開発を任せられるまでに、3ヶ月程度は猛勉強する必要があると思う。この期間、新米プロダクトマネージャーは、ターゲットとなるユーザーや顧客を知ることに没頭し、関連技術について叩き込まれ、市場や競争の見通しについて勉強する。プロダクトマネジメント部門のリーダーは、その過程で、彼らの勉強を手助けし、進み具合を監督していなければならない。この勉強は、彼らが既にプロダクトマネージャーとしての実際のスキルや役割について十分理解していることを前提としている。また、この 3ヶ月研修は、経験のあるプロダクトマネージャーにも受けさせるとよい。彼らも、会社独自の顧客や事業領域について学ばなければならないからだ。
プロダクトマネージャーを新たに採用したら、ユーザーと接して技術を説明できるレベルになってもらうための研修プログラムを準備するべきだ。すでに配下にいるプロダクトマネージャーや製品開発を担当中のプロダクトマネージャーには、もしユーザーについての理解が追いついていないならば、担当中の業務と並行して、こうしたプログラムに参加させるようにしよう。その場合は、プロダクトマネージャーとしてもっとレベルアップしなければならない状態であることを、きちんと自覚させなければならない。
どういうレベルの業務にせよ、プロダクトマネージャーにそれをこなす力がない、あるいはやる気がないと判断した場合は、代わりの人間を探すのは上司であるリーダーの仕事である。だれかを首にした経験のある人なら、これがちっとも楽しい仕事でないことはおわかりだろう。でも、だからこそ、リーダーには他の人より高い報酬が支払われているのであり、チームの他のメンバー、会社、そして顧客に対してその報酬に見合った働きをして状況を改善する義務を負っているのだ。プロダクトマネージャーから外された人のためには、その人が輝ける仕事を見つけられるように、できるだけのことをしてあげよう。でも、必要な仕事をこなせる適材を適所に配置する、という任務を片時も忘れてはならない。
プロダクトマネジメントチームに成功に必要な能力と技能を兼ね備えた人材が揃った、と判断したら、今度は一歩下がって、才能豊かな彼らに仕事を任せる必要がある。プロダクトマネージャーの仕事ぶりをいちいち細かく管理してしまうと、彼らが成長する機会を奪ってしまい、彼らが主体的に仕事に取り組むようになることは望めなくなるだろう。もし、部下のプロダクトマネージャーを信頼できないなら、信頼できる人間を見つけなければならない。これは、なにも、口出しするなとか、いつでも手助けできるような態勢でいるのはよくない、などと言っているのではない。それどころか、そうすべきときは、そうしなければならない。でも、有能な人に権限を与えて仕事を任せれば、必ずや彼らが期待以上の仕事をしてくれることに舌を巻くだろう。
ただ、権限を与える前に、まず、権限を与えても大丈夫なだけの実力があることを確認しなければならない。実力のない人に権限を与えてしまうと、それは管理職であるリーダーとしての責任を放棄したことになる。そして、実力不足のマネージャーの仕事を細かく管理することになったとすれば、要するにそれは彼らの仕事を肩代わりしているということだ。
できるリーダーはみんな、いちばんかっこよく見えるのは自分の部下が輝いていることだ、と心得ている。だから、いつも自分よりも頭がよさそうな人を採用して、彼らが成果を出せるようにできる限りのことをしよう。
会社の製品戦略を決める
プロダクトマネジメント部門のリーダーほど、会社のあらゆる製品について責任を負い、説明を求められる人間は他にいない。この役目を仰せつかっている人は、どの製品の開発を進めるかを決め、それぞれの製品の戦略と開発の進み具合をしっかりチェックする。
プロダクトマネジメント部門のリーダーは、最新の会社の事業戦略を深く理解していなければならない。それがあってこそ、事業戦略に沿った製品戦略を立てることができる。また、このリーダーは、製品開発のビジョンを打ち立て、このビジョンに沿ってプロジェクトを進めるようにプロダクトマネージャーと協力する上で、指導的な役割を果たす。この製品開発の原則 (第13章「製品開発の原則」を参照のこと) は、通常、プロダクトマネジメント部門によって作られるが、部門のリーダーはこれを主導し、製品ができるかぎりこの原則に沿ったものとなるように努力するのだ。
最高のプロダクトマネジメント部門があり、それぞれのマネージャーいい仕事をしているとしても、製品同士で利害が対立することがある。というのは、プロダクトマネージャーは、それぞれ自分の担当する製品を最高のものにしようとがんばるからだ。そこで、部門のリーダーは、こうした製品間にまたがる問題を見つけて、解決するように努力しなければならない。
また、プロダクトマネジメント部門のリーダーは、製品ラインのロードマップに対しても責任を負う。つまり、計画中の複数の製品発売の全体像を把握し、事業の課題や顧客への影響を検討しなければならない。
最後に、プロダクトマネジメント部門のリーダーは、経営陣ともうまく連携する必要がある。社内のえらい人全員、特に CEO とは、良好な信頼関係が不可欠である。会社全体がプロダクトマネジメント部門のリーダーの肩にかかっているので、さまざまな決定や理由付けについては、オープンで透明であることを求められるし、あらゆる人にとって身近で近づきやすい存在でなければならない。また、あっちこっちから出てくるアイデアを受け入れる柔軟さをもつ一方で、優先順位がぶつかったりぼやけたりしたときには拒否しても納得してもらえるぐらいに、一目置かれている人でなければならない。
ここまで読んでおわかりかと思うが、これは本当に難しい仕事である。でも、世の中に優れた製品を届けている企業では、必ずプロダクトマネジメント部門にすばらしいリーダーを抱えている。これは決して偶然ではない。
コラム１
プロダクトマネージャーをどうやって評価するか？
どうやってプロダクトマネージャーを評価すればいいのか、とよく聞かれる。私は、ずっと、製品開発の成果だけが確実な評価基準であると信じていた。今でもそう思っているのだが、これはあまり満足できる答えにはなっていない。製品開発の成果を評価するベストな方法とは何か、となったとき、これがはっきりしないからである。売上？ 利益？ ユーザー数？ それともページビュー？ こうした指標はすべて大事だけれど、プロダクトマネージャーの成果をきちんと評価するために必要な全体像を示してはいない。
最近、ビジネスにおける新たな測定基準が、多くの業界で注目を集めている。ネットプロモータースコア (NPS) だ。これは非常にシンプルな基準だが、詳しいことについては http://www.netpromoter.com を見てほしい。
その仕組みはこうだ。製品を買ってくれた人に、それを他の人に勧めようと思うかどうかを 10点満点で評価してもらう。9～10点をつけた人は、「推奨者 (プロモーター)」とされる。 (こういう人は、あっちこっちで、どんなにその製品が気に入っているかを友人たちに語り、そのすばらしさを説いて回ってくれる。) 7～8点をつけた人は、勧めることにそれほど熱心ではないか、推奨も批判もしない立場だ。0～6点をつけた人、つまり「批判者」は、製品を勧めてくれないばかりか、友達や不特定多数の人に対して、買うのはやめておけ、とわざわざ忠告までするかもしれない。推奨者のパーセンテージから批判者のパーセンテージを引き算すると、NPS が得られる。これで、製品を支持してくれる人とそうでない人とでは、どちらが多いかがわかる。
かなりの数の会社が、すでに NPS を導入している。そして、かなりいい数字を出しているのは、驚くこともないだろうが、Apple、Amazon、Google、eBay といった会社だ。
私はこの基準がものすごく気に入っている。製品や顧客経験価値 (カスタマーエクスペリエンス) に焦点を当てているからだ。IT業界でよく言われるように、すべては顧客を幸せにすることにあるのだとすれば、この基準はまさにぴったりだ。そう、理論的には 100% の顧客を幸せにすることができる。でも、実際にそんなことをしようとしたら、すべての顧客からそっぼを向かれて、損を出し、結局はそのビジネスから撤退することになるだろう。でも、単独で使う基準としては、NPS のいいところは、NPS を意識することで会社が顧客を幸せにすることに集中するようになる点だと思う。これは、成長のための動機付けにもなるだろう。収益性という点では、いちばん費用対効果が高い販売・マーケティングとは、製品を買った人が自分から営業とマーケティングをやってくれることだ。優れた製品というのは、顧客を幸せにすることで、こういうコスト (時としてかなり大きなコスト) の負担まで軽くして、収益をよくすることにも貢献してくれるものだ。
この評価基準のもう 1つのいいところは、いい売上と悪い売上という発想につながることだ。たとえば、大手のスポンサー候補や広告パートナーの候補が、あなたの会社が抱えるユーザーに食指を動かしてきたとしよう。そして、あなたのサイトをうまく使えば自分たちの製品が売れるだろうと考えて、アプローチしてきた。これがいい方に転ぶか悪い方に転ぶかは、どうやるか次第だ。
下手にやれば、短期的な売上はよくても、顧客経験価値を損ねるようなやり方をした場合、それは NPS に表れて、ビジネスとしての成長を鈍らせることになるだろう。逆に、たとえば広告パートナーと協力するなどの形でうまくやることができれば、顧客経験価値には影響を与えずに済むか、あるいは、むしろ向上させる一因となるかもしれない。そうすれば、ビジネスはもっと早く成長するだろう。
だから、特注品 (特定の顧客向けの製品のことで、だいたいは、製品の購入を確約してもらう見返りとして、特別仕様の仕事を引き受ける) に走るのはかなり危険だ。これは悪い売上の典型であり、会社がユーザーを幸せにする製品を作り出す力をダメにする。
会社別、業界別で NPS を比較するのもおもしろいだろう。でも、NPS がいちばん役に立つのは、自社の製品やサービスの改善がどのぐらい進んでいるかを測る場合だ。もしまだ自分の担当する製品で NPS を測定していないなら、すぐにでもやることを検討してほしい。そうすれば、製品に変更を加えると、 NPS のスコアにどう影響するかの観察を始めることができる。 そして、常に正しい方向に向かっていることを確かめながら、自分たちがやることすべてが NPS にどう表れるかを考えてほしい。
コラム２
プロダクトマネジメントの居場所はどこがいい？
多くの会社は、社内組織上、プロダクトマネジメントの機能をどこに置こうかと頭を抱えている。ほとんどの場合、エンジニアリング部門に置くか、マーケティング部門に置くか、という話のようだ。もしぴったりの人材がいるなら、どっちでも大丈夫だろう。でも、実は、私はどちらにも賛成ではない。
私が仕事をした会社でいちばん多かったのは、マーケティング部門の中にプロダクトマネジメントがあるパターンだ。この組織体系でまずいのは、製品は顧客と話すことから生まれるもので、そのために顧客と話すのはマーケティング部門の仕事だ、という間違った考え方に基づいている点だ。この考え方のどこがまずいかをすべてここで繰り返すつもりはない。ここでは、顧客の意見を聞いただけでは売れそうな製品を見つけ出すことができない、そして、それには重要な理由がいくつかある、とだけ言っておけば十分だろう。また、この組織で問題なのは、マーケティング部門の中で、プロダクトマーケティングの役割とプロダクトマネジメントの役割がいっしょくたにされてしまうことがよく起こる、という現実である。これらはまったく違う役割だし、その役割をこなすのに必要なスキルもまったく違っているので、たいていの場合、どちらかの役割 (あるいはその両方) がおろそかになってしまうという結果になる。
私が見た中で次に多かったのが、プロダクトマネジメントがエンジニアリング部門にあるというパターンだ。この場合、実際に製品を作る人たちの隣にその製品を考えてデザインする人を配置できるのは結構なのだが、やはり問題が出てくる可能性がある。なぜか？ エンジニアリング部門というのは、基本的に、正しい製品を作ることではなく、製品を正しく作ることに専念することになっているからだ。プロダクトマネジメントチームにとっては、市場機会を分析したり、勝てる製品戦略や製品ロードマップを見つけたりすることではなく、詳細な仕様を作るという細々とした作業やそのプレッシャーの中で消耗されることになりがちだ。作るべき正しい製品の着想を得るためには、エンジニアリングとは別の物の見方や別のスキルが必要だ。さらに、エンジニアリングというのは、本質的に実行に力点を置く作業なので、実行のために最適化された組織の中で着想のための作業をするのはしんどいかもしれない。
では、マーケティング部門でもエンジニアリング部門でもないとしたら、どこなのか？
製品開発部門は、社内組織上、エンジニアリング部門やマーケティング部門と同じレベルに格上げするべき、と私は強く主張する。理想的なのは、その上で、製品開発部門の中にデザインチームも入れることだ。というのは、プロダクトマネジメントとユーザーエクスペリエンスデザインとの協力関係はできるだけ緊密でなければならないからだ。今後ますます、「プロダクト」、「プロダクトマネジメント」、「プロダクトマネジメント＆デザイン」といった名称の部門ともに、プロダクト担当VP (バイスプレジデント) やチーフプロダクトオフィサーといった肩書を目にするようになるだろう。
この組織体系にはいくつかのメリットがあるが、中でもいちばん大きいのは、製品開発のトップが経営幹部の会議に出席する義務があるということだ。会社にとっては製品がすべてであり、マーケティングもエンジニアリングも独自の検討事項や課題を抱えている重要な部門だが、製品開発の組織はこうした課題の狭間で埋没しがちなのだ。その他にも、この組織体系にすると、製品にとっては技術が決め手になるわけではないことや、販売やマーケティングのニーズだけで決まるのでもないことが明確になる。
ただ、多くの大企業に関しては、1つ例外がある。大きい会社では、エンジニアリング機能は本社に置かれ、一方で、各事業部門は、自立的、独立的に運営されていることが多い。こうすることで、会社は、エンジニアリング業務については共通化することで効率よく進める一方で、複数の事業のそれぞれにじっくり取り組むことができる。こういう組織の場合、プロダクトマネジメントとデザインの機能は、本社のエンジニアリング部門や製品開発部門に置くこともできるし、独立した組織として本社に置くこともできるし、あるいは、それぞれの事業部門の一部として設置することもできる。このような組織では、事業部門のトップは、プロダクトマネジメントで中心的な役割を果たさなければならないことがある。でも、プロダクトマネジメントチームがその事業部門の中に置かれていない場合は、ちょっと厄介だろう。こうした大企業の場合は、私は、プロダクトマネジメントとデザインを統合した組織をそれぞれの事業部門の中に置くやり方がいちばんいいと思う。
ここまで、組織上のプロダクトマネジメントの位置づけについての理想的な姿を説明してきたが、社内の組織体系を変えるのはすさまじく困難かもしれないし、会社がそういうことはしたがらないかもしれないし、あるいは、それ以前にできないのかもしれない。だからといって、必ずしもこの問題からは逃れられない運命にあるとは限らない。結局は、製品開発に関わる人たちとそのスキルの問題に行き着くからだ。プロダクトマネージャーとしては、製品開発チームのスキルを高めて、その価値を社内全体に示すことができれば、どういう組織体系でも製品開発を成功させることができるだろう。
参考事例
製品戦略、製品ロードマップ、およびポートフォリオロードマップのサンプルは、次のウェブページで閲覧できる。
www.svpg.com/examples
Inspired日本語版 