garry’s posthaven

I got an email from a founder recently who wanted to help create software so that you could find other cofounders. It's a common idea that is so frequently attempted that I usually try to dissuade people from working on it. This is what I wrote him: 

It is usually the right thing to create something you yourself would use. Finding cofounders is a common problem that founders face, but it is probably a special case exception to the guideline. There probably aren't enough people who want to do startups, and you won't be able to make enough money from those startups to actually support your business. 

I would suggest that you work more on things that a lot of people in your world can use. If you could pick anything, the ones that are most valuable tend to come from there. 

There are probably specific aspects of your local economy and markets that you know about that nobody else knows about. Make software to solve those problems. For instance, I've met founders in the past who have backgrounds in the an unsexy business like textiles, or manufacturing. They end up making marketplaces or management software that make those kinds of operations a lot more efficient, and they're the only ones who can do it because it is rare for someone who knows how to code who also understands all the ins-and-outs of that particular industry and use case. 

You can think of this being true for any economic activity: banking, real estate, retail, wholesale, shipping, food, entertainment, transportation. There is an infinite amount of software just waiting to be written, around use cases that people actually want and care desperately about. That's what you should focus on. 

People are up in arms about the Oculus Rift selling to Facebook — some like the normally reasonable and insightful Barry Ritholtz are livid that people paid to the tune of $2.4M in presales and aren't sharing in the equity returns. 

I bought an early Oculus Rift developer kit as a part of the Kickstarter. I paid $300 for it and it was worth every penny. I had no expectation of equity from it, because the product was cool and something I wanted. It's the wrong thing to criticize Oculus Rift for the simple reason that hardware crowdfunding has unlocked a whole new world of things that could be built if only you could prove people want it.

The crowdfunding campaign Oculus Rift ran proved people wanted it. We see this over and over again — if you can create a new class of consumer behavior (Uber, Google, etc) then you can create a valuable company.

Articles like this are sensational in that they sometimes incite misguided lawmakers to regulate. But in this case, crowdfunding is creating new economic activity, and any new regulation would actively squelch that — and kill viable new products and companies in the process.

In 2009 I wrote a blog post here about advice for startups applying for YC. Little did I know years later I'd become a partner at Y Combinator and have the chance to shape hundreds of new startups since then. 

I thought I'd refresh that article since five years is a long time. Here are my six tips for applicants, updated for 2014.

1) YC is a multiplier for companies, both early and late. 

The most common question I get from teams is wondering whether they are too early for YC, or too late. I think YC can help any company prior to Series A. 

YC teams span the gamut. Some people are just out of college and might only have an early prototype. Others might have already raised a seed round and have real revenue and employees. Some of the YC companies who have done the best (e.g. Crowdtilt, Thalmic Labs) came into YC having already raised seed rounds. They do so well during YC that they have gone on to raise competitive Series A and subsequent rounds of funding right out of demo day. It turns out to be a multiplier on success. 

On the other hand there are teams that are just super early. That's OK too. If this is your first money you're seeking, realize that this is unlike a summer program or getting an internship. You're committing yourself to building a serious business, and you're telling your investors that you're going to do what it takes to returning their money plus a healthy return. It's not a grant. We do startups because we want to create massive value, reward ourselves and reward the people who help us create that value. 

2) Solve a hair on fire problem, or do it right

Great hackers get caught up in technology, but technology doesn't create value in and of itself. Technology is only useful for solving people's problems. 

One of the first pieces of startup advice I remember coming across was Paul Buchheit talking about startup ideas. Successful ones fall in one of two categories:

• They either solve a hair on fire problem that has never been solved before
• OR they solve a problem that has other solutions, but they do it so much better that they are "done right."

We use software to get things done. We hope these products will help make our lives better, and that's why it's such a blessing to be a software engineer and startup founder. There are an infinite number of things we can make that potentially make things better. Yet as software creators, we fail — over and over and over again. 

