How To Launch Software

37signals recommends that software developers pursue what they call the Hollywood Launch. They don’t give any argument for this method, except perhaps the title (as if Hollywood was a business you should try to imitate?) — I guess the idea is that you’re supposed to do it since 37signals says to.

The basic idea behind the Hollywood Launch is simple: you release a few hints about your product to build buzz, slowly revealing more and more until the big day, when you throw open the doors and people flood your site, sent there by all the blog coverage and email alerts.

This may work well for Hollywood — if your movie is a big hit at the box-office on opening weekend, then the movie theaters are more likely to keep showing it in the weeks to come and you get credit for being “one of the weekend’s biggest films”. But for software developers, it’s moronic. Your software isn’t being released in theaters, it’s available over the Web. You don’t have to worry about the theater no longer showing after week one; you can keep pushing it for years, growing your userbase.

Instead what happens when software developers try the Hollywood Launch, and I’ve seen this many times, is that users indeed do flood to your site on launch day but…

They bring the site down from the load. You scramble to get it back up and succeed by coding like a mad man, only to find…

They discover some big bug that you never quite noticed before, which makes the whole thing look like embarrassing hackwork. (What? You forgot to test that last-minute JavaScript change in IE6 1/2?) So you’re desperately rushing to fix the bug before the traffic dies down, rush-patching things and restarting the server when…

You bring the site down for everyone because there was a syntax error in your patch that keeps the server from coming back up. You fix it while cursing yourself madly. Finally everything seems to work. You take a breath and decide to see what people are saying about you on the Web, only to discover…

Everyone misunderstood what your product does because your front page wasn’t clear enough. Now they all think it’s stupid and wonder aloud how you even know how to breathe. So you reply in all the comment threads and fix your front page to ensure no one could possibly misunderstand what it is you’re doing just in time to find…

All the traffic is gone.

Tomorrow, hardly any of those users come back. Your traffic graphs look like the sharpest mountain you’ve ever seen: a huge climb up and then, almost immediately, a similarly-sized crash back down.

So what do you do then? Well, you do what you should have done all along: you grow the site.

I’ll call this technique the Gmail Launch, since it’s based on what Gmail did. Gmail is probably one of the biggest Web 2.0 success stories, so there’s an argument in its favor right there. Here’s how it works:

Have users from day one. Obviously at the very beginning it’ll just be yourself and your co-workers, but as soon as you have something that you don’t cringe while using, you give it to your friends and family. Keep improving it based on their feedback and once you have something that’s tolerable, let them invite their friends to use it too.

Try to get lots of feedback from these new invitees, figuring out what doesn’t make sense, what needs to be fixed, and what things don’t work on their bizarre use case combination. Once these are all straightened out, and they’re using it happily, you let them invite their friends. Repeat until things get big enough that you need to…

Automate the process, giving everyone some invite codes to share. By requiring codes, you protect against a premature slashdotting and force your users to think carefully about who actually would want to use it (getting them to do your marketing for you). Plus, you make everyone feel special for using your product. (You can also start (slowly!) sending invite codes to any email lists you might have.)

Iterate: give out invite codes, fix bugs, make sure things are stable. Stay in this phase until the number of users you’re willing to invite is about the same as the number you expect will initially sign up if you make the site public. For Gmail, this was a long time, since a lot of people wanted invites. You can probably safely do it sooner.

Take off the invite code requirement, so that people can use the product just by visiting its front page. Soon enough, random people will come across it from Google or various blogs and become real users.

If all this works — if random people are actually happy with your product and you’re ready to grow even larger — then you can start building buzz and getting press and blog attention. The best way to do this is to have some kind of news hook — some gimmick or controversial thing that everyone will want to talk about. (With reddit, the big thing was that we switched from Lisp to Python, which was discussed endlessly in the Lisp and Python communities and gave us our first big userbase.)

Start marketing. Once you start using up all the growth you can get by word-of-mouth (and this can take a while — Google is only getting to this stage now), you can start doing advertising and other marketing-type things to provide the next big boost in growth.

The result will be a graph that just keeps accelerating and climbing up. That’s the graph that everyone loves to see: solid growth, not a one-day wonder. Good luck.

Since 37signals quotes from people who followed their advice, I thought I might as well do the same. mojombo:

I find this to be excellent advice. This is exactly the approach we took at GitHub almost down to the letter. It took about 2 months until the site was good enough to use to host the GitHub source, another month until we started private beta with invites, and three more months until public launch.

