コンパウンドスタートアップについて起業家視点で考えた

Off TopicおよびRepeat Rhymeという2つのPodcastで取り扱われていた「コンパウンドスタートアップ」という概念があります。まずは以下の2つを聞いてみてください。
#135 コンパウンドスタートアップとは何か?マルチプロダクトの優位性
Listen to this episode from Off Topic // オフトピック on Spotify. ◎今週のトピック コンパウンドスタートアップとは? / Rippling CEOのパーカー・コンラッド氏 / 複数プロダクトを作るべきか?ひとつにフォーカスすべきか? / 時代によって変わってくるかも / 1社あたり使ってるSaaSプロダクトは○○個! / SaaSアプリ多すぎて連携難しい問題 / “ひとつのプロダクトでは勝てない” / Figma買収から経緯と今後を考察してみる / ワードとエクセルはいち機能でしかない / シングルプロダクトの限界 / ラスボスのセールスフォースとMicrosoft / “連携“が強み / Ripplingのミドルウェア / レポートやアナリティクスで効果を見たい担当者 / でもめっちゃ難しくね!どうやる? / C向けでも通用するか 【Spotifyオリジナルで新番組がスタート!】 bytes by Off Topic http://spoti.fi/bytesPodcast ◎参照リンク https://www.notion.so/offtopicjp/135-12ca1c13b93840a69e5d0a77eb2ec920 \ インタビュー動画シリーズもはじめました / https://www.youtube.com/c/offtopicjp ◎Twitter Off Topic https://twitter.com/OffTopicJP Miki Kusano https://twitter.com/mikikusano Tetsuro Miyatake https://twitter.com/tmiyatake1
これにについて、起業家やプロダクト開発者的な視点からの意見を自身のPodcast「Zero Topic」で収録しました。一部会話されていた内容へのAnswer的な要素も含まれると思います。
 
本記事はこのZero Topic収録にあたって準備した走り書きのノートを公開したものです。Podcastと合わせてお読みいただけると嬉しいです。

コンパウンドスタートアップのおさらい

  • スタートアップとしてマルチプロダクトからスタートする、というパターンが出ており、
  • これまでの特定の顧客のペインを1つのプロダクトでPMFしなさいというセオリーとちがう
  • メリットはいくつも商品が売れること
  • USは買収、技術的インテグレーション、エンジニア組織が下敷きとなっている。しかしかなり難しい
  • 日本においてはこれらを実現する資源がより貴重だろう
 

マルチプロダクトにも2パターンあるのではないか

  • マルチと言っても2つあるのではないか
    • 「1. 抽象化されたプラットフォームをベースに複数のアプリケーション(ここでいうプロダクト)がN個存在するパターン」と、
    • 「2. 全く独立した別のプロダクトがN個存在するパターン」
  • 1のプラットフォームをベースにする場合、メリットはプラットフォームによる共通基盤の恩恵を受けられること(セキュリティ、データ連携、抽象化された技術など)
  • また当然既存の顧客資産にクロスセルをしていける
  • デメリットはプラットフォームを創らないといけない。これが超絶困難。プロダクトの開発の他にプラットフォームの開発やマネジメントが必要になるため、それに応じた組織も必要になる。経営の難易度が飛躍的に上がる
  • 多くの場合でデータモデルのアーキテクトが極めて難しい。また自社の技術資産をどの抽象水準で投資するのかも難しい。そしてプラットフォーム開発・設計経験者が必要で日本には極めて希少
  • Stailerの場合は複数のプロダクトが1枚のデータモデルの上に創って1度目のPMFをしたが、内包される個別のプロダクトの独立した利用対するエンタープライズニーズも大きい。よって分割、独立したアーキテクトにしていくのが2度目のPMFに必要要件で、これが大きなチャレンジになっている。社運をかけてやっている
  • パターン2のはじめから独立したプロダクトは、メリットは独立したチームで開発できる。依存もない。デメリットは抽象領域を検討しないため、再生産性が低い。使い回しができず、毎回起業するようなもの。顧客資産だけは使える。
    • そして国内のほとんどのマルチプロダクトはこれだと思っている
  • このパターンを考える上での好例はBill One。SansanやEightで構築している技術とOpsの基盤がそのまま使われている (OCR+人による目検) & 顧客資産にもクロスセルできている。多分だけどデータモデルは共通化されていない気がしているのでちょうどパターン1とパターン2の中間じゃないかと思う
 

市場の要因

  • そもそも、これまでより「同時に多くの複雑な問題を解かないとスタートアップできない」問題がある
  • これを1枚のデータモデルでPMF目指すか、はじめからモジュール分割されたプロダクトでいくのか、個別のプロダクトを独立してNこつくるのか、技術的意思決定がめっちゃ困難になっている
  • 創業者は開発の速度を担保する前に、このアーキテクトに対して適切に意思決定をしていくスキルが必須になっていっていると思う
 

あわせて組織を考えないといけない

  • 最終的には事業組織もプロダクトに合わせて分割しないと絶対に速度が出ない。逆コンウェイ。なぜなら適切なフィードバックの取り扱いができないから
  • 要求が100を超えるとマネジメントは崩壊する。モジュールの中で独立して考えないといけない
  • 技術的な意思決定と事業的な意思決定を一致させる能力が求められる