Do More Faster India. Brad Feld
Читать онлайн книгу.
Many of their suggestions became the backbone of our company.
Finally, we had to turn our science project into a real company. Our philosophy was to meet with anyone and everyone we could. We never knew what experience or ideas would come from the people we met, and we believed people have a sneaky way of surprising you with the unexpected.
As we progressed, we realized that even experienced entrepreneurs forget to get enough feedback on their ideas. We regularly experienced this every time we used a piece of software or web service that wasn’t well thought out. Even as we became a more mature (although still very young) company, we still shared ideas early and often, not just with mentors, but also with our customers and partners. We hope that the advice we’re gleaning today will pay dividends as large as the ones we’ve already received.
Now that we get asked to give feedback to other startups we meet, we see a clear pattern. Many entrepreneurs are hesitant to share too much about what they’re doing and, even when they do, they hold back some of their thoughts when talking to people who could be incredibly helpful to them. These entrepreneurs overvalue their ideas. They should be doing the opposite and shout about what they are working on from any rooftop they can find. Getting feedback and new ideas is the lifeblood of any startup. There is no point in living in fear of someone stealing your idea.
David Cohen once told us that you can steal ideas, but you can’t steal execution. As first-time entrepreneurs, we quickly realized that we had many ideas every day—some good ones but many that were crummy. As we discarded the crummy ideas and started focusing on the good ones, we realized how difficult it was to implement them well. We concentrated—with our small team—on becoming execution machines, as we decided that this was going to be the key to turning our Franken-idea into something amazing.
By sharing our ideas with smart people, the early advice and feedback gave us a wealth of ideas and options to consider and a framework with which to address the important questions that arose while starting a business. It helped us get into Techstars, where we were lucky to build a network of people who understood and were involved with our idea to help solve the problems we faced on a day-to-day basis. As a result, we’ve found great mentors, made lifelong friends, and enabled ourselves to build a much better business.
Nate and Natty wouldn’t have been accepted into Techstars if they hadn’t been naturally good at sharing their ideas early and often and seeking feedback. When we met them six months before they applied to Techstars, we were skeptical because they were just two ex–Wall Street guys with no technical skills or experience. We kept in touch with them while they taught themselves how to program and made significant progress on the product in a short time. We were amazed and encouraged them to apply to Techstars. This was a direct result of Nate and Natty sharing their ideas with us early.
We are often asked if you have to be technical to start an Internet company. While it certainly helps, Nate and Natty taught us that it is not a requirement. They also showed us that if you aren’t technical, there’s no reason why you can’t learn how to be a software developer if you are a smart human who can learn how to sling code. Their story inspired Brad to write a series called “Learning to Program” on his blog.
Natty Zola from Everlater and Emily Olson from Foodzie celebrate doing more faster during the summer of 2009.
Chapter 7 Usage Is Like Oxygen for Ideas
Matt Mullenweg
Matt is a cofounder of WordPress and the founder of Automattic, the company behind WordPress.com and Jetpack. He also founded an investment and research company, Audrey Capital.
I like Apple because they are not afraid of getting a basic 1.0 out into the world and iterating on it. A case in point:
“No wireless. Less space than a nomad. Lame.”
—cmdrtaco, Slashdot.org, 2001, when reviewing the first iPod
I remember my first iPhone. I stood in line for hours to buy it, but the wait made the first time I swiped to unlock the phone that much sweeter. I felt like I was on Star Trek and this was my magical tricorder—a 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