Artificial scarcity is a great technique to generate excitement for a product while also limiting growth to a rate that won’t melt your servers. We worked through a huge number of problems and early users gave us some of the ideas that have defined GitHub. By doing a Hollywood launch, things would have been very different and I am convinced, very much worse.

Do not, I repeat, DO NOT underestimate how much your users will help you to define your product. If you launch without having significant user feedback time, you’ve essentially thrown away a massive (and free) focus group study.

Let me also say that when we finally did our public launch, there was plenty of buzz, and all of it was the RIGHT kind of buzz. The buzz that attracts real, lasting customers (and no, we weren’t on TechCrunch, that traffic is garbage).

Comments

Having experienced that first day launch, I totally agree with you that a slow build is better than a sudden drop off a sheer cliff. However, I disagree that you should keep invite codes up for so long. After you’ve stabilized the codebase to the point that it is no longer embarrassing and seems to actually work, you should let anyone sign up; just don’t make a big deal about it.

Good point. Upon reflection, I realize it’s not about when the site is stable, but when the growth in users won’t be overwhelming. I’ve fixed it; for the record, 4 used to be:

Iterate: give out invite codes, fix bugs, make sure things are stable. Stay in this phase as long as it takes to go a couple iterations without serious problems. Gmail did this for a long time, partly to scale really big, partly to find all the weird edge cases with email, but mostly because they could — there were a lot of people who wanted invites. But when you feel like everything is stable and you want more growth you can…

In a way, the method you described is how Facebook launched too. It felt like an exclusive country club at first, only for college students in the US, before being expanded across universities across the globe, and down to colleges/high schools elsewhere, and now, open to all.

One interesting thing is when you’re doing a nice GMail style launch and then you start getting organic blog links and such, and the users are turned off by the closed site. Nothing more off putting than hearing about an awesome site you can’t use.

I thought your argument was going along great until you hit point 6. You’re reasoning here is about as well thought out as the “???” step between underpants collection and profit.

Launching something is a big event and should get you press. Totally re-factoring an application in a new language is the sort of thing you should have done somewhere between step 1 and 2. It worked in your one-off case but there’s no applicable lesson in that step which we can take away for ourselves.

You’re basically saying: Step 6. Magically generate a shitload of hype now that you’re ready for the traffic.

If we knew how to do that, we wouldn’t need to be thinking through launch strategies in the first place! 37 Signals give some practical advice specifically on hype-building and deliberately not on engineering quality, scalable software.

Good advice. I read the 37Signals Hollywood launch section in Getting Real and I felt a certain discomfort with the idea. You pretty much nailed the approach I’ll be taking to slowly introduce users to my product. I think it’s a much more wise approach.

It is not either/or. If you do a “by invitation only” program to start out with, you can, through that, build hype, leading up to a “Hollywood” style release. As long as a limited amount of people have access to it, you are spreading an official rumor; one could say it was vaporware, except that there would, in fact, be some people out there actually using it (aside from yourself).

After thinking about it a while I realized that the big benefit of using invite codes was to ensure that people and bots didn’t use up all the good Gmail addresses before the people could get them. Imagine putting all that effort into building a system only to find that someone automatically reserved all the useful, easy-to-read usernames. With such a public product, this was important, but it’s probably not the case for smaller sites.

Having been involved in the dev of a couple of systems (one web based , one phone based) that were big bang marketed your description of the issues is bang on.

You are setting yrself up for weeks of intense pain, coming at a time immediately after the team has already squeezed out every drop of sweat and adrenaline to meet the ‘launch date’ which is an unmovable date because of the booked advertising for the launch.

So you not only risk losing/not gaining users, creating a stink market impression, but also losing your team members - either directly by them walking or by burning them out.

Although you sound very dismissive of the approach, and strongly hint that they are mutually exclusive, there is very little difference between it and what you’ve just written. In fact, the only difference I see is that you place greater emphasis on invites as a buffer against scaling issues, where 37signals makes passing reference to them as “golden tickets”. Given that your piece is three times longer, I wonder if perhaps you’re simply reading too much into the title. (e.g. Your sniveling at “Hollywood” being a bad model to follow is cheap and snide, knowing full well it’s only a fleeting analogy.)

I thought it was interesting to use Gmail as a counter-example, too. Gmail is an ad-supported service, while 37signals products and their example Blinksale are paid services. Users of the later are presumably less inclined to help you generate revenue by using your beta-quality product, no matter how special they feel for getting an invite. Unless you have a ton of cash to burn (a farcical notion among smart startups these days), you’ve still got to have a mostly-successful launch or you’re dead in the water.

