When I spoke with Amit Elisha of OutBrain a few weeks ago, we discussed the company’s software release strategy.
OutBrain operates under what’s considered the new Gospel of product development: get a basic version out there with a minimum number of features and maybe even a few known bugs, make it free, then let your users flood you with feedback so you can iterate and build your next version better.
Continue this process until you climb out of alpha into beta and eventually to a fully functional product (which, to follow Google’s prolonged beta label example, could take many years).
Jason Cohen
An interesting article by Jason Cohen, the founder of Smart Bear Software, on the On Startups blog challenges this methodology. Releasing too early and relying on the power of the crowd, he suggests, can potentially harm your reputation and potentially kill your product.
He uses the iPod as an example. Apple designed its game changing music device far away from the public eye. If it had been part of a release-and-iterate cycle, he says, could Apple possibly have gotten away with building a battery-powered device where you can’t change the battery! Or one without an FM radio (which was already included in many early iPod competitors – it’s finally been added to the new iPod Nano years later).
“Disruptive products by definition cannot be built by consensus,” he writes. “’’Design by committee’ is a sure-fire way to get mediocre design.”
Cohen presents additional points to back up his hypothesis.
- Startups often invoke the 80/20 rule that says you can implement just 20% of your features because that’s what 80% of your users want anyway. But Cohen says that doesn’t apply the way you think it does. The truth is that 80% of your customers use a different 20% from each other. So you need to push out more features, not less, to satisfy a larger cross-section.
- Twitter is often trotted out as a classic example of “get it out fast,” but it’s a bad one. While the service quickly gained a large and rabid following, it has been suffering from backend scalability problems ever since. Twitter has sufficient capital and some super-smart engineers who can work around the clock to fix what ails it, but your two-person startup may not be so lucky if you release before you’re ready.
- Customers don’t actually know what they want. “They’re much better at describing what’s difficult in their life, what frustrates them, or what takes up a lot of their time,” Cohen writes. But did anyone ever say “gee, I wish that I could send a video ringtone to my friends” (this is an idea that only a couple of smart entrepreneurs could think up).
Over the last 20 years, I’ve built or been a part of a team building a number of products. When I was working at CD-ROM developer Mindscape, I got into a huge fight with my boss over when to release a product that I had been toiling over for the better part of a year. The company had sales orders from its distributors, but I knew the product was still buggy and wasn’t ready.
Even worse, this was in the pre-Internet days; once the CD was shipped, it would take a new budget allocation to fix it, which I knew would be hard to obtain. When I was essentially given a choice – ship the product or pack your bags – I opted for prudence.
More recently, though, I fell victim to my own emotional involvement with a product that would have done better to release early and iterate. I got so caught up in getting it right, I didn’t realize that the business model was wrong, something that would have become apparent if users had a chance to kick the tires.
Two other examples from opposite poles:
1) Craigslist – if ever there was a bottom up, build it fast and they will come approach to web development, Craigslist would be the poster child. Of course, Craigslist got stuck after the first round of iteration – the site hasn’t been functionally updated for years, but it works and no one’s complaining.
2) The Apple Newton – this is not so much an example of slapped together product development, but it nevertheless demonstrates how a bad start can sink a product. The world’s first PDA came out in the early 1990s. It was a revolutionary product but “the handwriting recognition sucked and there weren’t a lot of apps,” Cohen explains. The public’s response: “it doesn’t do a lot and what it does do doesn’t work well.” By the time Apple addressed its myriad problems, it was too late.
Ultimately, there’s no clear-cut approach. I tend to lean towards the “you’ve got only one chance to make a first impression” direction but, as a number of comments on Cohen’s blog post argued, not every company is Apple.
“They have the money and market control needed to focus on building a complete product at the expense of time to market,” writes Paul May. “Few startups have this luxury.”
What do you think? Which direction is more likely to lead to success…or kill a company? I’d love to hear from you in the comments to this post.
{ 4 comments }
It’s happened to all of us at least once or twice in our careers. We’re writing a school paper or updating a website and we need a photo or graphic image to illustrate a point.
Why has the Flip video camera (and now its key competitor the new iPod Nano) been such as a roaring success? An article in the September issue of Wired suggests it’s part of a technology trend to build “good enough” products.