The Challenges of Releasing Early and Often

Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery.

Have you ever rolled out a major product change while one of your sales reps was demo’ing your product to a prospect?

I have. It wasn’t pretty.

It wasn’t a small change. It was a new home page, completely new positioning, new branding. A whole new identity.

It was a Tuesday morning, late in April last year. Our team pushed the release at about 10:30am. Within 20 minutes, I had an angry sales rep at my desk.

He had been in the middle of a demo when the home page changed. It was jarring. He demanded a heads up whenever we released anything.

We used Kindling to collect feedback from everyone in the company on the new design. Everyone knew it was coming. But we didn’t communicate when we were releasing it. More on that in a minute.

Now you might ask, why are we releasing on Tuesday at 10:30am. Isn’t that disruptive to our customers, and users, and in this case, our employees?

The Power of Continuous Deployment

When I started working at AfterCollege, the engineers had been releasing every one or two weeks.  A product manager or someone in management signed off on every release.

That was the first thing I changed. I wanted the engineers to release whenever they were ready. As often as they needed. Not just every day, but multiple times a day.

I’m a firm believer in continuous deployment.

I want any engineering team I work with to feel empowered to release whenever they see fit. I want them to take ownership of the product and do what they can to make it better.

Rather than staging releases once a week, or once a month, or once a quarter, companies that buy into continuous deployment allow their engineers to release whenever they want. More importantly, they encourage their engineers to release as often as possible. Sometimes as often as every hour.

For those of you who work in an environment where you only release a few times a year that might sound frightening.

The rationale is simple and I believe it is sound. Your engineers are making changes every day that can benefit your customers and your users. Why are you making your customers and users wait days, weeks, or even months to benefit from those changes?

With continuous deployment everyone benefits from the changes as soon as they are ready. – Tweet This

There are other benefits. Each release contains fewer lines of code reducing the chance of introducing new bugs or conflicts. When things do break, releases are easier to patch or roll back.

What To Communicate When Changes Come Fast and Furious

But it doesn’t come without challenges. As illustrated by the story above, an environment that uses continuous deployment can be disruptive.

There are countless stories of companies causing mayhem for their customers by releasing unexpected changes. Tesla and Adobe, for example, have both faced criticism for their updates.

Regardless of whether or not your company uses continuous deployment, odds are, people will have a hard time with your product changes.

It is impossible to communicate the details of every change. More often than not a customer, a user, or an employee will uncover a side-effect that you were unable to anticipate.

Product teams often spend a significant portion of their time dealing with these side-effects. So what can we do to get ahead of this?

Foster a Culture That Supports Continuous Change

Most of the product changes that you make are not going to be as big as a new home page. Much of what we do is optimization and refinement. But even these changes can wreak havoc on a customer who expects things to stay the same or a sales team that follows a script.

Internet software continuously changes. Whether you release every day or every month, your sales team needs to be prepared to deal with this change.

Too many product teams look at this as the sales team’s problem. But you are the one who is going to have to deal with the consequences. You are who your sales team comes to when they have problems.

You are better off getting out in front of it. If you have a product marketing team, help them shift to talking about benefits not features. If you are the product marketing team, do this yourself. If you spend your time touting features, you will be constantly updating your messaging. The benefits you deliver should change far less often.

It needs to be an accepted part of your culture that your product is going to continuously change.  – Tweet This

It’s the only way your product and your company will be successful.

The more your entire company talks about benefits and not features with your external stakeholders, the less disruptive product changes will be, as long as the product continues to deliver on those benefits.

However, you still need to be mindful of the fact that any change, no matter how big or small, is going to be disruptive. Your team needs to balance changing things for the sake of change and making things genuinely better.

Test changes on small populations before rolling them out to everyone. Get feedback from a customer advisory board. Work to understand the real need behind each change. And never underestimate the disruptive nature of even small changes.

It’s Not All or Nothing: Big Changes Should Be Staged

Some changes are big enough that they need to be treated as special cases. Facebook’s original newsfeed roll out and their later timeline rollout are great examples of this.

These changes should be staged. You should communicate to your customers, your users, and your employees when they are coming and how it will impact them.

We should have done this with our home page change. While everyone knew it was coming, we should have gone one step further and scheduled the release. It was a big enough change that our sales rep should not have been surprised by it during the middle of a demo. This was my mistake.

I’ll be the first to admit that I am biased toward action. If the code is ready, I want it released. I haven’t worked at many places that have long release cycles or big product launches. I mostly work with young companies that release early and often.

This isn’t always the right answer. Sometimes you need to slow down and manage the launch.

But if your bias falls on the other side of the pendulum and you are thinking to yourself, we could never practice continuous deployment at my company, then you better also ask yourself, what’s your world going to look like when your competitors release every day or even every hour? This is where the world is headed. You better start moving in that direction.

Sign up for free email updates to Product Talk because up next we’ll be talking about the third pillar of building great products – building the right team.