Restaurants and retail stores do something a little similar, but it’s called a “soft opening.” Basically, you open your doors to the public without advertising to serve those folks that stumble by and see you are open. This way you can work out the bugs with limited customers for a few weeks, before the big splash. A “hollywood launch” is not quite the same, because when I think of that I think of limited venues showing a popular movie at only limited theatres, which is what gmail did by just allowing in so many people for so long. But the biggest problem with this theory, is that you have to BE of a known stature (such as a company like 37 Signals or Google to do this. Otherwise, you’re just another piece of software or web app with low traffic. I myself plan to take the soft opening (or in this case, soft launch) approach, make our app a public beta to start and not aim for too much traffic, and backfiring PR (such as the overhyped, non-cool Cuil.) Interesting tactic though.

Apple likes Hollywood Launch for their tangible products like MacBook and iPhone. But this method turned out to be not suitble for online service as wittness by Jobs’ recent email concluding their MobileMe service is “not ready” when launch.

This, too, is how WordPress.com launched - golden tickets at first and later open to the world, followed by slow but steady growth.

One interesting thing is when you’re doing a nice GMail style launch and then you start getting organic blog links and such, and the users are turned off by the closed site.

This is actually a huge opportunity: just capture their email. Now you have an ever-growing list of people to seed new invites to in addition to the ones your existing users can send out. I’ve seen sites keep the list rolling for months, sending out only a few hundred at a time. This also creates a nice continuous buzz as people blog about getting their invite.

The main thing I wonder about the Gmail launch is how it could be applied to a 37signals style product. They charge a monthly rate to use their software. At step 5 would you want to say to all current users, “start paying or your account will be suspended”? If it’s gotten as big as Gmail had by that point grandfathering the current user base into a free plan would be a bad business decision.

One alternative (similar to something that 37signals employs) would be to grandfather current users in, but launch some new features only available to the new paying users. I’m still not crazy about that. I think that incorporating a revenue model that doesn’t depend on a free service is important in this discussion.

So, what you’re really saying is, don’t use a press-worthy event to attract attention to your new web app until you’ve scaled up enough to handle it? Okay, where exactly in the “Hollywood Launch” article you quoted did the 37signals guys specifically promote doing a big launch before the app is ready to handle lots of traffic? How is that article even connected to this post besides the fact that a “Hollywood” launch can be harmful to your site’s reputation if you aren’t ready to handle it?

You seem to be heavily conflating marketing advice—which is what the 37signals guys primarily gave in that article—with advice on how to make and maintain a good product. In particular, you seem to be saying that a Hollywood-style launch will fail developers that don’t HAVE their shit together. Developer incompetence can make a hash of even the best marketing advice. Developer incompetence can make a hash of any advice.

I’m not sure why this post even exists. It doesn’t make any sense. I keep trying to set out something about the Gmail example you gave, but I keep coming back to the fact that there doesn’t seem to be a concrete reason for this post to exist.

Chris above has the other key feature of the invite-only site: bot protection.

It’s not only from rate limiting — you also get a built-in-from-the-start web of trust among your users. If someone turns out to be an asshat, or a bot, or is submitting malicious requests, you can reconsider how you feel about their sisters and cousins on the invite family tree.

This post talks about publicly releasing a site before undertaking a marketing campaign to people you don’t know (even the offering invite codes to email lists in step 3 is about lists “that you have”, not just any old random lists).

The “Hollywood Launch” approach discussed by 37 Signals discusses marketing to people you don’t know prior to launching your site in order to generate “buzz”.

Please explain how these two approaches are the same.

EM, I’m not sure why your comment even exists. Unless it is to show that you don’t read other people’s blog posts carefully.

Also… rather than demand an email, the infochimps.org launch will ask people to either @infochimps||follow us on twitter, or to tag an interesting dataset ‘infochimpsable’ on delicious.com. We then respectively direct message or for:user their invite link.

Benefits: 1) the user is in control of how we communicate with them. 2) It’s an intelligence test. 3) We get at least one of: publicity, trust network connection, addition to the collection. 4) You can automate, when it gets to that.

The point is that in spite of dismissing 37signals as being “moronic” (and devoting more words to that subject than are in the entire excerpt from Getting Real), the actual content of the advice isn’t mutually exclusive.

Dude, the whole point of this post is to emphasize that no matter how competent you are, you will miss some critical bug unless your site is tested by real-world conditions (e.g. thousands upon thousands of users). We’re far past the threshold where any human being can manage to foresee all the possible implications of a large codebase coupled with a world-sized userbase. It’s why all significant software has bugs.

