Small Batch Development
Work in the smallest possible increments to find problems faster and waste less
Small batch development applies the lean manufacturing principle of single-piece flow to startup product development. Rather than completing each stage of work (design, build, test, deploy) in large batches before moving to the next stage, small batches move individual features or changes through the entire process from conception to customer feedback in the shortest possible cycle.
The counterintuitive insight is that small batches are actually faster than large batches, even though they appear less efficient. Large batches hide problems until late in the process when they are expensive to fix, create massive inventories of work-in-progress that must be tracked and managed, and cause the large-batch death spiral where batch sizes grow ever larger as teams try to reduce the overhead of handoffs. Small batches surface problems immediately, require almost no work-in-progress inventory, and enable course corrections before waste accumulates.
In a startup context, the ultimate large batch is spending a year building a product before showing it to customers. The entire year of development is work-in-progress inventory. If the product fails to resonate with customers, all of that inventory becomes waste. Small batch development suggests shipping the smallest meaningful change, getting customer feedback, and using that feedback to inform the next small batch.
- Small increments surface problems early when they are cheap to fix, while large batches hide problems until they are expensive.
- Work-in-progress inventory is a liability that accumulates waste silently until it is too large to ignore.
- Shipping the smallest meaningful change and getting real feedback is almost always faster than completing a large planned release.
- The large-batch death spiral is self-reinforcing because the overhead of each handoff creates pressure to make batches even larger.
- The unit of progress worth measuring is validated customer learning, not features completed.
- Identify Your Current Batch SizeMap your current development process and measure how much work accumulates at each stage before moving forward. How many features are bundled into a release? How long does work sit in design before engineering starts? How much time passes between completing code and getting it to customers?
- Cut Batch Sizes in HalfTake your current batch size and cut it in half. If you release monthly, try releasing every two weeks. If you design ten features before handing off to engineering, design five. The goal is not to reach single-piece flow immediately but to reduce batch size progressively.
- Work Cross-FunctionallyInstead of having separate departments work on their stage in isolation, bring engineers, designers, and product managers together to work on one feature at a time from start to finish. This eliminates the handoff delays and miscommunication that large batches hide.
- Build Automated Testing and DeploymentInvest in continuous integration, automated testing, and deployment infrastructure. These tools reduce the overhead cost of releasing small batches, making frequent releases practical. Without automation, small batches are prohibitively expensive.
- Use Pull-Based Work SystemsInstead of pushing large batches of work through the pipeline, implement a pull system where each stage requests work from the previous stage only when it has capacity. This prevents work-in-progress from piling up and naturally limits batch sizes.
QuickBooks had operated on an annual release cycle for years, spending months on planning and strategy before building anything. In 2009, they shipped a redesigned banking feature that took customers five times longer to reconcile transactions than the old version. Because of the waterfall process, it took nine months to fix. After adopting small batch development, the team moved to rapid iterations and achieved results that far exceeded anything from the annual cycle.
Small batch development applies the lean manufacturing principle of single-piece flow to startup product development. Rather than completing each stage of work (design, build, test, deploy) in large batches before moving to the next stage, small batches move individual features or changes through the entire process from conception to customer feedback in the shortest possible cycle.
The counterintuitive insight is that small batches are actually faster than large batches, even though they appea