Loading ...Here’s a handful of tips for first-time application developers and lone-ranger Web entrepreneurs scrambling their way to a private beta launch, based on lessons learned from http://SoIndustry.com going in to private beta last week:
1. Expect Broken Features
You’ve worked hard on getting your Web application to a state in which you’re ready to share it industry contacts, friends, or even family (and hopefully it didn’t take too long to get to this point). But even if you have the most comprehensive test suite ever conceived (presuming you’re working with a development framework/environment which encourages testing, e.g. Ruby on Rails, in TDD or BDD styles), things are going to break, and it’s very annoying when they do. Despite this only being a private beta, you’ll want to impress anyone & everyone who comes across your product, and broken features have direct effect on first impressions.
As soon as outsiders start using the application, bugs will crop up - literally, straight away. Some will be complete show-stoppers (the RSS parser has broken in SoIndustry a few times, and RSS aggregation is an important part of the service; even the registration form had a bug at one point), and when those big issues do show up, you need to be ready to tackle them and work through them asap. They’ll often ruin your plans for the day.
The plus side to all this is that you’ll quickly learn what really needs doing, and in what order. When you’re in pre-beta development, it’s easy to spend too much time focused on things that really don’t matter that much (color:#AAA; or color:#BBB;?). Get in to production and you’ll almost immediately change your approach to prioritisation; nothing brings the product development cycle in to focus like having people using your product (or not, thanks mr broken registration form).
2. Have Community Ready to Go
During the development period of your product, hopefully you’ve created some kind of audience ready to receive it and to use it. You don’t want to launch a private beta and to have absolutely nobody willing to use it and run through the user experience in the unstable first release (I’d like to think that this is slightly different to ‘having a market for your product’).
SoIndustry has been a long time in the making, and during this time I could have done more to build up the subscriber base for the couple of blogs I’ve set-up over the last year or two. The good news is that people have been in touch with me during development, a few people have subscribed to the blogs, and they’ve all been happy to go straight in to the site to help with the bug testing and preparation for a public launch (no ETA yet). If you’re one of those people, thank you - it has helped a lot.
Running a blog can be a full-time occupation (running a blog about blogging can be a full-time occupation), so you don’t want to focus on building a blog community the detriment of your Web application development (your app is your product, not your blog posts). But it would be more than sensible to gather email addresses and subscribers on a pre-launch teaser blog, and to have people ready to go in and scrutinize your private beta offering as soon as it’s live.
3. Provide Instructions
The private beta is where you’ll really find out whether or not your app cuts the mustard on the usability front. Usability is hard, but the closer the tie between your front-end team and back-end team, the more usable your product will be (that’s a topic for a follow-up post).
No matter how much you’ve done to make your application usable before a private launch, people will still be confused by things, they’ll feel lost at times, and they’ll be very tempted to give up after the registration form returns the first validation error on the email address they entered without an @ symbol. This is where clean and clear on-screen prompts (but not too many, mind) are vital, even on your form error messages. Site tours upon first log-in, tips sprinkled around in obvious places, and an up-to-date FAQ, will really make a world of difference to the user experience in your application. If people in the private beta aren’t using the application in the right way, you won’t be using the private beta to learn what needs correcting for the public beta (and that’s why you’re doing a private beta in the first place).
SoIndustry probably doesn’t employ enough instructional features, but it’s a simple application to use and navigate (so I’ve been told, please tell me if you think otherwise, and if you haven’t signed-up, please do so - show off your expertise, post an update, upload a banner for your professional services or company, check out the Newsfeeds…). Because SoIndustry is built around status updates, if something goes wrong, people have a tendency to just post a status update explaining the problem. That makes my life easier.
4. Set-up Feedback Channels
As previously mentioned, I’m very lucky regarding SoIndustry feedback; people can just post a status update when they find something that doesn’t work as expected, e.g. “I can’t access the People tab in my Industry” (that actually happened). I love this (the ease of use, not the broken features) - there’s very few barriers to entry for someone willing to share their annoyance with a broken feature (that’s as long as the status update feature isn’t broken, then it’s game over).
If you’re not building an application through which people can post status updates, you’re going to need another route for collecting feedback. Email is an obvious choice. Ask people to email you right back when they’ve been in the application and had a good look round. But be realistic and only setup feedback tools which you’ll definitely use. For example, Uservoice channels look like fun, but you need to make them well integrated (i.e. use the widget they provide) otherwise people won’t use them.
5. Make Architectural Changes & Move On
Code goes stale, features become deprecated, design becomes outdated, and you’ll never be 100% happy with your product. Always bear that in mind, Optimize for now!, say 37Signals. However, post-private beta launch, you’ll probably start mulling over some big architectural decisions which you weren’t 100% decided on prior to the private beta launch. You’ll be tempted to make those changes now because they’re the ones you won’t be able to forgive yourself for in a public launch. If you really have to make these changes, make them asap - just do it, and don’t think too long & hard about it. Having less options makes you happier. Be honest with yourself and immediately make the changes which are currently occupying 80% of your brainpower.
That’s it; those are my top five. Do you have any tips for a private beta launch?
