Upgrade your website and die 2

Changes to your website are easier to manage when you do one thing at a time. It’s tempting to include all the new features while the developers are at it anyway. But if traffic or sales fall afterwards, it’s much harder to find the cause when you’ve changed three big things at once.

This is my July 2010 addition to the warning about changing or upgrading an online shop, portal or other online solution. Feel free to watch the first video first. I’ve thought a little more about making the transition less risky.

Big changes to your website should happen in stages

I understand the argument for doing everything at once. You’re sitting with the developers, the floodgates are open and you’re already underway. So why not include every feature?

Because big changes cause errors. My experience is that you get both lots of errors and some big ones. After a major upgrade, you can find yourself biting your knuckles because traffic falls or fewer visitors end up buying.

If you’ve only made one major change, you know where to start looking. You can say: We’ve changed this one thing. If the result is a complete disaster, you can roll it back and return to the old version while you keep working on the fault.

Another option is to keep the change and fix the faults while the solution is live. Of course, that’s annoying for users, but many can live with quite a bit if you say on the site that things are unstable and you’re working to fix them quickly. Then you at least have one defined area to work on.

Which of the three changes ruined sales?

If you’ve made several big changes at once, you don’t necessarily know what made customers stop buying.

Is it the search engine work? Is it the new shopping basket that doesn’t work or doesn’t appeal to customers? Is it the home page design? The subcategories? The internal search? Where is the problem, exactly?

It’s very hard to troubleshoot when you don’t know which change triggered the problem. You fix something you think is the fault, and perhaps things get even worse. But that doesn’t necessarily mean the fix itself is wrong. It may have created a new error elsewhere in the system.

Before you know it, you have an absolute mess. That’s why my advice is to make one fundamental change at a time, bring users along and work on the errors in that change before moving to the next. Also read E-pusher about my experiences with business and online sales.

Don’t roll out big changes on Fridays

My next advice is to avoid big changes just before the weekend. The developers may suggest Friday morning. They’ve worked all week, and you want the new solution live right now. I understand that.

But when you roll out on Friday morning, the errors I’ve just talked about can appear. Then the developers spend all Friday battling them, perhaps after already working flat out for weeks.

They’re tired. They’ve planned to go home to their families for the weekend, relax and do something else. Around four o’clock, they expect to finish a hard week and head home.

If you then discover on Friday evening that the shopping basket has gone haywire, the discussion forum doesn’t work or you have a serious Google problem, suddenly you have a whole weekend ahead and people who’ve promised their families something else.

Perhaps you can persuade them to keep working. But this was when they were supposed to recover from the marathon you’ve just been through. Families get angry, developers get irritated and they aren’t rested. Those are poor conditions for doing good work. And the problem may not be fixed by Monday.

Prepare on Friday and start when people are fresh

So I wouldn’t schedule big changes for Thursday or Friday. Prepare on Friday, then roll out on Monday morning when everyone is fresh and rested.

Then you have Tuesday, Wednesday and the rest of the week to work through the problems and get the solution working. That’s how I think you should plan major rollouts.

It isn’t just about your impatience to get something new live. It’s also about having people available to handle what goes wrong, and those people being able to think clearly.

Break up the work so customers quickly see a benefit

My last advice is to keep individual changes small enough for customers to see the benefit quickly. I first say a week in the video and later use seven to ten working days as a framework. The point is short, manageable cycles.

If a change requires much longer development, you risk the developers running out of steam and getting tired. You also risk making a change that’s far too big.

So try having a rule that every improvement to your online shop or website should lead to something visible to customers within a short cycle. Otherwise, developers can lose motivation, customers can become confused and you can burn out in the process yourself.

One change at a time, time to handle the errors and a rollout when people are available. Those are the extra tips I want to give you before you rebuild everything.