Determining Ideal Release Frequency for Software Products

One of the questions product managers are constantly asking themselves is, “How do I get product updates into the hands of my users at a speed that is most beneficial?”

In 2011, I was a part of an industry that shipped software annually. All the companies in the industry were trying to figure out the best way to schedule their annual release to maximize the market splash. Should we release just after an industry event? Should we release just after the market share leader’s annual release? Should we release right after the board meeting? Should we release at the end of our fiscal year?

Over the last five years, many industries have shifted to more frequent releases, like quarterly, monthly, and weekly deployments. New deployment technology and hard work from DevOps teams have made it a different world for releasing software products. But it’s still a rich source of debate within organizations: what is the right cadence for your product(s)?

Pros and cons of shortening your release cadence

Pros Cons
Faster, predictable delivery of features and bug fixes Less time for you to squeeze in a feature or bug fix
The risk of a bad bug is lower in a smaller release Software bugs being released every 2 weeks will seem worse than if the same amount went out once a month
Faster feedback for the team More frequent meetings and shorter sprints mean a higher tax on the product manager/owner
The marketing, training, etc. teams have fewer items to cover when summarizing the release Release summary processes might need an overhaul to support more frequent releases
A shortened release cadence can be treated as an experiment There may be development costs associated with increasing the release cadence, like changes to the way the product gets updated

You’ll want to do the same sort of pros and cons list for your product’s particular situation. When you do that, you’ll want to consider some product management best practices. Here are some best practices for release cadence:

  1. Make the release less risky by making it small. The goal: minimizing bad changes vs. maximizing good changes.
  2. Your release cadence is not a race. Don’t make the release small because you want to hold to a cadence that your business doesn’t actually require. For example, if your users use your product once a month, who will notice when you push to weekly releases?
  3. Consider your release health. If releases every 4 weeks are good, it doesn’t mean that releases every 2 weeks are twice as good. It’s important to look at past releases for technical risks, like a ratio of documented bugs vs. release size.
  4. Evaluate the value a faster release cadence will give to the users that use the product the most. Your power users will feel a change in release frequency the most. Will a faster cadence make them have to give feedback faster? Will a faster cadence help them do the jobs they’re doing better and faster?
  5. Put your executive hat on. It’s not only the dev team and the user that matters…make sure that release cadence is in line with your executive team’s expectations.
  6. Re-evaluate your release cadence every few months. The answer to how appropriate the release cadence will vary over time, as your organizational behavior and your users change.

Did I miss a consideration for release cadence? Do you have any stories to share on the subject? If so, leave a comment.

For more product management articles, read The Product Guy Daily. I publish it every morning.

3 Responses to Determining Ideal Release Frequency for Software Products

  1. Good post, and thoughtful analysis. I will add one dynamic.

    Having spent time in enterprise communications software, where the bulk of the revenue is tied to keeping customers under maintenance contracts, you need to have a predictable cadence at least for major releases. That “large” release was timed to keep customers on the maintenance contract, the “hook” to keep them in the game, so to speak.

    Of course, with a big hairy product like that, most of the customers treated us like Microsoft, and waited until the first service release was ready to work out the kinks. So we were quite good about having a service release ready within 90 days of the main launch. Our major cadence was 18 months, and we had 2-3 SR’s, and often a score of bug fix patches.

    (Oh, the story I could tell about the chaos that a patch release of Exchange 2010 caused, but alas, that is beyond scope.)

  2. First, your cadence may be a function of your end market, not your capabilities. Think about new, chaotic industries where the state-of-the-art is changing every week. (Data Mining algos are a good example.) The need to keep up with the Joneses in that case is different than, say, basic industrial controls with well-established standards.

    Second, don’t forget that some customers may not welcome your updates. It’s a headache to install, a headache to re-validate your code within a larger code base, somebody has to learn it, … You may want to modulate frequencies on a by-customer basis.