The launch date is tomorrow.
Your software developers are running on fumes. The days are a blur of email, trouble tickets, status updates, and everyone asking you how it’s going. The stakeholders are getting anxious, which is making you anxious.
What do you do?
I’ve never been part of a perfect website launch (has anyone, truly?), but I’ve worked on teams that have launched some pretty incredible websites.
But when there are so many moving parts, involving so many departments in one or multiple organizations, there’s likely going to be a glitch or two. Or six.
It’s not hopeless. There are actions you can take, before and during your launch, to mitigate and manage risk when launching a website, app, email newsletter, or any other digital feature.
1. Determine the must-have features and functionality in advance.
Know what’s considered a “no go” well in advance of your launch. You have no way of knowing what may or may not be ready for primetime months ahead of the fact, but this way you’ll know where to prioritize your remaining hours. A “no go” for you may be a “go” for your stakeholders, or vice versa, so make sure that you’re on the same page (and get it in writing). And, make sure to hold your ground.
If you’re not comfortable putting your name on something in the early stages of planning, you’re not going to be comfortable come launch time. A launch plan is a negotiation.
2. Do not announce an exact launch date to users.
It is tempting to tell your users that something big is coming. There is no better hook for audiences everywhere than the idea that something is going to happen, it’s going to be bigger and better, and it’s going to be a game changer. But, it’s in your best interest to say “coming soon” or “coming this fall” instead of a specific date.
Anything can happen to change your date, and it’s generally something you couldn’t have planned for, no matter how thorough you are. The company powering your site’s search engine could shut down tomorrow, or an important industry event tied to your launch could be canceled. Remember, users generally are not sitting around waiting for your website to launch, so there is no need for specific promises.
3. Ask your team to stay late in advance.
This is how the mission becomes possible. Commit to long hours during the last week or two of your development, depending on how large your project is. Make it no secret that this is not going to be their favorite week at the office. The commitment will be one less thing to worry about in the eleventh hour, and your team will appreciate the notice.
4. Build clean-up into your launch plan.
You’ve likely made some tradeoffs in order to launch on schedule, so it’s not time to pop the champagne just yet. Before your users find out about your less-than-perfect website, tweak it as much as possible. Consider holding off PR efforts until any leftover launch work is finished. When you build this into the schedule, the powers that be won’t consider the job complete until your plan is, allowing your resources to continue their work.
5. Stay calm.
Even though you likely don’t work for the Department of Homeland Security, a large part of this whole process is crisis management. Model the behavior that you want others to follow, understand and acknowledge tensions, and do not diminish anyone’s concerns. Respond to emergencies quickly. Excuse unreasonable behaviors from otherwise reasonable team members. Everyone is doing something big and big feelings come with it.
I’d love to hear tales of your digital feature launching escapades, for better or worse. Feel free to tell me about them in the comments section of this post. What are your secrets to building a good website?
{Image: jurvetson]
{ 4 comments… read them below or add one }
This is the type of smart stuff that too often gets forgotten in the sprint to “finish” (they’re never truly finished) a website. Great post.
Thanks, Andrew! I agree on the never truly finished part, and hesitated to use the word “completion” in the post. Maybe that will be the subject matter for another post… coming soon, of course.
I really enjoyed this post, Laurie. We hear so much on this blog and elsewhere about what steps we can take to improve our content, but we don’t talk enough about what those improvements will mean for people on the backend. Something like this really helps people better understand what it is they are getting into and how to prepare for it. I especially liked your adivce about the launch date. I can’t understand why people continue to impose such uneccessary deadlines. We’re hard enough on ourselves already! Better to take your time and get it right.
Thanks for the positive feedback, Corey. I agree; deadlines should be only internal whenever possible. And as a user, just show me, don’t tell me (and then maybe get it wrong).
{ 1 trackback }