The same thing that makes OSS work “with enough eyes, all bugs are shallow”, happens to have an opposite clause: “With enough users, all software has bugs”.

Rather than blithely ignoring the aforementioned facts, we can embrace them, and try to mitigate their effects. Or we can ignore them, and kick ourselves when bad things inevitably happen for not being the mythical “competent developer”. Perfectly competent developers are like perfectly competent drivers. There’s a reason we have seat belts and airbags, and it’s because perfectly competent drivers are a myth. Even competent drivers screw up.

Never blow the doors open to the public unless your site has been tested within an order of magnitude of the scale the public will stress it under. This means preferably thousands or millions of people.

Don’t forget, you can supply invite code to users to invite others, but it’s always a good idea to let anybody sign up for an email blast that’s going to let everyone know that the site is open. I couldn’t use Twine right away but I was intrigued enough to wait a month for an email that I said I could sign up. Think of it as the line at an exclusive club. People with invite codes know the door man but everyone can wait in line.

I agree with you, but note that this is almost 180 degrees apart from advice you’ll gain from MBAs and others who have read crossing the chasm.

From there, we learn the importance of understanding your early users and geeks and dweebs that are not helping you understand what your real usersnormal people need or want.

It’s important for you to use their advice for bugtesting, BUT TO ABSOLUTELY IGNORE what they claim are their needs. You want to pay attention to the needs of the people on the other side of the chasm, even if you haven’t met any by dint of the fact that anyone that comes to your early stage site is basically a geek and dweeb.

I have been through the Hollywood launch and it was a disaster. Our current company has followed your model to the letter, releasing a free version and fixing and building based on user-input. Given that our paid product (SaaS) starts at $500/month, the input from free users has been incredibly useful in delivering a quality experience. This is great advice.

I was part of a big Hollywood style release sometime back. The date of the release was announced; our beloved, feared, industry respected and controversial CEO ready to launch; folks from who’s who lists were invited. Guess what? We were not ready from the product perspective, the day before. After working 18hrs a day for a week before the release nobody was ready to respond to sign-up issues on the BIG day. The product never took off.
Know your product before announcing it —whether it is to a friend or public…

The Hostile Monkey doesn’t really see what the fuss is here. What happens when the blogs are buzzing about your “limited beta” invite-only response, and then finally you open the floodgates to anyone who wants to visit?

What was that?

Did someone shout out “Hollywood Launch?”

The Hostile Monkey couldn’t hear - the sound of the server exploding distracted him a little.

This monkey thinks that 37s is talking from a marketing stance, and Mr. Swartz is talking from an engineering stance.

Define “launch”. The Hostile Monkey bets that AS will say “as soon as a random can use it”, and 37s will say “as soon as ANYONE can use it”. Did 37s not private beta Basecamp prior to launch? Isn’t that what we’re talking about here? The extent to which you private-beta?

One big problem with a GMail launch is that it’s never actually clear WHEN the app has launched. When was The Hostile Monkey supposed to start giving Google shit for downtime? A Hollywood launch (or “Step 6” as AS calls it) at least lets people know when the developers think it’s ready for prime time.

The Hostile Monkey thinks that AS assumes that Hollywood launch translates as “boot the server 30 seconds before zero hour”. THAT’s moronic, but it’s not what 37s advocated.

The Hollywood Launch is awesome for products that are ready. How do you figure out they’re ready? 37s doesn’t talk about this because, well, it’s up to you how you figure that out. Steps 1-5 are a really good way of figuring this out.

Even Hollywood has test screenings and previews months before prior to release, before they figure out who and how to market the launch.

I just want to drop a line and say how much I liked this article. Yes, I had seen the approach Gmail had used and loved it. But being a business guy I hadn’t paid attention to how that had helped the software development process. Thanks a ton!

I like the tone of this advice a lot, but I think it misses the mark for a lot of different markets. Not all markets are created equal, and a Hollywood style buzz may be difficult, if not impossible to generate in some markets.

The focus for any product has to be communicating with and getting the market your selling to involved. Not every site is going to get a bunch of interest from early adopters who will try anything and love signing up for the next best thing.

You need your audience working with the product on their terms to truly kick the tires, and putting up some splash page with an email address field and no real feature explanation or launch date will eliminate participation from a whole host of your core audience. Sure they may come back one day, but it leads to the sort of half-baked participation that gets you into trouble down the line.

I think the best thing you can do when putting your site out there for public beta is keep on communicating. As long as your on top of the issues that come up and let people know what you’re doing to address those issues (as long as they’re not major and site crippling), you’re ahead of the game.