The small batch method refers to the lean manufacturing concept of doing things in small batches. Taking the time to do things one by one instead of creating a huge batch of one thing, a huge batch of the next thing, and then joining them together at the end.
A quick example.
When mass manufacturing a car, you would assume it’s better to build a whole stack of headlights, a whole bunch of headlight mounts, and then put them all together in one go. The thinking here is to focus on one job at a time. Make the headlights, make the mounts and then assemble them all at the end. This is referred to as a large batch.
The issue with this is, you have 1,000 headlights and 1,000 mounts ready to go. But as you were making the lights, the mould was slowly going out of shape the more it was used. You might not notice the difference for the first 200 lights but after a while the shape is to warped to fit in the mount. Now you have 800 headlights that are useless. What a waste :(.
Small batches would be to create 1 head light, 1 mount, and assemble it before you start the next one. This avoids potential waste, as you would have noticed as soon as the light was not fitting correctly anymore and fixed the issue immediately. While this may halt the entire production line while the mould is fixed, this is a much better option than allowing the problem to be found further down the track where it could be very difficult to rectify and a lot of time and effort has already been wasted.
It can also reduce the management and space required to deal with the large amount of stock that is produced from large batch processes.
In product design.
This same thinking can be applied to product design. By releasing your product often with smaller updates, you can catch these issues early on and fix them before they become a bigger problem.
If you are releasing your products on a yearly cycle for example, with a huge amount of changes each time, you might find all your hard work was not what the customers wanted or it may cause some other unknown issue after release. You end up spending the next cycle rolling back those changes. That’s a whole lot of time wasted.
It also makes it harder to identify exactly which changes caused the issue.
With quick release cycles, it makes it very easy to run cohort analysis on your releases and really understand your users need and pain points.
Reducing time and money wasted on a project can’t be a bad thing right?
Thanks for reading. Don’t forget to check out my site!