Just in the past day, two big brands failed me in major ways through poor software engineering. Last night I bought an Xbox One game and tried to play it. I let it try to install overnight. The software is stuck now — complaining the installer hit network connection issues and won't continue, even though clearly the Xbox One can connect to the Internet. There's no retry button. I'm in a broken state and I don't know how to resolve it. This is a pretty basic use case that is completely broken. 

This morning, I tried to use Silicon Valley Bank's new deposit-by-mail feature. First off, it took me over a week and two emails sent in order for them to enable it on my account. I shouldn't need emails to enable a feature like that, let alone wait a week. Then, when they finally did enable the feature, it didn't work at all for the handwritten checks I needed to deposit. The error? "The amount doesn't match the check image." The engineers probably used some off-the-shelf OCR system that barfed on handwriting. There's no workaround. Yet handwritten checks are a pretty core reason why someone would use a mobile phone app to deposit a check. The core use case is completely broken. 

This is the inflatable hammer problem in a nutshell — too often, we are given tools that cannot be used for their described purpose. They're broken in fundamental ways. 

In the end, SVB and Microsoft suffer from broken product and engineering organizations. These organizations have plenty of resources to make these simple core scenarios work. But it's not a resource issue. These failings usually happen because designers and engineers who actually make the software are divorced from the management organization that sets the deadlines. There's no sense of ownership — merely hitting milestones and knocking off items on a to-do list. I hit my goals — ship it and let's get a beer. 

Large orgs also make the mistake of insulating their product and engineering people from the people who actually experience the pain. There are layers of engineers and management and emails go to account managers who can't do anything about it and don't know anyone who possibly could. When I was a PM at Microsoft, the only interaction I had with end users was reviewing Windows Mobile help newsgroups once a quarter. It was like wading through an ocean of pain. It was so sad and ugly to look at, and that was the software we were making — that was the pain we were inflicting on our users.

Silicon Valley is obsessed with the auteur-CEO for good reason. When MobileMe shipped crap, it wasn't OK with Steve Jobs and clear action was taken. When idiotic product decisions are made, it takes someone with power to lay the smack down and enforce a culture in which that kind of thing isn't acceptable. 

Startups don't have a creaky old dumb organization yet — it's just founders, right? Yet startups ship bad software all the time. Why? Well, founders have limited time, and the advice to ship-fast/fail-fast is a strong driver. We ship software when the basic case works at all. This is probably still the right thing for people do. But then founders forget to fix things that are broken. The moment your software works at all feels like you're 80% of the way there, but you're really at 20%. A great product is made, not born. 

Startups have an even greater chance of success at products because they can listen to users. You don't have many, so you can actually read and answer every email you get. Take a page from Wufoo, who made their engineers and designers do support every single day. This is the best thing you could possibly do. Connect with the pain of your users, and fix the papercuts, no matter how small. That's how you get to a great product. 

Don't make the same mistake the big orgs make. If it sucks, cut scope or slip the schedule. Don't cut quality and don't strand your users in frustrating bugs in core scenarios. Fix it and make it better. Listen to users. Fix it. Repeat. 

SVB and Microsoft can endure a lot of failure before it affects their bottom line. They've got a lot more things going for them — one is a bank, and the other has a few durable monopolies that have decades of life on them still. But for startups, all you've got is whether the damn thing works. So ship it and make it better. 

In early 2013, I posted results from Survata that indicated that teens really did use Snapchat, Instagram and Tumblr. About one year later, Survata ran the survey again, and this is what they found. 

A year ago, only 13% of teens used Snapchat at least several times a week. That has since increased to an incredible 39% as of January 2014. These are very impressive numbers alongside social media stalwarts Facebook, Instagram, and Twitter. 

I've heard some Valley insiders note that the growth and traction numbers for Snapchat would justify valuations of upwards of $20B if you used comparable metrics from valuations of Asia-based messaging services like Line. 

The attention economy continues to evolve, and not all the spots on the social media periodic table have been filled quite yet. An upstart with a unique model that taps real user behavior can still gain traction in an incredibly fast rate. 

As a side note, YC-backed Survata remains a really valuable tool to gain insights and run surveys against lots of Internet users quickly. See the full methodology for their teen social media study here.

