[翻訳] プロダクトCEOのパラドックス
a16z ベン・ホロウィッツが2013年に書いたプロダクト志向の創業者へ向けたエッセイ「Why Founders Fail: The Product CEO Paradox」の翻訳記事とこれを読んだ自分の考察を文末に記しています。この記事は何年か前に一度流し読みしていましたが、今の自分にとって示唆深いものでした。以下の連続ツイートでも触れています。
(翻訳始)
私は創業者が自分の会社を経営することに対して強く支持しているため、創業者がスケールアップに失敗したり、プロのCEOに交代したりすると、多くの人が私にたくさんのメールを送ってきます。
これらのメールに答えはこうです。
いいえ、あの記事を書き直すつもりはありませんが、この記事は書きます。創業者が 自分の作った会社の経営に失敗する理由は、大きく分けて3つあります。
- 創業者は本当はCEOになりたいとは思っていません。すべての発明家が会社を経営したいと思っているわけではありませんし、本気でCEOになりたいと思っていなければ、成功のチャンスは例外的に低くなります。CEOのスキルセットを習得するのは非常に難しいので、そうしたいという強い願望がなければ、創業者は失敗するでしょう。もしあなたが「CEOになりたくない創業者」であれば、それはそれで構いませんが、早めにそのことを理解して、あなた自身や他の人たちの苦痛を減らすべきです。
- 取締役会がパニックになります。創業者がCEOになることを望んでいても、取締役会が彼・彼女のミスを見てパニックになり、早々に交代させてしまうことがあります。これは悲劇的なことですが、よくあることです。
- 3つ目がプロダクトCEOのパラドックスです。多くの創業者は、プロダクトCEOのパラドックスにぶつかります。
プロダクトCEOのパラドックス
私の友人は、自分のプロダクトビジョンを徹底的に追求することで、会社を無一文から記録的な速さで10億ドル以上の収益を上げるまでに導きました。彼は、自分の会社のプロダクトの企画と実行の複雑な細部に深く関与することでそれを実現しました。これは、従業員500人程度までは見事に成功しました。
しかし、会社の規模が大きくなるにつれ、事態は悪化していきました。彼は、複雑化していくプロダクト群の一貫性と背景を維持する先見性のあるプロダクト創始者から、恣意的に見える意思決定者、そしてプロダクトのボトルネックになってしまったのです。
これが社員の不満となり、開発を遅らせました。この問題に対処し、会社の規模を拡大するために、彼は手を引き、プロダクトの主要な決定と方向性をすべてチームに委ね始めました。
結果として、彼は「プロダクトCEOのパラドックス」にぶつかったのです。プロダクトCEOがプロダクトに強く関与するよりも早く会社を破壊する唯一のことは、プロダクトCEOがプロダクトに関与しなくなることです。
これはよくあることです。ある創業者が画期的なアイデアを思いつき、それを実現するために会社を設立します。アイデアの発案者である彼女は、そのアイデアを実現するためにたゆまぬ努力を続け、プロダクトの細部にまで関与して、その実行がビジョンに合致していることを確認します。
プロダクトは成功し、会社は成長します。しかし、ある時、社員から「CEOは自分がいなくても社員がうまくやれることに気を配りすぎていて、会社の他の部分に気を配っていない」という不満が出てきます。すると取締役会やCEOコーチは、創業者に "社員を信頼して任せるように "とアドバイスします。
そして、プロダクトは集中力を失い、ラクダ（委員会が作った馬）のようになっていきます。そうこうしているうちに、CEOはプロダクトでしか世界に通用しないことが判明し、プロダクト重視の優秀なCEOから、汎用性のあるしょぼいCEOに事実上変身してしまったことに気づきます。どうやら新しいCEOが必要なようです。
それを防ぐにはどうしたらいいでしょうか？プロダクト志向の優れた創業者やCEOのほとんどは、キャリアを通じてプロダクトに関わり続けることがわかっています。
- ビル・ゲイツは引退するまでマイクロソフトのプロダクトレビューに毎回参加していました。
- ラリー・エリソンは今でもオラクルでプロダクト戦略を担当しています。
- スティーブ・ジョブズは、アップル社で重要なプロダクトの方向性を決めるたびに意見を述べていました。
- Facebookでは、マーク・ザッカーバーグがプロダクトの方向性を決定しています。
彼らはどのようにして、会社を破壊することなくそれを実現しているのでしょうか。
彼らは何年にもわたって、個々のプロダクト決定への関与の度合いを減らしてきましたが、本質的な関与は維持してきました。プロダクト志向のCEOの本質的な関与とは、少なくとも次のような活動を指します。
- プロダクトのビジョンを維持し、推進する。CEOがすべてのプロダクトビジョンを作成する必要はありませんが、プロダクト志向のCEOは、自分が選んだビジョンを推進しなければなりません。彼女は、何をすべきかを見極め、それを正しく伝えることができる立場にある唯一の人物です。
- 品質基準を維持する。どの程度の品質であれば、十分なプロダクトと言えるのでしょうか？これは非常に難しい質問ですが、一貫して文化の一部となっていなければなりません。スティーブ・ジョブズがアップル社を経営していたときには、この点を正しく実行することの重要性を容易に理解することができました。スティーブ・ジョブズは、「信じられないほどの顧客ロイヤルティを生み出す基準」を推進しました。
- 統合者となる。GoogleのCEOに就任したラリー・ペイジは、すべてのプロダクトグループに共通のユーザープロファイルと共有パラダイムの策定を強要することに膨大な時間を費やしました。なぜか？それは、彼がそうしなければならなかったからです。CEOがやらなければ、絶対に実現しなかったことなのです。他の誰にとっても最優先事項ではなかったのです。
- 自分たちが持っていないデータを検討させる。今日の世界では、プロダクトチームは自分たちが作ったプロダクトに関する前例のない一連のデータにアクセスできます。プロダクトチームに任せれば、彼らは自分たちが持っているデータに基づいてプロダクトを最適化するでしょう。しかし、自分たちが持っていないデータはどうでしょうか？お客様が想像できないようなプロダクトや機能を作らなければならないとしたら？誰がそれを優先させるのでしょうか？CEOです。
しかし、そのプロダクトにずっと深いレベルで関わってきた人が、どうやってそれだけをするのでしょうか？ある分野ではまったく手を引くことなく、一般的には潔く手を引くにはどうすればよいのでしょうか？
ある時点で、プロダクトへの関わり方を正式に構築する必要があります。これまでの親密な関わり方から、チームの力を削ぐことなく、またチームを混乱させることなく貢献できるプロセスに移行しなければなりません。具体的なプロセスは、あなた自身、あなたの強み、ワークスタイル、そして個性によって異なりますが、通常は次のような要素が役立ちます。
- 書く。言わない。プロダクトに求めるものがあれば、それを完全に書き出します。簡単なメールではなく、正式な文書にしましょう。そうすることで、より明確になり、自分が関与するのは考え抜いたことだけに限定されます。
- プロダクトレビューを公式化し、参加する。チームが、ビジョンとの一貫性、デザインの質、統合目標に対する進捗状況などをチェックする定期的なレビューを期待していることを知っていれば、廊下で方向性を変えられたときよりも、はるかに無力感を感じずに済むでしょう。
- 正式なメカニズム以外で方向性を伝えるのはやめましょう。個々のエンジニアやプロダクトマネージャーとその場しのぎで話をするのは構いませんし、必要なことです。なぜなら、あなたは現状の理解を常に更新する必要があるからです。しかし、このような場面では、すぐに指示を出そうとしないでください。上述のような正式なコミュニケーションの場でのみ指示を出すようにしてください。
本質的でない関与から手を引きつつ、必要とされる場所に関与し続けることは本当に難しいことです。多くの人はここで自滅してしまうのです。もしあなたが、私の友人のように、完全に手放すことなく、少しだけ手放すことができないという状況に陥っているのであれば、おそらくCEOの交代を検討すべきでしょう。でも、そんなことはしないでください。そのための方法を学びましょう。
( 翻訳終 )
考察
この記事の趣旨を端的にまとめるならば、プロダクトへの影響を弱めるな、という一言に尽きます。しかし影響の与え方はフェーズによって明確に変わる必要があり、どのように変えるか(How)についての答えは明示されていません。それは各CEOの中にあるからです。
しかしバトンタッチを機に自分がプロダクトへの影響を弱めたとは考えていませんでした。むしろより影響の大きな部分にフォーカスし、プロダクト価値のレバレッジを高めていくことになると考えていました。
10Xの事業において、プロダクト開発以上にプロダクトへの影響度が高いHow、それが「どのパートナーと、何を目的に、どのように提携するか」を司るBizDevや、プロダクトやBizDevを実行する「チーム体験の向上 = Employee Success(ES)」でした。これは振り返ると適切なタイミングで進められたのではないかなと感じています。
BizDevチームが組成されたことで、10Xがタップできる機会は飛躍的に増え、それによってさらなる事業機会・新たな事業機会が会社にフィードバックされるようになりました。これらが新規事業や中長期のストラテジーを組み立てる上で最も重要なソースになっています。
ESチームが組成されたことで、メンバーのパフォーマンスを安定させ・飛躍させる土台を整えることに注力できました。土台が固くなるということは、更に多くのメンバーを迎え入れられるようになる、ということでもあります。以下のPodcastでも話しているのでぜひ聞いてみてください。
まとめると、プロダクト開発から正式に離れることによって、より影響度が高くなりうる新たな領域へ注力できたと実感しています。
他方でホロウィッツが記載しているTipsには非常にインスパイアを受けました。「言わずに書く」というのは筆のほうが早い自分を知る人からすると納得してもらえそうです。しかし課題も見つかりました。
それは「プロダクトレビュー」を正式なメカニズムとして会社へ埋め込んでいなかったことです。正式なメカニズムがないと、フィードバックを与える・正式な指示をだすメカニズムも持てません。
決してCEOが全てに介入するわけではないにせよ、CEOだけが持つフィードバック権利 であり責務 「ガラガラポン」は正式なメカニズムがないと発動もできないものになってしまうでしょう。そしてそれは会社にとっては非連続機会を逃すリスクにもなります。この記事を読んで数日後、急いでそのメカニズムを整備したところです。
皆さんの会社にはどのようなフィードバックのメカニズムは埋め込まれているのでしょうか。ぜひ感想と合わせて教えて下さい。