There is a saying that goes back to Milo of Croton: lift a calf every day and when you grow up, you can lift a cow. The principle applied to product design: products must mature no faster than the rate at which users can adapt. Call that ideal maximum rate the Milo rate. Exceed it and you lose the user. Fall below it and competitors eat your lunch. The constraint is not what you can build — it is what a human nervous system can absorb.

Simple Picture

Imagine teaching a grandmother to use a smartphone. You do not hand her an iPhone Pro Max with custom widgets, hidden swipe gestures, and nested settings on day one. She will panic and throw it in a drawer. You give her a brick with a screen that only makes calls. Six months later, you add a camera button. A year later, you introduce WhatsApp. The grandmother’s brain needs time to build new muscle memory for each abstraction.

They mistake their ability to produce complexity for the user’s ability to consume complexity.

The Core Subversion

The conventional reading of Lean Startup, MVPs, and rapid iteration is that they accelerate discovery — you learn what users want faster. The Milo Criterion inverts this: building software faster is actively hostile to user adoption. Code has no physical constraints. Engineers assume user behavior also lacks physical constraints. But human neuroplasticity and habit-formation are biological processes bound by the speed of meat.

Engineers naturally want to build complex, feature-complete systems. Given free rein, they will drop a calculus textbook on a user who is still learning to count. The Lean methodology — customer development, rapid iteration, two-week sprint demos — is not actually a mechanism for discovering value faster. It is an artificial friction-inducing ritual. It is a speed bump disguised as an accelerator. By forcing engineers to stop coding and talk to a user every two weeks, Lean accidentally throttles the product’s evolution down to the biological speed of human habituation.

Lean Startup works not because “pivoting” is magic, but because the bureaucratic overhead of the methodology acts as a governor on the engine of feature bloat.

This is the Theory of Constraints applied to product design. The bottleneck is not engineering capacity — it is the user’s cognitive absorption rate. Any improvement not at the constraint is an illusion. Shipping features faster when the constraint is user adaptation is like adding upstream capacity before the bottleneck: it creates more work-in-process that piles up at the chokepoint, reducing effective throughput.

What Companies Actually Sell

Software companies do not sell utility. They sell habit structures. If your product requires a user to break an old habit and form a new one simultaneously, churn will be catastrophic. The product must slot into existing behavioral patterns and then incrementally reshape them — the same way air travel evolved from bus and train conventions over a century, accumulating dozens of learned behaviors (check-in, security, boarding, baggage carousels, duty-free) that would be incomprehensible if dumped on someone all at once. This is the product-level expression of the Manufactured Normalcy Field: the future arrives along a least-cognitive-effort path, and user experience design is the manufacturing of that normalcy.

An MVP is not the “minimum code required to test an assumption.” It is the maximum cognitive load a target user can absorb without abandoning the interface.

This reframes the MVP as a constraint-derived quantity, not a business-strategy choice. The right MVP size is determined by the Milo rate of your target user population. Sophisticated users with high technical fluency have a faster Milo rate — they can absorb more complexity per cycle. Grandmother has a slower one. The engineering question “what is the minimum we can ship?” becomes the cognitive question “what is the maximum they can absorb?”

Deliberate Withholding

The operational implication: you hold back finished features deliberately until the user base proves it has mastered the current paradigm. This feels perverse to engineers. The feature is built, tested, ready. Withholding it seems wasteful. But shipping it before users have habituated to the current interface is worse than wasteful — it is destructive. Each premature feature degrades the user’s mental model of what the product does, increasing confusion and churn.

Your “continuous deployment” is continuous psychological assault.

This connects to tempo at the product level. Premature exploitation — shipping before the user’s mental model is ready — produces the same result as the cheap trick that buys too little time and provides too little leverage. The organizational absorption rate is the internal version: push more improvement than the system can metabolize and the system rejects you. The Milo Criterion is the external version: push more product than users can metabolize and they reject the product.

Dimwit / Midwit / Better Take

The dimwit take is “ship fast and iterate — speed wins.”

The midwit take is “we need more user research to figure out what to build.”

The better take is that the constraint on product success is not what to build or how fast to build it, but the biological speed at which humans can form new habits. User research tells you what to build. Engineering tells you how fast you can build it. Neither addresses the actual bottleneck, which is the speed of meat. The winning product is not the one with the most features or the fastest iteration — it is the one whose complexity ramp matches the cognitive absorption curve of its users. The manioc lesson applies: the elaborate, seemingly wasteful process exists because the human organism cannot be rushed without consequence.

Main Payoff

The Milo Criterion explains why many technically superior products lose to inferior ones. The inferior product is simpler — not because its engineers are less capable but because its complexity happens to match the Milo rate of the target population. The superior product exceeds that rate and gets thrown in the drawer. The relationship between product complexity and user adoption is not linear but threshold-based: below the Milo rate, more features help. Above it, more features actively destroy adoption. The grandmother does not learn 80% of the smartphone and struggle with the last 20%. She panics at the complexity and learns 0%.

The deepest lesson is that the constraint on product evolution is the same as the constraint on all human learning: the speed of the nervous system, not the speed of the tools. Every productivity system, every feature roadmap, every “move fast and break things” ethos runs into the same wall: the meat is slow, and the meat is the bottleneck.

References: