I am generally not a big fan of strategies that involve pursuing business A now in order to pursue B in the future. I tend to believe that you should go for B right away. For example, if you are planning to disrupt textbooks I would likely prefer a strategy that figures out how to peer produce those instead of one that first tries to make the renting and exchange of existing textbooks more efficient. Why? Because there are few businesses that have pulled off the “A now, B later” trick — most everyone simply gets stuck in business A. Netflix is one the few that pulled it off. They first shipped DVDs and now successfully stream (even Netflix they almost botched the transition).
Two possible justifications come to mind for the “A now, B later” strategy. The first is technological progress. When Netflix got started, streaming was not yet a truly viable option. The second one is behavior change. When Amazon first got going, buying online was enough of a change for people. It would have been too much to also ask them to do so in a marketplace and so Amazon chose the commerce format. Bezos smartly picked books where an online store had big advantages over a brick and mortar one.
This latter justification seems particularly relevant when looking at healthcare opportunities. After many years of content sites a la WebMD we are now seeing a great many startups that want to actually provide care. This ranges from medical Q&A sites all the way to telemedicine applications on mobile phones. Going to the computer or your phone for a consult rather than a flesh-and-blood doctor is a big behavior change. That suggests that an Amazon like strategy where you start with commerce and only introduce a marketplace later may be the winning model.
So what would a commerce model a la Amazon look like in healthcare? It would be a branded service that provides diagnosis, prescription and if necessary referral. The service would use some combination of texting, possibly video chats / image uploads, and use of existing lab networks (eg for blood analysis). The logical entry point would either be primary care in its entirety or a large specialty such as dermatology. I believe the right service could quickly grow large, especially if it can be priced in a way where insurance reimbursement becomes a secondary consideration. The subsequent marketplace would be for cases that require a specialist or treatment other than prescriptions.
I am curious to hear from others whether they buy this argument about a commerce model coming first or think we will go straight to a marketplace. Also, if you know of any startups pursuing the commerce model please let me know.
Susan and I are trying something new: we are offering an online pitch practice aimed at women entrepreneurs. Susan came up with this idea based on working hard to hone her own pitch for Ziggeo (which is also the platform we will be using to power this). We are both big believers in the importance of deliberate practice and feedback is an essential ingredient to this. Giving feedback asynchronously on a recorded pitch is an experiment — if it goes well, we will figure out how to repeat and/or expand it.
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.