How to NOT Launch a Big Software Update
Justin McGill — June 17, 2017 — June 17, 2017
We recently rolled out a pretty major software update to the LeadFuze platform.
In the months leading up to it, the team and I were getting excited.
It was going to be a game changer and something that hadn’t been seen in the marketplace previously. It was exactly what our users were telling us they wanted.
Users that were canceling gave us the same kind of feedback:
Of course, getting it to a point we could launch it was troublesome.
We were running into one issue after another. It was already two months behind.
I recently performed a post-mortem analysis on the update, the launch, and what happened post-launch to see where we could improve.
Unfortunately, there were several things we could have differently.
Fortunately, there were also several things we would do again.
I decided to share this introspective in the hopes that others can learn from it as well.
Lessons From a Semi-Failed Software Update
1. Test EVERYTHING…Multiple Times
This was a product update that was relatively large. It literally changed the entire way users built lists. We were dropping our chrome extension and handling everything in-app.
We were able to leverage all of our own data, while building new data sources and partnerships.
There were a lot of moving parts.
We would run through a quick test, even built some unit tests, but we failed to account for all the moving parts.
A little more Q and A would have gone a long way.
Get your entire team involved in the testing process. Especially your Customer Success team so they can feel confident and know how to support users through the change.
You can also use a service like Blitz.io for stress testing heavy server load.
2. Soft Launch THEN Announce
The day of the update, we were still making last second code changes and bug fixes.
Probably a warning sign to begin with, but we were anxious to get this out. Again, it was already two months later than we wanted.
The moment the build was done (techie talk for the update went live), I fired off the email blast that it was live!
This email was saved as a draft for over a month.
Of course, immediately after clicking send we realized we had problems as our server CPU was maxing out and our data providers couldn’t handle the volume.
Doh!
Ideally, we would have released the update and hand-held the first several customers that had questions. We could have seen how our server and data providers were doing.
Let that run for a couple of days and then send out the email blast.
Now, if you have a list of several hundred people that won’t be an issue.
However, our list is approaching 15,000 subscribers so an email blast can mean a flood of users at once.
3. Triple Check the Links in Your Announcement
This was brutal as we rolled out a blog post to accompany the e-mail announcement.
However, I changed the URL of the actual email. Only, when I updated the link in Drip I apparently didn’t have the entire phrase highlighted.
So the first word was sent to a dead link, while the other was sent to the actual post.
#FAIL
This filled up my inbox with a bunch of responses.
A quick 301 redirect of the old URL did the trick, but since I was in Slack talking to dev team about all the issues, I didn’t notice my inbox filling up.
4. Launch When Engineers Will Be Available
Of course, we were working hard on so many last minute bugs that the day was getting away from us.
We decided to get it live and announce it the moment we thought it was ready.
Unfortunately, this was later in the day and our engineers were already seeing double.
If anything, soft launch later in the day with the plan of a full announcement the beginning of the next day.
5. Don’t Give an Estimated Launch Date
This is tough to do when you have users on the fence if they should cancel or not.
Especially when you know the update you are rolling out will fix their problems.
Even internally, you should avoid giving dates. Again, tough to do when Customer Success wants to know so they can pass it along to disgruntled users.
Did I mention we were two months past when we originally started telling users it was coming?
Ugh.
If there’s one thing that I’ve learned running a software company, you NEVER launch on time.
6. Don’t Avoid Support Tickets
Don’t go dark on your customer support tickets.
Even if the update worked perfectly, many users will be PISSED you changed the UI on them.
People don’t like change.
Don’t take it too personally. Just know they were used to things being done in a certain manner.
Luckily, we handled this one pretty well.
We tried setting expectations that we were working through the kinks the next couple of days and appreciated their patience. We didn’t want them to expect an immediate resolution.
At the same time, tell them to keep reporting any issues they encounter so that your team is aware. This actually makes them feel like they are a part of it – which can change the dynamic of the conversation.
7. Tease the Release
In our email blasts, we would give hints as to what was coming.
Of course, we thought it was coming “next week”, and so we got a little lucky with the teaser.
Because of the delays, we were able to string along four emails that referenced the big change.
We’d use the bottom of newsletter type updates to reference it, we’d use the P.S. section and even use a subtle screenshot.
This helps to build some excitement for the release, lets current customers know you’re working on things, and also sets expectations that some things might be changing.
8. Update Your Help Documentation
Our Customer Success team had plenty of time to prepare Zendesk with all new articles, update old articles, and add new screenshots.
We ended up going live with some before the update even happened, which ended up not being a big deal.
It was nice that we could roll out such a massive change and have documentation for user’s to go to for more help.
9. Communicate to Impacted Users
Not only did we have a massive update to the platform, we actually LOWERED pricing.
So much more value, yet lowered pricing. Go figure.
This was important though because we found our sweet spot.
At the same time, we communicated individually with users in advance who were paying more and actually gave them a lot more value for their money.
This allowed us to keep current revenue (by giving more value), and made those customers feel like they were getting a free upgrade (since they were already okay paying the higher price point).
10. Update Your Onboarding
Inside Intercom, we had a whole new onboarding experience both for new users just checking us out, as well as for paying users.
This includes new screenshots, new workflows, triggers, goals, upsell messages, and more.
Luckily, we had this in place ready for over a month as well and so we just needed to turn it on when the announcement went out.
11. Celebrate!
Lastly, don’t forget to celebrate when it finally launches!! rum and coke for everyone in the office and we captured screenshots of our announcement to document the journey.
This was a monumental day for us. I physically went and poured rum and coke for everyone in the office.
We captured screenshots of our announcement and posted it into our #moments Slack channel. We have this Slack channel just for the purpose of documenting the journey.
It was a great time to reflect with the team while also getting them excited about where we’re headed.
Conclusion
At the end of the day, it was a milestone and a major day in the history of LeadFuze.
I have always been focused on getting a product out the moment I think it’s “good enough”.
I literally have this printed on my wall:
While this served me well in the early days of LeadFuze, I’ve learned that things need to change as you progress as a business.
Avoid launching software update too early, but you still need to ensure the entire team feels the urgency. Especially when you are losing customers and your next update is going to solve those problems.
So there’s a delicate balance to be made between releasing too soon and releasing too late, but hopefully, this helps in guiding your decision.
Business & Finance Articles on Business 2 Community
(10)
