One topic that's often overlooked — and certainly not much discussed — is what goes on behind the scenes when you launch a new update of your existing web app. While the bulk of the work is done in the months, or years, of development, the final weeks before launch — and the weeks following — are more hectic and draining than anything at the development stage. You've got to deal with testing, marketing, customer service, system administration, design touchups, and last minute bugs that only show their head after you've flipped the switch. A sloppy migration can really set you back — à la Digg — and a smooth rollout — à la Twitter — can gain you a lot more loyal customers. Don't expect to sleep.
How We Marketed Our New Update
An update is different than a spankin' new full bells and whistles upgrade. There's a lot of new stuff, but it's not of the same magnitude as when you're introducing, say, the iPhone for the first time. Steve Jobs presents a new update to i0S differently from the way he presents a new device, and we for our part don't want to overplay the significance of the update. Yes, there's a lot that's new, but still, an update has to be presented in a different light from introducing a whole new concept or else you're going to underwhelm your users.
With that said, there's still plenty to do. One thing we really wanted to do was to send a newsletter to our users. Before that we had never sent out a single newsletter or announcement, but this update was significant enough to warrant one. Together we worked out the gist of what we wanted to say in the newsletter and then hired one of our close friends, Angela Black, to craft the copy. She and Dave designed out and wrote up two newsletters: one to our Whoo! users (paying) and one to our meh users (free).
If we had had more people and time, we would have created a "What's New" page similar to what Twitter launched to preview their new update. A "What's New" page is great for existing users to get a sense of things that are coming in the new version. We tossed the idea around the office, but couldn't justify the time in relation to this update.
The Rolling Release: Generating Hype
As a tactic in marketing, and something that worked very successfully for us during the release of our new update, we slowly leaked the migration bar to users over time. This builds hype by generating the idea of scarcity. People want what they can't have — especially if their peers have it. That's part of what Dribbble, FFFFOUND!, Forrst and other invite-only communities bank on.
We first release the migration bars — with newsletter — to our VIP users. Our VIP users are people to whom we give all the privileges of a paid account without the cost. They're generally some of the more talented creatives on our website — folks we show off on our Examples page. This gets our new update into the hands of some of the more heavily trafficked portfolios on Carbonmade, which instantly gets us emails and tweets to the effect of: "I saw Nirrimi's portfolio. How'd she get it to look like that?" We haven't told anyone other than our VIPs that there's an update yet, so buzz begins to build.
Following the release to our VIPs — with a dozen or more bug fixes — we began releasing the update to our paying users at 1,000 person intervals. Your paying users deserve the update in advance of your free users, but only after things are working smoothly. The gap between the release to our VIPs and our paying users was a good four to five days, so that we could make sure we had time to deal with any critical bugs.
By the time you've rolled out your update to your VIPs and paying users, the free users are chomping at the bit. Many of them are so desperate for the update that they email in asking whether they will get access to the new features if they upgrade. But of course, we say. Then as we began to roll out the new update to our free users at about 60,000 newsletters and migration bars a day, we saw almost double our typical upgrade increase even though more and more of the free users now knew they could get the update anyway. This was certainly owing in part to the great new feature set in the update, but also to the build-up that preceded the expanding release. Steve Jobs knows he's going to sell more iPhones if they're not immediately ready for release when he announces them. Hype is the best marketing money can't buy.
Migration by stages also helps to fight any downtime or slowness that your web app might experience if you release to all of your users at once — 280,000 in our case. This was especially important for us, as we had introduced a brand new video encoder and image generator which re-built every video and image when someone migrated over.
Technical Bits and Bobs
I'm a non-technical guy, but I talked with Jason Nelson (our developer) over greasy diner food about the technical bits of Carbonmade's migration. Jason's approach to migrating old apps to new apps — as he states it — is fairly simple. Jason uses the concept known as MVC ("Model View Controller"). What MVC does is keep things loosely coupled by separating your UI from code and isolating the changes with versions. Here's how they work:
At the action level (within the controller) we do this by breaking out our code into versioned blocks. For example, when updating a project, we might have:
From our UI (the views), we specify what version of the update method we'd like to use.
For instance:
Taking this a level further, we scope entire view sets out by directory. Each directory specifies the versions of the code they're dependent on. When it comes time to migrate folks over, we just bind their website address to a different view directory with the new version of the app.
Example:
Cake (not just a piece of it).
Morale Specialist
When we asked Mike, our recently appointed "customer service and community manager," what he wanted his title to be, he chose Morale Specialist. Perfectly fitting. We knew we'd have a lot of people contacting us when we rolled out the update, so we had to be ready to receive everyone's requests. We didn't really change our customer service routine during the release of our new update apart from adding a 1-800 number for people to call.
We got about two to three times more emails during this time than we did before the update. Up from about 50-75 taps of the send button a day to anywhere between 150 and 200. Tweets and Facebook wall posts were also way up during this period as we leaked tidbits on the new features.
Gathering Feedback
As mentioned in "Technical Bits and Bobs," when everyone logged into their accounts, they were presented with a message bar at the top of their screen saying: "Thanks for trying out the new Carbonmade. Let us know if anything looks amiss. Or go back to the old version."
The "Let us know" text linked off to a feedback form where people could let us know what they thought or if they had any technical issues. We wanted to make sure they felt comfortable migrating over to the new update and that they could get in touch with us with any questions while making the switch.
We were also constantly checking Twitter and Facebook for feedback. As much as I like to talk about the drawbacks of social media, they can be a really powerful tool for gauging people's reactions when tied into customer service.
Gather up all the feedback (emails, tweets, and Facebook messages), compile them in Google Docs for everyone you work with to see and begin to sort through the messages. If you spot a bug, throw it in Basecamp, as we do in a "To Do" list, and alert your programmers. Otherwise, don't overload them with criticisms of the update. Keep their spirits up by sharing only the positive feedback.
Don't Have Downtime
If Digg had had fewer broken axles during their recent re-launch, the community backlash they received would have been far less severe. Those same users would have been just as upset with the individual feature changes, but they'd at least have had a website to play around with. They'd have explored and seen what Kevin Rose and the other product people at Digg had in mind for them. Instead, all they got was a broken website, which further compounded their frustration. "Not only is Digg broken, but I can't even access the new version," they screamed, further compounding their distrust and frustrations with the re-launch. Don't make this mistake.
Don't Rush
It can take a hell of a lot of restraint — something I'm not always the best at — to keep you from throwing up your hands and sending out the update early to all of your users. There's a big difference here between releasing early and often and releasing foolishly. You may be able to get away with a premature update when you have a few hundred or a thousand users, but when you've got people paying you good money for their portfolios to work, you have to be thorough when testing and not jump the gun a few days or weeks early just so you can breathe again.
If you do, you'll end up with twice as much work. You'll be more panicked and run into far more problems if you rush things. At a certain point we were "ready" to release our new update to our paying users, but chose to sit back and wait five days, during which we re-encoded everyone's video so that when the time came our video encoding machine wouldn't get swamped as everyone moved over, causing it to build up a long queue and be unviewable until all the re-encoding was done. A little foresight of this kind can save you face, time, and headaches. An extra five days after over a year in development is going to help you, not hurt you.
Don't Move Your Office Then
Since September of last year, we've been sharing office space with the crew over at Harvest — a New York City startup. Its been a great arrangement, but the size of both of our companies has doubled in the past twelve months and in the early part of this year we knew we'd have to look for a new home.
Having been friends with Anthony and the folks at Squarespace for a while now, we heard that they were moving to new offices around June 1st, 2010. They're also in our same building in SoHo, and as we love the area an easy transition into their old space seemed too good to be true.
Construction delays are inevitable, and as we were waiting for them to vacate their old space, we had our hands tied. We were in office limbo, just waiting for them to move out so that we could move in. June went by, July, August, and then finally in early September we got the news that Squarespace's old space was ours for late September.
At the same time we were going to be inaugurating an update to our portfolio app. Egads! While we were putting the final tests and debugs on our update, we had to deal with all the things entailed in an office move: furnishing the raw loft space, hiring a cleaning service, setting up Internet, getting the energy bill transferred over, a million Amazon orders, and so on.
This is not something that we could have avoided, but still, planning a move into a new office space is not something you want sloshing around the back of your brain when you're hunting down Internet Explorer bugs and pushing around last minute pixels. Thankfully, the move went okay and we were about to begin the rollout a few days before move day.
Don't Move Apartments
Carbonmade is made up of five full-time folks: Spencer, Dave, Jason, Michael, and Mike. In what can only be described as a freakish act of bad timing, Spencer, Dave, and Michael all had to move apartments during the month of September — Spencer and Dave only from one New York City apartment to another, but Michael from Portland, Oregon with his wife and daughter and all his belongings to NYC.
Michael, along with his friend Jim, took the first week of September to pack his stuff into a large Penske truck and then proceeded to drive across the country to his new place in Park Slope, Brooklyn. On his arrival, Spencer and Jason both went to meet Michael and spent the entire day unloading the truck. A productivity loss of about 10 days for Michael and 1 day for Spencer and Jason — all occurring within the final month before releasing our update.
Don't Hire New People
Having made the major move East, Michael only began working with us on September 15 — within 45 days of our update. Even though we couldn't have released it on time without Michael's help, there was the inevitable process of getting him up to speed that might not have been worth it if our team had been bigger already. However, in our actual circumstances having Michael's help was indispensable.
If you can possibly do so, you should put a moratorium on hiring new people during the few weeks leading up to a release and the few weeks after. It's not a great environment to bring a new employee into, and the time it takes to get him and her up-to-date is time taken away from focusing on a smooth release.