Do More Faster

by Brad Feld

  About those pesky and annoying customers that alerted me to the problem? I’m grateful that they raised the issue, and so are the over 150,000 SendGrid customers who are benefiting from our service!

  Many Techstars founders—like Isaac—are deeply technical. As you have just read, SendGrid emerged from a specific pain that Isaac encountered in a previous job. While Internet email has been around for a very long time, and commercial Internet email has been around for more than 20 years, new issues continue to arise. Isaac took a fresh look at the problem as a user and realized that even though there are many companies addressing different aspects of email, no one was solving the specific problem he faced.

  When we first met Isaac, we knew that he was a technical rock star and had done some clever things, but we didn’t realize the breadth and impact of the approach he was taking to solving this problem. Furthermore, neither did he. It wasn’t clear how much people would be willing to pay, if anything. We encouraged Isaac to get out there, talk and listen to customers, and sign them up!

  As a tech guy, Isaac wasn’t comfortable dealing with customers; he would rather sit in front of his computer and hack on code. But we, and his Techstars mentors, pushed him to go talk to people. At first, he talked to other software developers, people he was comfortable with and who typically came back with uniformly positive responses. Then he started talking to nontechnical executives of other web companies who were equally enthusiastic. Within a few weeks, Isaac realized how powerful it was to talk to the early users, as they all quickly signed up, started using SendGrid, and gave him immediate feedback on their specific pain, resulting in a much more relevant product. Billions of emails later, it’s clear that SendGrid solves a very real problem.

  Isaac’s experience (look for the pain) is one of the most common approaches to starting a business. Where is the pain? Look for things that frustrate you. Search for situations where you can’t get things done easily or quickly or where things are inconvenient, involve red tape, or are expensive. You don’t even need customers to look for pain—it can come from your own experience or from random people you meet. But solving for a specific pain is one of the surest ways to create a sustainable business.

  Isaac Saldana focused on values by creating SendGrid’s four Hs. Isaac has since joined Techstars as a leader at Techstars Studio.

  Chapter 6

  Get Feedback Early

  Nate Abbott and Natty Zola

  Nate and Natty are the cofounders of Everlater, an easy and fun way to share your travel experiences. Everlater raised capital from Highway 12 Ventures after completing the Techstars accelerator in 2009. Everlater was later acquired by AOL/Mapquest. Nate is now head of product at Front and Natty is currently the managing director of the Techstars Boulder accelerator.

  When we set out to build a travel website, we were two finance professionals with zero practical knowledge of software development or how to run an Internet company. We didn’t know what we didn’t know. So, as an absolute necessity, we set out to share our ideas early and often with as many smart people as we could find.

  First, we reached out to any of our friends and family who would talk to us. While our network wasn’t rich with savvy Internet personalities or experienced engineers, we knew a lot of folks who wanted to see us succeed—and most of them traveled! We talked to them about how they found hotels, whether they liked scrapbooks, and whom they trusted online. We shared our opinions and received loads of feedback. From this, we stitched together a Frankenstein monster of an idea from our experiences, perceived market needs, and the invaluable advice of friends and family.

  With our Franken-idea in hand, we set out to implement it. However, since we were new to programming, we had no experience and few resources with which to teach ourselves. As a result, we turned to the developer community with questions and open minds. Without their support, guidance, and ideas, we would have been lost. It also made our project more fun, as we got lots of smart developers helping us to realize our idea. 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 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 co-CEO 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. I proudly told everyone that iContact did more than any other mobile social networking product that existed at the time. Basically, iContact was a mobile social network that solved the problem of knowing what your friends were up to—Foursquare before it existed. But the market said: “So what?” No one, including us, understood the one thing iContact did better than anybody else in the world. When it didn’t take off, we made the fatal mistake of responding by adding more features (including several shiny new kitchen sinks). In retrospect, we probably should have been removi
ng features and focusing more on the few things that our users did like. iContact eventually died, and that’s how I learned this lesson firsthand.

  Several Techstars companies came in with a plan like “Yelp + Facebook + YouTube + kitchen sink.” We coached them early on that they have to be the best in the world at one thing and then build from there. We ask them to focus on their passion and to pick the smallest meaningful problem that they can solve better than anyone in the world.

  I love what Ev Williams (founder of Blogger and Medium and cofounder of Odeo and Twitter) says about this:

  Focus on the smallest possible problem you could solve that would potentially be useful. Most companies start out trying to do too many things, which makes life difficult and turns you into a me-too. Focusing on a small niche has so many advantages: With much less work, you can be the best at what you do. Small things, like a microscopic world, almost always turn out to be bigger than you think when you zoom in. You can much more easily position and market yourself when more focused. And when it comes to partnering, or being acquired, there’s less chance for conflict. This is all so logical and, yet, there’s a resistance to focusing. I think it comes from a fear of being trivial. Just remember: If you get to be #1 in your category, but your category is too small, then you can broaden your scope and you can do so with leverage.

  Ev’s last point is key. If you’re the best in the world at thing X, it’s much easier to get to X + Y. You’ll have credibility from your customers who already love you for what you do so well. They’ll be patient and willing to help you build Y. It’s a place of strength, and it can be so much easier to do more from there.