Everything that used to be fax machines, contracts, and invoices and purchase orders in triplicate are going away. What's replacing it? The API.

Before Stripe, you had to fill out a ton of forms and get approval to get a merchant account. Now you can sign up on a website and make simple REST API calls. Before Twilio you had to go through similar hoops just to be able to work with phone numbers. Once again, the API prevails, and whole new capabilities are unlocked. 

Recent YC company Lob is bringing this same kind of capability to print anything — on any kind of paper, any size, and mail it to anyone — all via a simple REST API. This is a big deal because paper is actually still the interface for the rest of the world — the rest of the world that still uses paper contracts, paper checks, and paper invoices. The company is already printing millions of dollars worth of checks!

Think about most of the bad customer interactions we end up having to have on a typical day — to do anything in business, really. We get on a phone and we get voicemail. We wait a few days for our purchase order to be approved. If software is eating every industry and every type of economic activity, then the force that is replacing it is actually software talking to other software. That's the API.

This world has been a long time coming. We've heard enough about e-business thanks to huge ad budgets by enterprise IT consultant behemoths! But rather than those huge wasteful IT firms, the people bringing it to us are the hacker-oriented dev-savvy API companies like Stripe, Twilio and Lob. Where there is paper to push, a call to answer, or a purchase to approve, there is an API coming to replace it. 

One of the first lessons Cus D'Amato taught Mike Tyson was about fear: 

“Fear is the greatest obstacle to learning. But fear is your best friend. Fear is like fire. If you learn to control it, you let it work for you. If you don’t learn to control it, it’ll destroy you and everything around you.

“You think you know the difference between a hero and a coward, Mike? Well, there is no difference between a hero and a coward in what they feel. It’s what they do that makes them different. The hero and the coward feel exactly the same, but you have to have the discipline to do what a hero does and to keep yourself from doing what the coward does.”

Earlier this evening I was debating whether or not to eat a Drumstick, one of my favorite ice cream treats. I really wanted it, but some other part of my brain short circuited that decision and said nope, fatass, you're not having it. I felt viscerally torn. I had some desire that must have emerged from the neurons of my brain having to do with eating, and I had to override those desires using some sort of higher order logic around the fact that I lead mostly a sedentary existence and reallly don't need those calories at 2AM. 

Shortly after that internal debate was won, I happened on an interview with Tufts University Professor of Philosophy Daniel C. Dennett that pointed out perhaps those cells really are warring: 

Each neuron is imprisoned in your brain. I now think of these as cells within cells, as cells within prison cells. Realize that every neuron in your brain, every human cell in your body (leaving aside all the symbionts), is a direct descendent of eukaryotic cells that lived and fended for themselves for about a billion years as free-swimming, free-living little agents. They fended for themselves, and they survived.    

It's an interesting thought experiment. At some point, single celled organisms started banding together. Oh, you know, about 1 billion years ago (clipped from an amazing infographic recently at waitbutwhy.com): 

After about 400 million years, those few early multi-cellular lifeforms got progressively more advanced, resulting in the first fish about 500M years ago, then insects 400M years, then reptiles 300M years ago, then mammals about 200M years ago.

So that's a lot of years for things to progress from just a few cells going on a date to now about 50 trillion cells coordinated in unison in any given human body! Though perhaps the most important part, the brain, consists of somewhere around 100 billion of them. 

So that's wild. The experience of one human being, my experience, and your experience, seems to be the product of 100 billion neurons working together — fighting, debating, forming alliances, and ultimately making decisions. 

That gives me some hope for humanity overall, then. If 100 billion in-it-for-themselves descendants of selfish eukaryotes can work together for the greater good, whatever it is you choose it to be — then perhaps 7 billion people can do the same for the humankind. 

Kansas City sportswriter Martin Manley committed suicide yesterday at the age of 60. Before his death, he posted a website explaining why he did it. He still had his health, his mind, and felt that he had contributed everything he could to society at that point. 

On why he posted his website, he writes: 

