How to Prepare for a Product Launch, Part 1: What Could Go Wrong?

The day of your software product launch is finally here. The date of golive. You’ve TDD’d, you’ve user-tested, you’ve QA’d, you’ve exploratory tested, you’ve QA’d again. You’ve hammered on your software every which way, and you’re confident that it’s ready to face the public.

So, why are you still biting your nails?

There’s one badge of honor your app won’t earn until launch day: Battle-Tested. You just can’t know how end-users will use, misuse, and abuse your shiny new project until you put it out there, on prod, for everyone to react to. What will you do if (when) something goes wrong?

Here are a few questions to ask yourself to quell the nervous energy and get some sleep before the big day.

What could go wrong?

Start by making your best assessment of the types of issues that could come up after the product launch. Some of these can be tested for in advance; others might be prohibitively expensive to simulate. No matter how bulletproof you think your app is, at least one will catch you completely by surprise.

Here’s a shortlist of possible problem vectors and some examples of what to watch out for to get you started:

  • Failure under heavy traffic: A server slows to a crawl juggling thousands of requests per minute; a SAAS tool nails you with an unexpected rate limit. Most folks test for this with tools that simulate high request volumes.
  • Failure at scale: Someone miscalculated the O(…) of a common DB query; a formerly-quick nightly export starts timing out with sheer volume. These can be sneakier to test for — can you simulate a fully-loaded DB or a data pipeline with a few months of records?
  • Attacks and abuse: Someone’s crawling your site with a bot and hoarding new products the moment they drop; an enthusiast is producing thousands of votes per second for their favorite Fat Bear. Put yourself in the mindset of someone with malicious intent and hammer on your app; if it’s a mission-critical app, consider investing in a third-party security audit.
  • Network or service failure: A public API you were relying on goes down right in the middle of your peak hours; the cell towers at a baseball game can’t handle the volume of traffic your ticketing app is hitting them with. How does your app behave when the network connection dies or when a needed service starts returning 500s?
  • Just plain bugs: A timer goes wonky when daylight savings time starts; testing didn’t catch that a particular phone’s browser can’t render that fancy animation. All the tests in the world won’t keep you safe from human error. What kind of bugs will you consider showstoppers vs. point release candidates?

Yikes. I have enough to worry about already.

Of course, you do! Enumerating the what-could-go-wrongs isn’t about keeping yourself up at night or filling your backlog with bubble wrap. It’s about having a vision of what sort of challenges you might face and, ideally, having a team-wide discussion about how you might prevent or deal with them.

This list is non-exhaustive, and no matter how long you worry about it, something’s going to slip past your careful watch. In the next post, we’ll talk about how to spot problems when they arise, before they turn into angry phone calls.

What product launch issue caught you by surprise? Share your horror stories in the comments!