Survivorship Bias in Startups

Confluence, from Hacker News, makes a great argument for why all advice given by successful startup founders should be taken with a grain of salt - statistical variability. Humans tend to create narratives around events, thereby turning random outcomes into events with perceived predictability.

I myself have been guilty of reading and listening to startup founders tell their stories to try to find a pattern that I can emulate for success (Jim Collins is a guilty pleasure). But the truth is probably closer to what confluence is preaching - there is a very limited set of commonalities in startup founders, and a lot of what we interpret as skill or foresight is more likely luck.

It is a must-read comment for anyone involved in startups. A choice quote:

[Taking lessons from successful startup founders is] like taking lessons from survivors of the Titanic on how to survive the sinking of a ship. It’s quite simple - be a young female child with a life vest and rich parents (or in startup land - a young upper-middle class male living in California during a venture bubble, a cyclical investment in the Valley with a convergence of secondary technologies, above average intelligence and a college degree from a reputable university). is fighting network effects

Dalton Caldwell’s audacious proposal has created quite a stir in the industry by proposing, a realtime feed API and service that you have to pay to use. As I understand it, it’s Twitter, but more focused on the API and protocol, and, obviously, it’s not free.

It’s refreshing to see such against the grain thinking, and based on the current sentiment against companies with no clear business model, I think this was only a matter of time. I would love to see this work, because I think it takes guts, and I think Caldwell is a smart and capable guy (see: Imeem, Picplz). But I don’t think it will, for the simple reason that relies on network effects, which is fundamentally at odds with an “everyone pays” model.

Paid models work really well for some web apps, the 37signals family of SaaS products being a prime example. Their products, however, do not rely on network effects to be successful. If I’m the only user of Basecamp, it wouldn’t affect me one whit. Facebook, LinkedIn, and Twitter, on the other hand, rely almost exclusively network effects. Most people do not use Facebook or LinkedIn on the basis of superior features, they use them because all their friends/contacts/potential employees are there.

That’s why those companies operate on a free-to-use model: they derive network value from the non-paying customers. It’s part of why I think Craigslist has remained so successful: most of its listings are free, which keeps the network/marketplace intact. In the case of Dalton Caldwell’s, he’s excluding from the network anyone who isn’t willing to pay for a realtime feed API service (read: almost everyone). That makes the network less valuable, even for those people who are paying for it, which results in fewer people willing to pay, and down the spiral it goes.

