The podcasts Off Topic and Repeat Rhyme both covered the concept of "compound startups." Give them a listen if you haven't:

(Podcast links)

I recorded my own thoughts on the topic from a founder and product builder perspective on my podcast Zero Topic — including some responses to ideas raised in those episodes.

(Zero Topic link)

This post is the rough working notes I prepared before that recording. I hope you'll read it alongside the podcast.

Quick Review of Compound Startups

  • A pattern is emerging where startups launch with multiple products from the start
  • This differs from the traditional playbook of: find one specific customer pain, build one product, achieve PMF
  • Benefits include multiple revenue streams
  • In the US, this works because of acquisitions, technical integration capabilities, and strong engineering organizations — but it's genuinely difficult to pull off
  • In Japan, those resources are even scarcer

Two Patterns of Multi-Product

  • "Multi-product" actually comes in two distinct flavors
  • Pattern 1: Multiple products built on one platform. The benefits are shared infrastructure — security, data integration, abstracted technology. You also get cross-sell opportunities into your existing customer base. The downside: you have to build the platform itself, which is extremely hard. Beyond product development, you need platform development and management, plus the organizational structure to support it. This raises management complexity enormously. In most cases, data model architecture is highly challenging, as is deciding at what abstraction level to invest in your own technical assets. And people with platform development and design experience are rare in Japan.
    • In Stailer's case, multiple products were built on a single data model to achieve a first PMF, but enterprise demand for using individual products independently has grown large. Separating and re-architecting them is a prerequisite for a second PMF — and it's a major challenge. We're betting the company on it.
  • Pattern 2: Independently built products from the start. Benefit: independent teams, no dependencies. Downside: without an abstraction layer, low reusability. You end up essentially re-founding the company each time. Customer assets are reusable though.
    • A good example to consider here is Bill One. The OCR + human review tech and ops built for Sansan and Eight are reused directly, plus cross-sell into the existing customer base. I suspect the data models aren't unified, so it's probably somewhere between Pattern 1 and Pattern 2.

Market Forces

  • There's a growing underlying problem: "you can't start a startup without solving many complex problems simultaneously"
  • Whether to pursue that with a single data model, modular products from the start, or N independent products — the technical decision is increasingly hard
  • Founders now need the skill to make appropriate architectural decisions before even worrying about development speed

You Have to Think About the Organization Too

  • Eventually the business organization must be split to match the product structure — otherwise you simply cannot move fast. This is reverse Conway's Law. Without it, you can't properly handle feedback loops
  • Once requirements exceed 100, management breaks down. You need to think independently within each module
  • The ability to align technical decisions with business decisions is an essential capability