Managing Startups: Best Blog Posts

Foreword

Since 2009 I've been publishing an annual compilation on my blog, Platforms & Networks, of what I deem to be the year's best posts by other authors about the management of technology startups. Readers have asked me to collect the posts in an ebook, so I was very happy when O'Reilly Media offered to do this. I was pleased, as well, to be able to donate my profits from the project to Endeavor Global, a terrific organization that supports entrepreneurship in emerging markets.

What I do. In my annual compilations, I've steered clear of news about product launches and funding rounds; likewise, I don't include posts that analyze trends in technologies or markets (e.g., big data, cloud computing, SoLoMo services). Instead, my focus has been on the management tasks that entrepreneurs must undertake when they search for a viable business model and then scale a startup. These tasks include the work done in the engineering, product management, marketing, sales, and business development functions. I pay special attention to ways in which functional managers leverage lean startup management practices. My compilations also cover a range of organizational issues; for example, dealing with cofounder tensions, recruiting and career planning, managing company culture, structuring the startup team, pacing the introduction of formal management systems and processes, working with the board of directors, and coping with the psychological pressures that inevitably confront entrepreneurs. Finally, I track developments in capital markets that are relevant to the management of tech startups; for example, the ebbs and flows of valuation bubbles and the proliferation of incubators and seed-stage funds.

Why I do it. I'm a business school professor who works closely with students aspiring to launch a startup or to work for one. My students are hungry for practical advice, and I've found that they learn a lot when I steer them to the wealth of insight available on the Web. As an educator, I feel fortunate to work in a field where practitioners are so eager to pay it forward by sharing their experiences and ideas. Over time, I started collecting posts for my own reference, and for sharing with my students. It was a natural step to curate these posts and publish the compilations. I discovered that there was interest in the lists that I'd curated in the broader entrepreneurship community.

How I do it. Readers of my blog have asked how I pick the posts for my annual compilations. There's no science in my approach: I don't use an algorithm that tracks traffic or social media mentions. Rather, I regularly read a few dozen blogs—mostly written by entrepreneurs and venture capitalists—and I follow links to other posts that look interesting. My criterion for flagging a post for future reference is simple: did I learn something that seems worth passing on to my students or to current entrepreneurs? When I publish my compilation, I ask readers to suggest other posts that I've omitted, and I always get some great additions. I'm sure, however, that I've missed plenty of posts that deserve to be included, and I apologize to their authors.

I want to thank all of the individuals who gave permission to have their work republished here. The generosity of the startup community is amazing, and these posts are invaluable to those of us who teach and coach aspiring entrepreneurs.

Tom Eisenmann, Editor

Chapter 1. How We Fooled Ourselves into Delaying Our Startup's Launch

Vinicius Vacanti I remember reading the first few pages of Steve Blank's book, The Four Steps to the Epiphany , and thinking two things:

This is not exactly a page-turner.
This is a really smart way of thinking about startups.

Soon after, I started attending the Lean Startup meetup in New York and reading Eric Reis's writings. I was a believer.

One of the main principles is to release an early prototype of your idea to potential users to get their feedback. But, despite being all in on the Lean Startup movement, we didn't do that.

Why Didn't We Release an Early Prototype?

Our current idea, Yipit, would find all the deals happening in your city (sample sales, happy hours, retail discounts) and would send you an email with the best seven, based on your interests and your location.

It would have taken us just a week to launch an early prototype.

We could have measured success based on whether people opened and clicked on the emails. We could have manually created the emails with deals we found and used MailChimp to send them out. There was no need to build any tech infrastructure.

But we came up with all sorts of excuses why we just couldn't release an early version.

Six painful months later, we finally put out the product. It didn't work—which was okay. What was not okay was realizing that our excuses for not releasing earlier were all wrong.

The Excuses We Came Up With

The bright side is that six months later, when we iterated Yipit into a daily deal aggregator, we learned to ignore the excuses and released a prototype in three days that took off right away.

Here are the excuses we made, and how we realized they didn't matter:

It wasn't good enough yet. We thought manually sending deals wasn't good enough. We were guessing and didn't really know. It turned out that six months later, the automated version full of features wasn't good enough either. We could have learned why it wasn't good enough six months earlier and spent that time actually trying to fix it. Instead, we just guessed why it wasn't going to work, and guessed wrong.
We didn't want to give a bad impression to those early test users. I can safely say that this doesn't matter. Those early test users just don't care. After we relaunched as a daily deal aggregator, we got exactly one email from a user saying they'd missed the sample sales. That's it. In fact, many of those early users enjoyed seeing our product develop.
It needed extra features. We thought we had to have a web view, people had to specify where in the city they lived, it needed to have links to the source of where we found the deal.... None of these were right. We were guessing. Had we launched in a week, we would have quickly realized these features weren't going to make a difference.
It was going to take us a few months to build the tech backend. We shouldn't have built it. We should have just used MailChimp to send the emails. For the next iteration of Yipit, we didn't build the backend. Users don't know what your tech backend looks like. Focus instead on getting the user experience right.
It needed to scale to accommodate hundreds of thousands of users. No, it didn't. We weren't going to get hundreds of thousands of users. Not anytime soon. We should have just been worrying about getting our first 1,000 users.
Someone will see what we're doing and copy it. If our idea had any merit, then there would have been at least 10 other groups of people out there also actively working on it. In fact, there were many groups of people working on a daily deal aggregator. But, because we launched in just three days, we were the first ones and got most of the press attention.
A potential investor will see it. I'm not sure if any investors actually did see it. But even if they had, it's not a bad thing. Investors like to see the progress you make as a product and as a team.
TechCrunch will write about us when we're not ready. They won't. We spent a bunch of time trying to get people to write about us, and they didn't. Also, in some crazy scenario where someone writes about our terrible prototype, I can safely say it won't matter in the long run. Startups succeed because they have a good product, not because they got good launch PR.

The Excuse I Didn't Admit

There's one more excuse I didn't talk about. I was afraid it wouldn't work.

I had quit my job. I had told my family and friends about the idea, and they were all telling me how much they believed in me. What if the idea was bad? What if I had to tell them it didn't work? What if I had to admit failure? You have to fight this feeling. The best way I've come up with is to think of a startup as an experiment, not as a business. Your early experiments are supposed to go wrong. Your goal is to find out what went wrong and iterate.

Lastly

For those of you that don't have an amazing excuse (like, you will be put in jail if you do this), please launch an early prototype. Not waiting to launch is, by far, the best advice I can give. Hopefully you'll listen more than we did.