tricorder that constantly dropped calls on AT&T’s network, had a headphone adapter that didn’t fit any of the hundreds of dollars’ worth of headphones I owned, ran no applications, had no copy and paste, and was slow as molasses. It had multiple shortcomings—just like the iPod when it first came out.
Now the crazy thing is when the original iPhone went public, flaws and all, you know that in a secret room somewhere on Apple’s campus they had a working prototype of the 3GS with a faster processor, better battery life, and a normal headphone jack—basically everything perfect. Steve Jobs was probably already carrying around one in his pocket. How painful it must have been to have everyone criticizing them for all the flaws they had already fixed but couldn’t release yet because they were waiting for component prices to come down or for some bugs to be resolved.
“$400 for an MP3 player! I’d call it the Cube 2.0 as it won’t sell and be killed off in a short time . . . and it’s not really functional. Uuhh, Steve, can I have a PDA now?”
—elitemacor, macrumors.com, 2001, responding to the original iPod announcement
Or, I wondered, was Apple really very Zen about the whole thing? There was a dark time in WordPress development history that I call our lost year. Version 2.0 was released on December 31, 2005, and Version 2.1 came out on January 22, 2007. From the dates, you might imagine that perhaps we had some sort of rift in the open source community, that all the volunteers left, or that perhaps WordPress just slowed down.
In fact, it was just the opposite—2006 was a breakthrough year for WordPress in many ways. WordPress was downloaded 1.5 million times that year and we started to get some high-profile blogs switching over from other blogging platforms. Our growing prominence had attracted a ton of new developers to the project and we were committing new functionality and fixes faster than we ever had before.
What killed us that year was “one more thing.” We could have easily done three major releases that year if we had just drawn a line in the sand and shipped the darn thing. The problem is that the longer it has been since your last release, the more pressure and anticipation there is, so you’re more likely to try to slip in just one more thing or a fix that will make a feature really shine. For some projects, this can feel like it goes on forever.
“Hey—here’s an idea, Apple—rather than enter the world of gimmicks and toys, why don’t you spend a little more time sorting out your pathetically expensive and crap server lineup? Or are you really aiming to become a glorified consumer gimmicks firm?”
—Pants, macrumors.com, 2001
I imagine prior to the launch of the iPod (or the iPhone) there were teams saying the same thing. The copy and paste guys were so close to being ready and they knew Walt Mossberg was going to ding them, so they must have thought “Let’s just not ship to the manufacturers in China for just a few more weeks.” They were probably pretty embarrassed. But if you’re not embarrassed when you ship your first version, you waited too long.
A beautiful thing about Apple is how quickly they make their own products obsolete. I imagine this also makes the discipline of shipping things easier. As I mentioned before, the longer it’s been since the last release, the more pressure there is. But if you know that your bit of code doesn’t make this version but the +0.1 is coming out in six weeks, then it’s not that bad. It’s like flights from San Francisco to Los Angeles; if you miss one, you know there’s another one an hour later, so it’s not a big deal.
Usage is like oxygen for ideas. You can never fully anticipate how an audience is going to react to something you’ve created until it’s out there. That means every moment you’re working on something without it being in the public arena, it’s actually dying, deprived of the oxygen of the real world. It’s even worse because development doesn’t happen in a vacuum. If you have a halfway decent idea, you can be certain that there are at least a few other teams somewhere in the world independently working on the same thing. Something you haven’t even imagined could disrupt the market you’re working in. Just consider all the podcasting companies that existed before iTunes incorporated podcasting functionality and wiped them all out.
By shipping early and often you have the unique competitive advantage of getting useful feedback on your product. In the best case, this helps you anticipate market direction, and in the worst case, it gives you a few people rooting for you who you can email when your team pivots to a new idea.
You think your business is different, you’re going to have only one shot at press, and everything needs to be perfect for when TechCrunch brings the world to your door. But if you have only one shot at getting an audience, you are doing it wrong.
After the debacle of the v2.0 to v2.1 lost year of 2006, the WordPress community adopted a fairly aggressive schedule of putting a major release out three times a year.
I love working on web services and pretty much everything Automattic focuses on is a service. On WordPress.com, we deploy code to production 20 or 30 times a day and anyone in the company can do it. We measure the deploy time to hundreds of servers and if it gets too slow (more than 30 to 60 seconds), we figure out a new way to optimize it.
In a rapid iteration environment, the most important thing isn’t necessarily how perfect code is when you send it out, but how quickly you can revert. This keeps the cost of a mistake really low, under a minute of brokenness. Someone can go from idea to working code to production and, more importantly, real users in just a few minutes, and I can’t imagine any better form of testing.
“Real artists ship.”
—Steve Jobs, 1983
When Brad first met Matt, they had dinner at a nice restaurant in Palo Alto. Matt was too young to drink—and admitted it. As a result, the other person they were dining with (Jeff Clavier, another Techstars mentor) and Brad had to drink all the wine. Brad fell in love with Matt and his vision for WordPress at that dinner and became a huge Matt and WordPress fan. (We became investors due to Automattic’s acquisition of Intense Debate, a Techstars 2007 company.)
Matt’s contribution to Techstars can’t be understated. In addition to spending time in Boulder as a mentor, he is a huge inspiration for any first-time entrepreneur who has a vision to create something transformational. And yes, Matt is now old enough to drink.
One of the key lessons from Matt for the startup entrepreneur is to get moving quickly. Founders often rely too much on ideas, when in reality they need to get out in the world and get moving.
Chapter 8 Forget the Kitchen Sink
David Cohen
David is the cofounder and Managing Partner of Techstars.
I’ve seen “everythingitis” kill many a startup. This is the disease a startup gets when it sets out to add more features than the competition does. It is a fundamentally flawed strategy that presumes that users will adopt a new service or product just because it has more features. Most people use a particular service, product, or technology because it does one thing really, really well. For example, a lot of people use their computer just to access the Internet and browse, although the computer itself has far more power than most people will ever use. Think about your own experiences and you’ll understand that this is true.
I’ve been guilty of trying to solve problems by throwing in more and more features, including the kitchen sink. iContact1 was the second startup that I founded, and it had a serious case of everythingitis.
