Twitter is going public today. This is something many startups aspire to yet very few succeed in doing. My congratulations to everyone who has contributed to Twitter’s growth over the years. There are many people whose names will not be in the news today who at varying moments made this possible.
It is also a good point to remind oneself just why these successes are so improbable: because every startup goes on an Odyssean journey in which failure is generally closer than success. I often talk about the Scylla and Charybdis problem where you can err on both sides of pretty much any issue that a startup faces (e.g., you can hire too fast or hire too slow).
Having had a front row seat to Twitter’s journey and the journey of several other startups that have gone from a few people to hundreds of employees I am always amazed when it works at all. While some might interpret that as making the founders of those startups that succeed all the more heroic, I think it is a good reminder that all success in startups also involves a fair dose of luck.
The thing I am most happy about today though is the existence of Twitter itself. Active participation on Twitter has provided me with new connections to people and topics — hardly a day goes by where I don’t discover something or someone fascinating and I am sure today won’t be any different!
At MIT one of my statistics classes was taught by Prof. Jerry Hausman (of the Hausman test). In every class Prof. Hausman would at some point reach a result and then exclaim “and this proves that life is unfair” (usually it was that your statistical test had less power than you would have hoped for). Reading Nick Bilton’s Twitter story in the NY Times Sunday magazine reminded of that. I read it not because I expected to find something new but because it is always fun to see an event described in the press or in a book that one had front row seats to (in my case I spent a bit of time with the Twitter team shortly after USV invested).
So why does the Twitter story remind me of Prof. Hausman’s admonition? Because it demonstrates the relative importance of hitting upon the right thing at the right time over early execution. This goes a bit against one of the historic ideas held dear in venture capital that execution matters more than ideas. And yes it remains true that an idea alone is worthless, you have to build something. But beyond that it turns out that building the right thing at the right time will let you get away with all sorts of mistakes. Conversely, hypothetically perfect execution but too early or too late or on the wrong variant will not get you very far. For everyone working really hard on a startup that’s not going gangbuster this seems, well, unfair.
So there you have it. Prof. Hausman was right all along. Actually not quite. I used to think that but more recently I have changed my outlook to: Life just is. Unfair implies some kind of moral standard. Somewhere somebody right now is building the next big thing and most likely it is not you. Just accept that and you’ll be happier.
P.S. The Twitter story also shows that beyond a certain point even when you have hit a gusher (ie you built the right thing at the right time), you eventually need to build a real company. Inevitably many of the people who were there early on won’t be part of that organizational growth. That is a different kind of fair (or unfair) and does involve moral standards.
I am often asked about what has changed in Venture Capital and how that has impacted startups. Inevitably I answer that the right place to start when looking for impact on startups is Amazon. My line is: “Amazon has done more for startups than all early stage investors combined.” Why? Because founders can now generally get a service up and running on AWS with a close to zero upfront investment. And of course once you have something fundraising gets a lot easier and you probably have to sell a lot less of your company.
And now I am thrilled to see Amazon go one step further by offering their Amazon Activate program. In addition to all the stuff you can already get in the free usage tier they are throwing in a bunch of support and training. But where the numbers really start to get interesting is if you qualify for what they are calling the portfolio package — you have to be part of an incubator or accelerator or early stage portfolio. This program includes up to $15,000 in promotional credit, which is a fair bit of computing.
So if you are a startup in one of the qualifying programs I would highly encourage you to apply. And this is definitely a reason worth considering if you are thinking about joining an accelerator in the first place. Everyone running an accelerator or seed investing should make sure their portfolio qualifies (at USV we don’t do much seed investing but we are part of this nonetheless).
The last two Tech Tuesdays were about common blindspots for all engineering founding teams (marketing, sales) and ditto for all business founding teams (technology). In the comments Brandon asked “how many designer led companies have these problems”? The short answer is “it depends”! What does it depend on? What you mean by “designer.”
If by designer you mean someone who is in love with a pretty surface (UI) then I have actually seen both failure modes — failure to deliver the actual product (fear of technology) and also failure to market and sell (build it and they will come). And if that is not bad enough I have seen a third failure mode which is delivering and marketing a pretty product but one that nobody actually winds up using.
If on the other hand by designer you mean someone who cares deeply about how something feels and works for the customer then you have your best shot at avoiding all of these problems. There are three critical pieces here: feels, works and customer. The feels part includes how the product looks but also how it is marketed and sold (as that also impacts how people feel about it). The works part means appreciating the importance of the underlying technology in enabling that feeling. And the focus on the customer is what drives the usability and usefulness of the product.
It is that three way combination that marks the most successful companies. His astute sense for all three was also the hallmark of Steve Jobs. In their brand new (released today!) book “Customers Included" Mark Hurst and Phil Terry do a terrific job debunking the notion that Jobs created products without the customer. So yes, that kind of design is the best way to avoid the key traps I described in the two previous posts.
Later today I am giving a talk titled the “ABC of Startup Recruiting” as part of a speaker series that Susan is putting together for Ziggeo. This is the first time I am giving this talk and I am quite excited about it as this is such a critical topic for startups. The opening slide is a picture of Alec Baldwin from Glengarry Glenn Ross in the famous “Always Be Closing” scene. For startups and hiring the ABC instead stands for “Always Be Collecting Candidates.” I have found that the best entrepreneurs are always keeping a list of people they some day would like to hire. I also discuss how that motto applies all the way from putting together your founding team to growing past 50 employees.
My illustration of the founding team are the Beatles. They illustrate three things about founding teams. First, it’s often a very good idea to bring friends or at least people you know exceptionally well into the founding team (George Harrison was Paul McCartney’s friend). Second, even in the founding team you may eventually need to replace someone (Ringo Starr replacing Pete Best). Third, it’s OK to have inexperienced co-founders if the chemistry is right (the Beatles were teenagers when they got going!).
I then move on to early hiring as you go beyond the founding team but are still below 10 employees. Here I emphasize the importance of what I think of as startup attitude, which can be loosely summed up as “Keep Calm and Get Shit Done.” Actually both parts of this are relevant. Startups can involve a fair bit of stress and so having folks who can keep calm is important. And of course shipping product is essential even if the early versions are a bit embarrassing.
From there I go through the early growth phase which I characterize as going past 10 employees. In fact I single out the relatively narrow range from 10-20 employees. There are a bunch of reasons for that. This is when you first need some amount of structure in your organization (could just be loose teams). That in turn suggests you should start to hire with some job descriptions. Also you need to really make an effort on diversity because otherwise it will get a lot tougher going forward. And a very important point that people tend to neglect: you need to really start investing in onboarding. Put differently the 10-20 employee range tends to be where you should build the foundation for going from 20-50.
From 20-50 employees hiring become all about building and managing the funnel. I can’t overemphasize the importance of having a large funnel. Remember from the beginning: Always Be Collecting Candidates. This starts with social media outreach and includes speaking at conferences, recruiting on campus, etc. If you are succeeding in building a large funnel scheduling tools and screening tools (such as Ziggeo) start to play a major role. You want to track all candidates and get back to people at least with an email. But you want to focus your time on the most promising candidates.
I then wrap up the talk with a few points on recruiters and on hiring for senior positions. Those are meaty subjects on their own and I am planning to write future posts about these. The very final wrap up though is a reminder just how important hiring is. It should be one of the top three priorities for any startup founder.
Last Tech Tuesday I wrote about how engineering led companies sometimes underrate the importance of marketing and sales. One of the comments on Twitter pointed out that the converse is also often true and I replied that I will write a post about that, so here it goes. Many companies founded by a pure business team tend to struggle with technology and fail to deliver the products or services they envision. There are at least three distinct failure modes that I have seen here over time.
The first are teams that outsource their initial technology development entirely. By this I mean that they don’t have a truly technical person on their own team. This hardly ever works. I am sure people will post examples of successful counter examples but most of the teams I see who fall into this category are struggling mightily. Some of them fail to ever ship a product. Others ship something but it is delayed and a far cry from what they had in mind. Based on lots of experience my clear and unambiguous advice here is: if you don’t have a technical member of your founding team stop everything else you are doing and find somebody (I will have a separate post on how to do this). In many situations you would be better off not continuing at all if you can’t do this and instead take time out to learn enough technology yourself to build an initial version.
The second are teams that add a technical person early on but always treat engineering as a substitutable appendage to the company cycling through many engineering leaders and accumulating massive technical debt along the way. Things may look like they are going well initially, but over time the product development cycle for companies like this starts to slow down dramatically as the technical debt makes innovation harder and harder. Churn in the engineering organization also means that there is less institutional knowledge about why things were built in a certain way to begin with.
The third are teams that bring on board a technologist but then proceed to let that person build an engineering fiefdom that’s disconnected from the rest of the organization. The failure mode here tends to be an over-engineered solution that invests heavily in technological infrastructure before having found product market fit. There may be no technical debt here in the classical sense but it generally won’t matter because many of these companies never really get off the starting blocks.
The root cause in pretty much all of these situations is a lack of understanding of technology. It is unfortunately easy to go through business school and/or work on the business side of startups or large companies without ever developing any meaningful understanding of technology. That, however, is a recipe for mismanaging technology as it will translate into a fear of engaging and an inability to ask the right questions. If that happens to describe you, then you might want to go and read Tech Tuesday from the very beginning.
Today’s Tech Tuesday is a relatively short note on the “Bleeding Edge” — technologies that are even beyond the cutting edge. Every technology tends to start life at the bleeding edge with early releases that are unstable and poorly tested, many different ways of doing something (instead of an agreed upon best way) and with upgrades that are not backward compatible. It is tempting for startups to embrace bleeding edge technology for several reasons: first, you are starting from scratch, so why not use the very latest? Second, if it works out well it can give you a competitive advantage. Third, it can be a recruiting tool for people who want to get on the next technology trend.
Before you adopt the bleeding edge though, make sure you understand the downsides. In the worst case scenario you find yourself sitting on technology that is no longer supported at all. That will leave you with a tough decision between maintaining it yourself or migrating away. Even in the best case though you are likely to face changes that come from the external technology that force you to rewrite your code (because the changes are not backward compatible). There too you face a tough choice — if you stop upgrading you avoid any rewrite but in all likelihood you are not stuck with whatever version you have which at some point (often very soon) will no longer be maintained.
As a general rule then I suggest to folks that unless you absolutely definitively need it, wait to adopt a technology until it has started to settle down a bit with the vendor (or vendors) reasonably firmly established, the number of releases slowing down considerably and — most importantly — a commitment to avoid backwards incompatible changes unless absolutely necessary. The node.js project for instance seems to be settling down (there are drawbacks to this too as people who were hoping for a different module system were quick to point out), but in terms of adoption this is a big plus.
I already hinted at this topic in my last Tech Tuesday, when I wrote about having a healthy mix of young and more experienced engineers. More generally, diversity in engineering teams (and teams more generally) tends to be a healthy thing. Diversity helps prevent group think and provides for a better match with the wide variety of tasks that come up in the live of a startup engineering team. In the extreme if all you have are say realtime systems engineers your UI/UX is likely to be atrocious (exceptions to this notwithstanding).
Diversity is particularly difficult to achieve in engineering for two reasons. First, many engineering teams grow highly organically with people referring their friends. And that’s often a good thing because it can help identify high quality candidates quickly. But if you hire one person from say Google, you may wind up with a whole team of ex-Google people if you don’t pay attention. There is nothing wrong per se with hiring from Google, but Google does everything at scale and highly engineered whereas at a startup you often need to just make do with something a bit makeshift. So you want at least some people on your team who know how to do that and be comfortable with it.
The second reason that diversity is hard to achieve in engineering is that the applicant pool isn’t very diverse to begin with. So unless you make an effort you can wind up with a very homogenous team. For instance, it is not unusual to find startups with engineering teams with a dozen or more people and not one female engineer. Once you have reached a certain team size it actually gets much harder to become diverse. I went through this many years ago with a consulting startup in Germany where we grew to be about two dozen consultants and had failed to hire even one woman which made the place pretty uninviting to female candidates.
For an example of what making an effort means, you can read this great summary of how Etsy significantly grew the number of female engineers on their team. There are many pro-active things you can do, once you are focused on diversity. And the sooner you get going the better off your team will be.
It’s been a while since I have written a post in my Scylla and Charybdis series. As a quick refresher, the basic premise of the series is that startups are hard because on pretty much anything you can do too much or too little and the path to success thus requires navigating a narrow straight with deadly obstacles on both sides.
Today’s post is about listening. As an entrepreneur you can do too much or too little listening. How can you do too much listening you may ask? Well, by listening here I don’t mean the time spent having sound waves hit your ears but rather how much you change what you are doing based on feedback. It is very easy to make too many changes and to make them too quickly. As an entrepreneur almost everyone you meet will have an opinion on your startup and what you absolutely should be doing. That will range from someone insisting that you must have a specific feature to wholesale changes in strategy. Of course much of the advice you will receive will be contradictory to each other. And so if you listen too much you will be jerking your company around and building a bloated product.
On the other hand you can also listen too little. We all suffer from confirmation bias and it is easy to ignore feedback that doesn’t fit with our own view of the world. That’s particularly true for entrepreneurs who often don’t realize how hard it is for one of their employees to disagree with them. Feedback from board members is also easily ignored by young entrepreneurs (what do the “old folks” know about the new ways of the world and/or the view that only other entrepreneurs have valid opinions and not investors). Finally, the feedback that’s most ignored is that of the customer — far too few entrepreneurs spend time observing customers first hand (thankfully my friend Mark Hurst has a book forthcoming that addresses this point). It is by listening too little that entrepreneurs wind up running out of money or falling badly behind the competition.
Let me give a sailing analogy to illustrate the challenge. The ideal entrepreneur is like a sailboat captain who has a strong sense of the proper course to steer so as to not be buffeted by every piece of new information and yet capable of listening enough to understand when the ship has gone off course or the wind has changed to make a new course better.
I have written about prioritization previously on Tech Tuesday, introducing a prioritization heuristic and emphasizing the importance of a healthy mix of different projects. Today I want to add some point on how to think about competition in the context of prioritization. This is particularly important when you are in a somewhat crowded field and need to differentiate yourself from the competition.
What features should you prioritize when competing? Go back and take a look at the post on the prioritization heuristic first. Now think about the difference between going deeper on something that the competition has also versus working on something that the competition doesn’t have at all. The payoff to the latter is likely to be much higher and for less effort! When competing there is always the temptation to match competitors feature for feature and then pile on some more. In the diagram from the heuristic post think of that as going deeper and deeper along one of the directions with ever more diminishing returns.
The strongest position to take is to commit to just good enough along some dimensions and then pick the one differentiated dimension along which you will compete. For that it is best to choose something that changes the game as opposed to marginally improves on what competitors are doing. Or just short of that choose a dimension along which your competitors cannot easily follow you.
So what would be a concrete example? Self service sign up with aggressive pricing is an example of a dimension that would be difficult to match for competitors that are pursuing an enterprise sales model. Or if your competitors are all small startups with limited funding and you are well funded you might make infrastructure investments that give you a global footprint your principal dimension (eg building out a global network or marketplace where this is relevant).
Once you build out that dimension of your business you should also align your marketing messaging around it. That will set you apart from the crowd and everyone else is now playing catchup along that dimension. Another way you can think about that is: prioritize a dimension that you can “own” ie that can be uniquely identified with your startup.