The wisdom of ‘release early, release often’

Release early, release often — often shortened to ‘RERO’ — is a popular software development nugget of wisdom.

It’s a philosophy toward software development that encourages early and frequent releases of software features and fixes.

But why is this approach so lauded? What’s the wisdom fuelling this software philosophy?

The benefits of RERO

‘RERO’ is all about creating a tight feedback loop between software developers and the users of the software.

This generates a host of benefits:

·         You create a solid, desired product

‘Release early, release often’ allows you to guide product development by the market you’re targeting. That tight feedback loop allows for user-centred design.

When you RERO, you get regular feedback and requests. In turn, this means you’ve got actionable insight into exactly what users want.

In other words, your software gets moulded by customer needs and evolves to fit what the market most wants.

·         You have happier customers

The tight feedback loop of ‘release early, release often’ also means that customers/users have a say and get what they need. (Not what developers think they might like.)

So, users are satisfied not only because they get what they want — but because they feel invested in the development of your end product, too.

Releasing early and often also means that customers/users get their requested features and fixes in their hands faster. So, there’s less time dealing with bugs or waiting for promised functionality.

·         Drive and direction for developers

Then, there’s the benefit that RERO offers developers.

Releasing early and often creates a strong sense of progress for developers. They will consistently reach a goal post and get to see their work out there.

Frequent release opportunities also reduce the pressure on developers to rush and meet unreasonable or overshot deadlines. If a feature isn’t finished by a release date, it can be added to the next, rather than scrapped.  

This also feeds into the additional benefit of handling deadlines and plans. Shorter release cycles are far easier to predict than looking way ahead into the future. That is, developers get a more easily predictable schedule of features and fixes to tackle.

Releasing early: the fears

Releasing early can be daunting. It feels as though you’re barely-baked software will set a bad tone for future iterations of the product.

But done right, this is not the case.

Releasing early means finding early adopters for your product. It starts the software on the road to profitability sooner, rather than later. You also then get more data in to help see market fit. This means ‘release early, release often’ can help to make sure you don’t end up releasing a huge product that no one wants.

To release early, it’s important to make sure that your software — as bare-bones as it may be — works. For instance, it’s your minimum viable product. It needs to have the core functionality of your proposed solution for you to build around.

Releasing often: how often is often enough?

Several factors influence just how often ‘release early, release often’ means.

For example, you need to consider the adoption cost to customers. This covers any monetary costs (say, with upgraded hardware specifications), and the disruption of your updates. The danger is releasing too often. It’s too disruptive and takes up their time for too little gain.

You don’t want to release too often, lest customers get update fatigue.

On the other hand, you want to release often enough to showcase new functionality and maintain that precious feedback loop. So, you need to weigh up the disruption to the customer with the payoff.

The type of features you’re developing also play a role. Early on, there’s a good chance you can release quickly, as you slowly build up more and more of your product. But later, you’ll be making more general changes and fixes, which may take longer to develop to the level of quality you want.

RERO: user-centred design

The wisdom behind ‘release early release often’ is that it enables you to include real user voices in your development. It encourages user-centred design.

This means a better product-market fit, more flexible software development, happier customers and fulfilled developers.

What’s not to like?

Useful links

The tech market and why the winner takes it all

In a nutshell: the technology adoption lifecycle and crossing the chasm

Identifying your SaaS product market fit

Software adoption, development, and Goldilocks