Products Ship 90% Complete

The launch sets the ceiling

Pedro Franceschi, running Brex, states the pattern as a near-law of product building: "Every product that you ship is 90% of what it will ultimately become."¹ Once a product rolls out to the mass base, which at Brex means tens of thousands of companies, later iteration mostly polishes the surface. It rarely rescues a weak core. In his account, the consequence is that the leverage sits almost entirely in the phase before broad rollout, not after it.

That reframes where effort should go. If launch fixes roughly nine-tenths of what a product will ever be, then a fast, shallow first cut permanently caps it. Franceschi's response is to over-invest in what he calls the kernel: the small-cohort discovery phase where the concept is still being narrowed. "That original genesis of here's the kernel of something great is really hard to replicate at scale," he says. "You have to start really small and create the environment that makes it happen."¹

Two hard problems, in order

Franceschi separates discovery into two distinct stages and insists they be taken in sequence. First is the undefined-problem stage, the question of what is even worth solving. Second is the undefined-solution stage, the question of what the right design and interface should be. He treats the first as the harder and less reversible move: "once you define it, it's very hard to go back once you start building." Many builders, in his telling, are strong at solution design once the problem is already constrained, but few are good at the constraining itself.

The practical instruction that follows is to run discovery cycles longer than people expect, testing with very small cohorts until the concept is genuinely narrow, and only then expanding use cases, rollout, and user count. He locates this as the same instinct behind the startup maxim about doing things that do not scale, relocated inside a company of more than a thousand people rather than a garage.

Signal-to-ship as the quality metric

The organizational number Franceschi attaches to the principle is the speed from capturing a customer signal, the moment it becomes clear there is a real problem, to shipping a high-quality solution to it. He describes scale as the enemy of that latency: more customers, more users, more employees, and more sellers all sit between the signal and the ship. Preserving what he calls "YC-level thinking and quality of operation" as the company grows is, in his framing, the job. This connects to his related belief that a scaling leader has to operate at all levels, moving between forty-thousand-foot strategy and five-foot product detail, and to his practice of launching new efforts as separate from-scratch environments rather than reshaping the existing organization around them.

Where the rule strains

Franceschi is candid that the doctrine gives no clean stopping rule. It says to run longer cycles than instinct suggests, but the gate for when a kernel is ready is taste-based, resting on whether the concept feels right and whether the builders are proud of it, which is hard to institutionalize. He also raises a possible exception to his own rule for agent-based products. For deterministic software, launch is close to final, but for products that improve through evaluation and reinforcement learning after release, the last ten percent may be both larger and more automatable than the ninety-percent claim allows. The principle is less a measured constant than a discipline: treat the pre-launch kernel as the place where the outcome is actually decided.