It’s incredible what is lost to history. Even one generation back, so little is really known about the vast, vast majority of people. It’s a shame - especially considering existing technology has enabled us to store everything ever said, done or thought by every person on earth a thousand times over. There is no reason lives have to continue to be forever forgotten. Everyone can be remembered if they put in the effort to be remembered in some concrete form rather than simply being dependent upon fading memories of those who knew the deceased person.

In 2009, a brilliant software engineer Sergey Aleynikov was arrested by the FBI at Newark Liberty International Airport. The allegation? He stole Goldman Sachs source code, about 8 megabytes of it. But it wasn't purely GS code — It was open source code mixed with Goldman Sachs proprietary code. If anything, if the source code was LGPL or a similar license (common among open source projects), Goldman Sachs was actually supposed to release this code back out to the community.  (Clarification: If the binary is distributed, it must be released back. Not required legally in this case.)

In Vanity Fair, Michael Lewis writes:

Serge quickly discovered, to his surprise, that Goldman had a one-way relationship with open source. They took huge amounts of free software off the Web, but they did not return it after he had modified it, even when his modifications were very slight and of general rather than financial use. “Once I took some open-source components, repackaged them to come up with a component that was not even used at Goldman Sachs,” he says. “It was basically a way to make two computers look like one, so if one went down the other could jump in and perform the task.” He described the pleasure of his innovation this way: “It created something out of chaos. When you create something out of chaos, essentially, you reduce the entropy in the world.” He went to his boss, a fellow named Adam Schlesinger, and asked if he could release it back into open source, as was his inclination. “He said it was now Goldman’s property,” recalls Serge. “He was quite tense. When I mentioned it, it was very close to bonus time. And he didn’t want any disturbances.”

Open source was an idea that depended on collaboration and sharing, and Serge had a long history of contributing to it. He didn’t fully understand how Goldman could think it was O.K. to benefit so greatly from the work of others and then behave so selfishly toward them. “You don’t create intellectual property,” he said. “You create a program that does something.” But from then on, on instructions from Schlesinger, he treated everything on Goldman Sachs’s servers, even if it had just been transferred there from open source, as Goldman Sachs’s property. (At Serge’s trial Kevin Marino, his lawyer, flashed two pages of computer code: the original, with its open-source license on top, and a replica, with the open-source license stripped off and replaced by the Goldman Sachs license.)

He agreed to hang around for six weeks and teach other Goldman people everything he knew, so they could continue to find and fix the broken bands in their gigantic rubber ball. Four times in the course of those last weeks he mailed himself source code he was working on. (He’d later be accused of sending himself 32 megabytes of code, but what he sent was essentially the same 8 megabytes of code four times over.) The files contained a lot of open-source code he had worked with, and modified, over the past two years, mingled together with code that wasn’t open source but proprietary to Goldman Sachs. As he would later try and fail to explain to an F.B.I. agent, he hoped to disentangle the one from the other, in case he needed to remind himself how he had done what he had done with the open-source code, in the event he might need to do it again. He sent these files the same way he had sent himself files nearly every week, since his first month on the job at Goldman. “No one had ever said a word to me about it,” he says. He pulled up his browser and typed into it the words: Free Subversion Repository. Up popped a list of places that stored code, for free, and in a convenient fashion. He clicked the first link on the list. The entire process took about eight seconds. And then he did what he had always done since he first started programming computers: he deleted his bash history. To access the computer he was required to type his password. If he didn’t delete his bash history, his password would be there to see, for anyone who had access to the system.

...

The story the F.B.I. found so unconvincing—that Serge had taken the files because he thought he might later like to parse the open-source code contained within—made complete sense to the new jurors. As Goldman hadn’t permitted him to release his debugged or improved code back to the public—possibly in violation of the original free licenses, which often stated that improvements must be publicly shared—the only way to get his hands on these was to take the Goldman code. That he had taken, in the bargain, some code that wasn’t open source, which happened to be contained in the same files as the open-source code, surprised no one. Grabbing a bunch of files that contained both open-source and non-open-source code was an efficient, quick, and dirty way to collect the open-source code, even if the open-source code was the only part that interested him.