A little under 2 weeks ago, I launched Onword, my latest web venture. If you haven’t yet heard of it, it’s a simple writing environment for the web. It was my first project written in Ruby, and it was developed in just 10 days. I’m very happy with it, and from the feedback I’ve received, so are its users. I’m not going to go into too much technical depth about Onword here. That’s for another day. I’d like to talk about shipping.
Having launched or been on the launch team of a number of products and projects, including Brills, Animate.css, Owlr, Onword, and Striving, I think I’ve learnt a few things about the best way to manage, develop, and launch a successful product.
Keep It Secret
One of the biggest mistakes I feel most startups, developers, or otherwise product-related people make is a preannouncement of a product. You know the ones — the one-page websites with an email address field to sign up for updates. Don’t get me wrong — I’ve made this mistake. Heck, I’ve made it in the last month. But it’s still a mistake. Or at best, a risk. Take an example — iTunes 11. iTunes 11 was announced earlier this year, (though it feels like last year) and it looked incredible. I couldn’t wait to get my hands on it. I eagerly watched the keynote to discover it’d be launched in October. Weird of Apple to announce something fairly minor in their product line and then not launch it there and then, but whatever. October came and went, and then Apple announced that it would be more like November. 21 days into November, and still no new iTunes.
Here’s the thing — a preannouncement works in some industries. I think it works quite well in the technology hardware industry. Computers, cars, tablets, cameras — it’s not at all unusual for these products to be announced months or even years before they’re shipped. But the web is different. Launching a web product is more like launching a chocolate bar.
A chocolate bar is something you don’t commit to. A chocolate bar is the sort of thing you spot at a gas station and pick up out of curiosity. If you really love it, you’ll keep buying it. If you don’t, you can ignore it and get back to the other chocolate bars. Cadburys have never (to my knowledge) announced a chocolate bar several months early. They make something new, put it on the shelves, and then advertise it. And it works for the on-the-spot nature of their trade.
Preannouncing a website (or a chocolate bar) will cause momentum for that product to quickly drop. People hear about a product that doesn’t exist, then immediately forget about it. When it arrives on shelves, they have the memory of that product somewhere, but with none of the original curiosity. They try it, and expect it to taste different. They build a picture of the product in their head, and that’s your fault.
Keep your product secret. It’ll fly off the shelves.
When I launched Brills, I was only at a few hundred followers on Twitter. My main outlet for promotion was Forrst, and that’s where I announced the launch. But prior to the launch, I made a pretty big mistake — I didn’t get any testers. A few hundred people signed up to Brills, and immediately alerted me of bugs. It was a busy week squashing them. On the plus side, launching on a larger scale helped me to maintain momentum for solving problems and improving the product.
A year on, and it was time for my biggest independent launch yet — Onword. This time, I developed the product in isolation for about 5 days. After that, I invited 5 close and trusted friends to sign up and start using the app. The next day, I added another 5. The day after, another 10. By launch day, there were only about 30 people who even knew about the application’s existence. And upon launching, the app was almost entirely bug free.
Keep test groups (at least initial ones) small, and make sure that only those you trust to give quality feedback are involved at this early stage. Take the time to explain your decisions thus far, and be sure to thank them for their time. These early stages will shape the entire project — be sure to make it someone who’s opinion you value.
Ship Early, Ship Often
While it can be good to make sure you’ve squashed all bugs before you launch your product, doing so can also squash the momentum you have for it. I’ve always found that shipping without testing every eventuality will keep you motivated to get those issues ironed out, as well as give you a chance to have someone else discover bugs for you. There’s no testing like real-world testing. For example, Onword’s launch day was actually supposed to be several days later than it was. I knew it wasn’t ready, but I just wanted to launch it anyway. So I did. And within a few hours, I got issues raised by users and fixed almost immediately — issues which would have taken me days to discover myself, and even longer to fix.
Shipping a “perfect” product leaves no room in your mind for improvement. It’s “done.” But that’s a slippery slope — our work is never done. And shipping changes before they’re “done” will help you remember that.
Relax. It’s launch day. You’ve come this far, and all you have to do is let the world know about your awesome new product. So, what do you do? Write a blog post, right? That’s the done thing. Only, it doesn’t really work. The idea of writing something — to me at least — makes me feel a lot of pressure about what information I need to put in there. Do I concentrate on the technology behind the product, or the process? Or both? Should it be long or short?
Let’s jump back to that chocolate metaphor. Let’s imagine that it’s launch day for your new chocolate bar. You could write a press release about the manufacturing process behind the chocolate bar, or the ingredients used, or the stages of product development. Or you could just put it on the shelves. Your customers don’t care about how your chocolate bar was made — they just want to eat chocolate. If they don’t like it, they won’t eat it again. If they love it, they’ll buy boxes of them and throw chocolate bar parties with their friends and get a chocolate bar tattooed on their butt.
By all means, publish an article about the development process — but don’t couple it with the launch. That’s just one more click for the user to get from your 2,000 word development story to the product itself, when all they want is to decide if it’s right for them or not.
A Matter of Opinion
These aren’t meant to be facts or lived-by rules. These are just guidelines, based on my previous experience with projects. The one thing I will state as fact is this — if no one buys your chocolate bar, that doesn’t matter. As long as you like it — and it’s your favourite chocolate bar in the whole damn world — then it’s a resounding success.