Small Batches

Ries draws on lean manufacturing — the Toyota Production System — to argue that small batches outperform large batches in almost every dimension that matters to startups. A large batch (months of work shipped at once) hides defects, accumulates rework, and delays feedback. A small batch (a day of work shipped at once) surfaces problems early, when they are still cheap to fix, and produces feedback that informs the next batch.

The counterintuitive finding from lean manufacturing — confirmed in software, marketing, and customer development — is that small batches are faster end-to-end, even though they appear slower at the individual-task level. The time saved by not building defects, not accumulating rework, and not waiting for late feedback exceeds the apparent overhead of more frequent shipping.

For startups, the practical move is to compress every cycle — design, build, test, learn — into the smallest possible unit. A feature that would have taken a quarter becomes a two-week build that ships and gets measured. The next two-week cycle is informed by what shipped, not by what was planned in the quarter.

The discipline is uncomfortable because it requires shipping unfinished work, accepting initial-version judgment from customers, and trusting that the next iteration will improve what the first one revealed. Teams that learn the discipline outpace teams that ship perfectly polished products on a quarterly cadence — the polish ships less learning than the imperfection did.

Ries imports the logic of lean manufacturing — especially the Toyota Production System — to argue that small batches beat large ones on nearly every dimension a startup cares about. His homely illustration is stuffing envelopes: counterintuitively, completing each envelope one at a time finishes the whole job faster than folding all the letters, then stuffing all the envelopes, then sealing all of them, because large batches hide defects until the end and force expensive rework. In product terms, shipping a day's work surfaces problems while they are still cheap to fix and produces feedback that immediately shapes the next increment, whereas shipping months of accumulated work delays the feedback until the assumptions are wrong at scale. He points to IMVU's continuous deployment, where the team shipped dozens of times a day, and to the andon cord from Toyota — the principle that anyone can stop the line the moment a defect appears, so the root cause is fixed immediately rather than propagated. Reducing batch size is therefore the practical lever for accelerating the entire Build-Measure-Learn loop, and the chapter's central paradox is that doing less work at a time reliably produces more total learning and throughput than batching it up for one big release.