Release early and often and achieve success
The founder of Timmy on Time, a web app that helps freelancers and teams track time via IM (pretty sweet from a quick look), recently wrote a post on his blog titled, “Releasing early and often… how it failed for us.” Provocative title, but is releasing early actually bad advice?
Why release early and often?
There are a few reasons to release early and often. It allows you to:
- Quickly assess your app’s chances without investing a ton of time (and money).
- Keep your app’s feature set limited and realistic.
- Get rapid feedback from the market.
Dan Simard, the author, writes that the main reasons are “to start making money as early as possible and to avoid discouraging development team.” These are happy side-effects. If these are your main reasons, you’re relying on luck and setting yourself up for failure.
Releasing early and often is about acknowledging that you don’t know how the market will respond to your product, and reducing the time you sink into something that might not work out. It’s about taking a shortcut to a feasibility study.
Your product may be an abysmal failure, your target market may need features that you didn’t anticipate, and you may have to go back to the drawing board. If you find these out after releasing early, before you’ve sunk a ton of time and resources into the product, it was a success. It won’t make you much money, and it won’t be encouraging, but it will have reduced your risk and kept you on the right path.
Let’s take a look at the three main reasons to release early and often.
Assessing your app’s chances.
Because web app development is relatively inexpensive, it often doesn’t make a lot of sense to invest heavily in market research. Instead, it can be cheaper (and always faster) to just build the thing and see if people respond. Of course, this isn’t categorical, and complex applications that require significant investment warrant more upfront research.
But if you have a simple idea and want to see how the market responds, release early. Call it beta. You’re basically making your prototype public.
Keeping your app’s feature set limited and realistic.
This addresses a problem I’ve seen over and over. The tendency of most startup founders is to fixate on a minor aspect of their overall idea that they think is especially cool. By committing to releasing early, you’re committing to a bare-bones feature set.
Which features are absolutely necessary for your application and business model? If it’s not essential, it’s out. This will give you time to focus on making those features rock-solid and really good. Releasing early isn’t an excuse to release a buggy, ugly, unusable product. Make sure each feature is simple and works as expected, every time. The more features you have, the harder it is to do this.
Getting rapid feedback.
The market’s going to give you feedback almost immediately, and this is when you’ll see the real advantage of the first two reasons. You’ve released a super-limited version of the product. People have started using it, so you know it’s viable. Now the market will help you decide which features come next.
In my experience (ten years of web app design and development), it’s next to impossible for people to correctly anticipate how people will use a product. Unless you’ve done a lot of customer research, it’s highly likely that the feature you’re in love with is not the feature your customers really want. (And even if you have done a bunch of research, it’s still 50/50.)
The more you focus on developing “down-the-road” features before release, the more likely it is that you’re wasting time and money, and the more likely it is that you’ll hide the real value of your product.
Shortly after launching, it’ll become clear which features are needed and which aren’t. These might be driven externally, by your customers, or internally, by your staff.
I remember one website we launched that had a very rudimentary user admin system. Three days after we launched, we started receiving hundreds of e-mails with questions about user accounts (the registration process was a little more complicated than your typical site). Thankfully, we had cut features before launch, so we had resources available to upgrade both the internal support features and refine the registration process. If we had focused on some random, unneeded feature, we wouldn’t have been able to address this core problem.
Guidelines for releasing early and often.
There’s not much to releasing early and often, but to get the most advantages, there are a few simple guidelines.
- Don’t rush. Releasing early doesn’t mean rushing it. It doesn’t mean you should foist buggy, incomplete software on your customers. To release earlier, you can either cut features or cut testing time. Don’t cut testing time. Cut features (this will cut testing time as well).
- Release quality. Since you’re releasing less, what you release needs to be awesome. There’s no excuse for releasing something riddled with bugs, and there’s nothing that will turn off your customer base faster or more permanently than a messed-up website.
- Prioritize anticipated features and create a plan. Because you’re releasing a product with a bare bones feature set, you’ll have a long list of features you want to add. Make sure this list is prioritized, and that your attention is focused on second-order features only.
- Gracefully handle feedback. You’ll receive two types of feedback: massive bugs that need immediate action and everything else. Most massive bugs will be caught in testing, but occasionally one will sneak through. When this happens, you need to fix it. Put everything else aside. Otherwise, accept the feedback and put it aside to review later. It’s tempting to think that every customer request requires immediate action, but this isn’t a tenable long-term strategy. Fire-fighting is lazy. Success requires discipline.
- Plan for your next release. Your next release should come soon, and you need to follow the same guidelines you followed for the first release. The next release should either be a simple bug fixing release, or introduce one or two new features. But don’t start yet! You’re still planning for it. Make sure not to rush it, and make sure it’s solid. It’s tempting to rush out a bunch of fixes or new features. Don’t! Consider all the feedback you’ve received and make decisions for the next release.
- Frequent, controlled releases. Make sure to test each release completely. As you add features, your application will become increasingly complex, will have more edge cases, and will require more testing. You can keep this manageable by controlling your feature set.
Effectively evaluating feedback and planning the next release.
When customers are clamoring for features, it can be hard to ignore them. Yet, this is exactly what you must do in the short term – don’t respond willy-nilly. Carefully evaluate requested features within the larger context of your business goals. What ROI will you receive on the feature? Is it absolutely necessary? Limiting yourself to one or two features per release really helps focus this conversation.
Often, you’ll receive all sorts of random feature requests. It’s especially important to take these with a grain of salt – every person uses the web (and your application) for slightly different things, and what’s vitally important to one user may go completely unnoticed to others. Oftentimes, the people with the most quixotic needs are the loudest. Don’t let them derail you!
Sometimes, you’ll receive a ton of requests for a feature that’s just way out in left field. Don’t ignore these! It’s quite possible that you completely misread the market and you need to be taking your product in a completely different direction. Obviously this isn’t a decision to be made lightly, but be open to it.
In the end, releasing early and often is a generally good strategy for a startup. It has risks, but they are often less than a longer process that doesn’t solicit market feedback until it’s too late. By staying focused and relaxed, you’ll reap the benefits.
Stop guessing: A guide towards deciding your next feature. I don’t agree completely (see above), but some good points.
Don’t Launch: why to avoid a big splash
Hey! This wasn't written by a consortium of crabs! It was written by Josh Orum, who does awesome work at Loud Dog, a digital branding firm in San Francisco that helps businesses express themselves authentically via identities, websites, and marketing collateral.
If you want us to do awesome work for you, if you have a question, or if you're just feeling lonely and want to chat, we want to hear from you!