Talking to users every two weeks works mainly because it slows the engineers down.
Imagine teaching your grandmother to use a smartphone. You would not hand her the newest flagship, with custom widgets, hidden swipe gestures and nested settings, on day one. She would panic and throw it in a drawer. You would give her something closer to a brick with a screen that only makes calls. Six months later you would add a camera button, and a year later WhatsApp. Her brain needs time to build new muscle memory for each abstraction.
Every product team understands this about grandmothers. So why do so many ship as if their users were different? Venkatesh Rao’s answer starts with a saying that goes back to Milo of Croton: lift a calf every day and when you grow up, you can lift a cow. 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.
The speed of meat
Teams overshoot because the two sides of a product run on different clocks. Code has no physical constraints, so engineers come to assume user behavior has none either. But habit formation is a biological process bound by the speed of meat. Given free rein, engineers build complex, feature-complete systems and drop a calculus textbook on a user who is still learning to count. They mistake their ability to produce complexity for the user’s ability to consume complexity.
This is the Theory of Constraints applied to product design. The bottleneck is the user’s cognitive absorption rate, not engineering capacity, so shipping features faster is like adding capacity upstream of a bottleneck: the work piles up at the chokepoint and effective throughput falls.
That also explains, oddly, why Lean Startup works. The usual story is that customer development and two-week sprint demos let you discover value faster. Rao reads the methodology as an artificial friction-inducing ritual. By forcing engineers to stop coding and talk to a user every two weeks, it accidentally throttles the product’s evolution down to the speed of human habituation. Its overhead acts as a governor on the engine of feature bloat.
What an MVP really is
If the constraint is the user, software companies do not really sell utility. They sell habit structures. A product that asks the grandmother to break an old habit and form a new one at the same time will lose her. One that slots into what she already does, and then reshapes it gradually, has a chance.
That changes what a minimum viable product is. It 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. The engineering question “what is the least we can ship?” becomes the cognitive question “what is the most they can absorb?” Sometimes that means you hold back finished features deliberately until the grandmother has mastered the camera button.
Who sets the pace
The Milo rate is not one number. Sophisticated users with high technical fluency absorb more complexity per cycle than the grandmother does, and a product paced for her will bore them while a competitor moves faster. So the criterion does not say “go slow.” It says 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.
That is how technically superior products can lose to simpler ones. Adoption is threshold-based: below the Milo rate, more features help, and above it they destroy adoption. The grandmother does not learn 80% of the smartphone and struggle with the last 20%. She panics at the complexity and learns none of it. Which makes the most important number on any roadmap one that nobody on the team controls: how fast the people using the product can change.
References:
- Venkatesh Rao, The Milo Criterion, Ribbonfarm