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.
{ 5 comments… read them below or add one }
I think release early and often is usually the way to go. With the Apple Newton, I don’t think the problem was that they released too early. I think they erred in thinking that natural handwriting was going to be a successful input method. Generally speaking I think we have to realize that we’re just not that smart. Get something to the users quickly, and then iterate. That first release can be revolutionary and paradigm-shattering. But it doesn’t have to be perfect.
full disclosure, I work @outbrain with Amit. IMHO the only true goal is to produce something remarkable that people will want and talk about. The remarkableness of a product is usually very simple and focused. If your first iteration accomplishes that, then you are way ahead of the game. How many startups “change” direction mid-flight? Many do, and by default these folks got it wrong the first time. If you are smart enough to launch with something remarkable, then fast release and adjust is wonderful as velocity increases on core KPI’s. From a VC perspective, sniffing out who has a nose for producing “remarkableness” quickly instead of a spaghetti thrower can make quite a difference.
Great post, Brian!
There is no one true answer here, you simply have to be smart about it. I actually agree with Cohen’s point: customers don’t know what they want (I think focus groups are useless if you just ask them what they want and not watch them use your product). This doesn’t mean you don’t iterate based on your customer’s “feedback”. Feedback doesn’t have to be explicit. Especially on the internet, it’s very easy to receive implicit feedback. You look at the bounce rate on specific pages, you monitor your customer service requests, what features you customers use more often than others etc. etc. There are also tools like “visitorspy” that let you actually watch a video of how your users interact with your site.
There is also a matter of core functionality – of course you can’t release a job site without being able to post jobs, search for jobs and post resumes. But a release doesn’t have to be a public one. You can plan your product to death but when you see the HTML – many things you didn’t plan on will start popping out. For me, I’d like to see some code out and let people interact with it, watching over their shoulder – friends, family, peers…
Also, the first users of your software, your “early adopters” are usually the tech savvy users that expect bugs. They like to provide feedback and if the core functionality is there and they like what you do – they will come back.
BTW – Apple DOES release fast and iterates. They are great at being focused on the most important features that will stun you. Look at the iphone – they have released 1st gen without 3g when the technology existed and used by most households in many countries. It was revolutionary enough in order to bring to market ASAP. Finding a solution to add 3g in a cost efficient way – do it next time. On the software side – they update firmware constantly. The focus on the core functionality, release the product and add “copy/paste” or MMS via firmware updates.
One more thing worth mentioning – Naughty Dog, a video game publisher, have released Uncharted 2 for the PS3. This game is the “iphone” of video games. Set the bar so high you can’t even see it :). In a recent interview to G4, Evan Wells (co-president) said that their secret was to not write a full/polished script and go from there, like most video game devs do. They had a general narrative, they wrote a scene, coded, watched users play it, received feedback (implicit), changed stuff around and went from there to the next one.
I’m by no means a proper geek – but I think there’s a difference here between web-based products (like Twitter) and gadgets / devices like the Apple examples. I have no idea why they are even placed in the same category for consideration of this question. I’m assuming that gadgets require so much more work to revamp / rerelease / remarket. There are trucks and planes and factories involved. Websites / web based apps – you can more or less change while the world sleeps and the masses wake up to a new feature or a fixed bug. It makes it logical, then, to take the cautious route with gadgets and the more open ended, rapidfire approach with internet co’s. I think a huge mistake web companies make is obsessing and letting fear masquerade as perfectionism. I’ve seen it lots of times. One company i was with was killed by it. By the time the product is released, someone else is there, funding ran out, everyone is exhausted, etc…and only THEN comes the user feedback. With gadgets, on the other hand, a bit of obsession and delay might save a lot of money later; failure might be too expensive, and a bit of caution justified.
“80% of your customers use a different 20% from each other” – I seriously doubt that, though it may depend on the specific application.
“Twitter is often trotted out as a classic example of “get it out fast,†but it’s a bad one.” – Yeah, I would hate to be as unsuccessful as Twitter. 🙂
“Customers don’t actually know what they want.” – well I kind of agree with this one, but this doesn’t really have anything to do with releasing fast and iterating.
Obviously you have to find the right balance, but I think the big advantage of releasing fast is you avoid wasting time building tons of features that nobody uses. And you get useful feedback while you’re building out the product, even if you don’t take what customers say they want word-for-word all the time.