Release Early, Release Often

If you release often, but find that your releases tend to be of a low quality, then perhaps it's time to take the dial back a bit. If your releases are of a very high quality, perhaps it's worth looking at any waste that goes into each release and trying to eliminate it so you can release even more often if doing so would appeal to your customers.

The more often you release, the better you are at releasing; release overhead decreases over time. With long release cycles, the pain of release inefficiency is easy to ignore and justify and the urgency and incentive to trim that waste is very low.

It's demoralizing to implement a great feature or key bug fix and then watch it sit and stagnate with nobody using it.

Another concern raised is that this leads to more frequent lower quality releases rather than less frequent releases with higher polish and quality. After all, releases always contain overhead and by having more releases, you're multiplying this overhead over multiple releases.

The longer a feature is implemented, but not being used in real scenarios, the more the context for the feature is lost. By the time it's in customers hands, the original reason for the feature may be lost in the smoky mists of memory. And as feedback on the feature comes in, it takes time for the team to re-acquaint itself with the code and the reasons the code was written the way it was. All of that ramp up time is wasteful.

Every release is an opportunity to stop theorizing about what customers want and actually put your hypotheses to the test by getting your product in their hands

Matt Mullenweg, the creator of WordPress put it best in his blog post, 1.0 is the loneliest number:

Usage is like oxygen for ideas. You can never fully anticipate how an audience is going to react to something you've created until it's out there. That means every moment you're working on something without it being in the public it's actually dying, deprived of the oxygen of the real world.

It provides a rapid feedback loop

Steve Smith had this great observation (emphasis mine):

The shorter the feedback loop, the faster value is added. Try driving while only looking at the road every 10 secs, vs. constantly.