Startup Seven: Confessions of a Repeat Entrepreneur

It’s been over a month since my last post, and so much has happened in that time. We’ve setup shop in downtown Palo Alto and are working through all sorts of interesting challenges as we chart the right course. I’ve always found that there are just a zillion decisions in the early days of a startup, and time just seems to fly by.

Perhaps one of the most important lessons that I’m reminded of every day is the need to make decisions quickly and move on. Every day, I try to move the ball forward on numerous fronts, whether it’s operational infrastructure (lease, legal, insurance, etc.), product decisions (features, platforms, data suppliers, etc.), business model questions, recruiting, customers, partners, marketing, etc. You know that circus performer with the spinning plates? That’s the startup CEO running back and forth between the plates.

An old friend and co-founder, Ted Barnett, is really good at this. Back at when.com, he would gather the right amount of data, make a decision, and move on. I’ve always admired his “decision throughput” and I think the key point here is to embrace the speed and not be afraid of making a mistake (the old “analysis paralysis” problem). You’re not going to get every decision correct when you are moving at startup speed. But for the sake of your team and your business, it’s critical to make these decisions as rapidly as possible while still applying good judgment.

Equally important is the ability to say “I was wrong.” I know certain people who could never allow these 3 words to leave their lips in that order, but are happy to use 2 of those words in the phrase “you were wrong” (you know who you are). Being able to recognize you were wrong and say so is not a negative–in my book, it’s almost a requirement for any businessperson, especially the startup founder. Not that you are wishy-washy and reversing decisions every hour, but when presented with new or contradictory data, you’re wiling to be open-minded, step up and say “I was wrong, let’s make a change.”

Finally, let’s not confuse speed with sloppiness. Speed is about making decisions and focusing on what matters, but that is not an excuse for poor quality. I’ve worked with teams who use speed as a crutch to say that poor quality is OK. Not in my book. Sometimes compromise is necessary–for example, having something partially working for an important demo–but the quality should always shine through even when features are missing. Move quickly, get tons done, prioritize, but keep the bar high.