If Twitter (or could price-discriminate perfectly, charging nothing to the cheapskates, and a ton of money to those willing to pay it (in the real world, this often takes the form of freemium), then a paid model would work, but barring that, it collapses because the network, the real value, is missing.

Perhaps if caters to a specific niche that requires highly available realtime messaging - something having to do with swing trading or something similar would be interesting - they can find success outside of the mainstream. But based on the network effects that Twitter (and by extension relies on, a mainstream play doesn’t seem viable.

I wish Dalton the best of luck, and I hope he proves me wrong.

Ignoring the Wisdom of the Crowds

Ignoring the Wisdom of the Crowds

Crowd-sourced knowledge is often vaunted by technologists like Clay Shirky as a critical development to the future of humanity.

But while crowd-sourcing is good at some tasks, creativity, including the kind required to create an innovative product or company, isn’t one of them. Jason Cohen describes how in creative situations, the crowd finds the result that everyone hates the least.

For startups, eliciting emotion is critical, meaning the result that everyone hates the least is the one you absolutely want to avoid.

My first real product launch: Sweat, tears, and viral growth

3 weeks ago yesterday, I did my first real product launch. I’ve shipped apps before, but I’ve never done developed with a team, and I’ve never tried so hard to get support drummed up beforehand.

This time I did. I spent the 6ish weeks prior to launch developing a social web application in NodeJS with 2 other developers, a designer, and a business guy. We set a launch date ahead of time, and had a promotional team on the ground in our target market pushing people to our early signup page. We got great press, driving even more traffic. We had more people sign up early than I have ever had use one of my applications before, and this was the first time I’ve ever developed in NodeJS. It was exciting.

We planned a soft-launch the day before we were to send out emails to all of the early signups, to be able to start testing the product at some scale before it got out of control. Sunday at 4pm was our soft-launch, and Monday morning was the “real” launch.

One of the developers, the stronger NodeJS and mongoDB guy, had his sister’s wedding the weekend of launch, leaving me and our HTML dev to handle things during launch. Needless to say, we left way too much until the last minute, and the night before our soft-launch I was up until 5am trying to make all of our last-minute changes. The day of the soft-launch was dedicated to moving everything over to the production database and fixing the bugs that popped up during all those last minute changes I had made.

Of course, we ran into difficulties moving the database over, which consumed the better part of our morning prep (who knew that forgetting to drop old indices would cause the entire site to crash, but only on the second access?). Heading into the afternoon, everything on the site seemed to be crashing constantly, and I was living only on several cups of coffee.

Then at 3:30, I had fixed it. Nothing was breaking. Just in time for our 4pm launch. Our business guy was introducing the product to the 4pm soft-launch crowd of around 40 when I saw a horrible message scroll over the logs H10 (App Crashed). I gave him the kill sign, which he apparently didn’t understand, and he tried to log in to the app on the big screen. Everyone in the room started to chuckle when they saw Heroku’s “Application Crashed” screen.

I raced to fix the issue, which I don’t even remember now, and we finally got things underway. The next 3 hours I hardly remember, mostly because I was staring at the logs fly by, waiting for the app to crash so that the other dev could restart the server while I tried to quickly trace and patch the issue. I was so heads-down that a friend of mine didn’t even see me at the launch at all (see below).

The people at our soft-launch were very kind for their patience with our shaky product, and told us immediately of any issues they saw. That also meant that the moment an “App Crashed” message scrolled over the logs, the entire room filled with a chorus of users saying “crash!”. Most of it was property checking null or undefined variables, stuff that should have been caught much earlier.

Some of them were a little more complex, revolving around the data looking differently than we expected. For those of you who don’t know, NodeJS doesn’t play nice when you send two responses to the client. Turns out, looping through an array or object and triggering a res.render or res.send when certain conditions are met is a great way to crash the server if the data isn’t exactly what you expect.

The viral growth was much stronger than we anticipated, and our userbase grew from 40 to 500 in the next 6 hours[1]. Our business guy was ecstatic. My heart pounded seeing the logs scroll by faster and faster, but that made it even harder to watch for crashes and other obscure errors as they happened. I spent the 8 hours after launch fixing things, some of them much more obscure than others (Logging in didn’t work when you didn’t have a gender listed on Facebook, for one).

Launching was one of the most exciting things I’ve done, and also one of the most stressful. I didn’t eat until 9pm that night (Chipotle FTW), but hardly felt hungry all day. I must have sweated out a gallon of water, and I probably took a year off of my life. But it was awesome. To see people use something you’ve worked hard on feels great.

I only got a few hours of sleep that weekend, and spent the entire time working, and it was still one of the most rewarding and refreshing weekends I’ve had.

Lessons learned (most of I already knew but that didn’t stop me from making the mistakes anyway) :

  1. Don’t make changes the day before you launch.

  2. Test, test, test.

  3. The data will not be what you expect it to be.

  4. Calls to the database and external API’s WILL fail. Prepare for it.

  5. Install airbrake BEFORE launching

  6. Set your expectations low (in user numbers), prepare yourself for the worst (out of control growth).


Startups Are a Better Way to Get Work Done

In the closing session of Techonomy 2011, Sean Parker (of Napster and Facebook fame) talked about the surplus of early-stage funding in Silicon Valley. Parker said that one of the end results of so much early-stage capital is that too many talented people are starting their own companies instead of working at established players like Facebook, Google, Microsoft, etc. In his own words, “this results in a talent drain where the best talent gets diffused.” (The story was covered on TechCrunch, All Things Digital, and PCMagazine)

That statement seems to indicate that in terms of technological progress or societal impact, the best talent is better off working at the established players rather than at their own startups. To be fair, Parker was being intentionally contrarian instead of giving the “standard technocrat viewpoint”, but the implication behind that statement is one that is shared by many in the business community at large.

The theory is that at a large organization with access to resources and the ability to collaborate with one another, teams of people who would normally have little impact are able to make a large impact (either on technology, society, or both). Underlying that notion is a more basic one: that large institutions are the best way to organize people toward a common goal.

That’s not the case, at least not anymore. Institutions require a bureaucratic structure to keep the efforts of all the individual workers within it, who are not exposed to the same market forces as the institution, aligned with goals and efforts that will ultimately benefit the institution as a whole. This creates a lot of additional work for the institution (and meetings, and everything else dreadful about institutions) without creating additional value.

In a startup, the need for a bureaucratic structure disappears because everyone involved is so close to the market forces. Everyone’s effort in a startup is directed solely at the company’s survival, which, because of the proximity to the market, is equivalent to creating value for the company, and the company’s customers.

Not only does a startup remove extraneous work, but it also increase motivation. This makes sense if you consider that in a startup, the reward for success is enormous, and the effect that each worker has on the outcome is large. But even more telling is that according to social scientists, financial rewards aren’t the greatest motivator, especially in creative (i.e. innovative) work. Dan Pink at his TED talk in 2009 explains that for right-brained work, the kind of work that doesn’t have a clear set of rules or a single solution and requires creative thinking to solve, contingent rewards (if you do this task, you get this reward) don’t help, and actually hinder the work the being done. He quotes a study by the London School of Economics that found that “financial incentives can result in a negative impact on overall performance.”

Pink goes on to explain that the real motivators for creative work are autonomy, mastery, and purpose. A startup mirrors that model of motivation almost exactly. In a startup, the level of autonomy you are given is second only to actually working for yourself. Mastery, “the desire to get better at something that matters,” is ever-present in a startup, where you are constantly improving your skills in doing something that you have already decided matters a great deal. Purpose, “the yearning to do what we do in service of a higher purpose,” is nearly always present in a startup, where passion for solving a particular problem is just as important as the financial resources to do so.

In a startup, you have better motivation, and you have stripped away non-value creating work: how could this not be a better way to organize people toward a common goal? The common answer is the inability to collaborate on large projects. Startups are great for small (from a technical standpoint) projects like Twitter or Foursquare, but for large projects, you need a large group with the ability to collaborate.

But in today’s world, that collaboration exists without the need for the institution. It is almost a rule in startupland that your service must have a public API. This allows services to piggyback off of each other and “collaborate” without ever communicating, and, even better, without ever going to a meeting. And how many fantastic, value-creating services have we seen spring up as a result of public API’s? How many more will we see if this trend continues?

The startup model consists of taking a tiny piece of what could be a company and exposing it to market forces while it is manned by a self-selecting group of highly driven, highly capable individuals. In today’s world where collaboration doesn’t require institutions, it’s a better way to organize people to do work, and it results in more much innovation and societal impact. I don’t believe in the 20th century model of institutional management, and I think we are moving toward something better.

Inspiration for this post comes from Paul Graham’s essay, “How to Make Wealth.”