One exception to the "solve your own problem" approach to startup ideas

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. 
This is an unusually ripe time for people to make software that touches late adopter industries like the ones mentioned above. 

It's not enough to be focused on your own needs. This is why empathy is so important as a founder. You really do need to focus on the needs of others. That's the path to creating something people want. 

The outrage that shouldn't be: Oculus Rift pre-orderers aren't angry that they didn't get equity. That's not how it works.

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.

Last Minute Advice for YC Applicants, Updated for 2014

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."
If you're a hair on fire problem, you have to clearly state how bad that problem is. How do you know the problem exists? Who has it? How specifically have you solved it? When you're doing something new like solving a brand new hair on fire problem, it's an uphill battle just to let people know you exist. We want to know that you are capable of even getting people to know you exist. 

On the flip side, if you're focused on a more crowded space and you're trying to do it right, then you've got to be a lot more clear about how your solution is unique and different. It's not OK to do exactly the same thing. Help us understand what you have figured out that nobody else has. It's so important, this is actually one of the questions on the application. 

If you're new, focus on explaining what you are. If you're not new, focus on explaining how you're different. If you're neither of these types, you're doing it wrong.



3) Have a capable team

The ideal startup team involves really two major roles — builder, and hustler. I used to say it took three roles (designer, engineer, hustler), but in practice I've seen enough evidence to the contrary that I have changed my mind. In reality, I think designer / engineer can be abstracted to builder. Some enterprise software companies don't need a ton of design. All tech startups need tech cofounders though. 

I've seen teams of hustlers fail because they can't create any product on their own. I've seen teams of pure builders (amazing designer / engineers) that fail because they can't put the product in the hands of users. In the end, you need both. Your cofounding team needs these things, and if you don't have them yet, you should go find your most talented and trusted friends who have those skills and get them to come join you. 

You need these skills because they're the basics for success. It doesn't have to be one person specifically for one role or the other. It's just important that people are capable of those things.  Be realistic with yourself about what you and your teammates are good at. You are getting married to your cofounders -- you're essentially getting out onto a life raft in the ocean with them, and you're going to need to work with them (and well) to survive.

Doing a startup without a kickass team who can really clean up on each of the three skills is going to war without guns, ammo, training, or all of the above. 



4) Write well

In the past five years, this has become more and more obvious to me as the examples pile up. The best startups are incredibly good at writing and communicating in as few words as possible. Being concise and clear matters. PG taught me years ago: If a founder can't express their ideas clearly to others, then the simplest and likeliest explanation is actually that the idea is not particularly clear to them either. 

PG's essays are an indication of what you should be striving to do in your application. You should read these essays now if you haven't already. Everything you write should be crisp, articulate, and to the point. 

One way to do this is to actually write every last idea down. Write copiously. Brainstorm to get it all. Then edit. Connect similar concepts and put them next to each other. Edit mercilessly until there is not a single word you could remove without losing significant meaning. 

One common pitfall that plagues practically everyone is the urge to sound professional. Don't do that. Just use normal plain English that you would use to explain things to normal human beings who have no special background. It's a mistake to try to sound corporate, or professional, or like a press release. Those are all among the worst ways to communicate in the history of language. What you say should communicate, not get in the way.

Simple rule of thumb: Does the writing sound like something you would say to a friend? If not, rewrite. 



5) Get a little help from your friends

You've got mentors, right? Get as many trustworthy and intelligent eyeballs on your written application as you can. This goes for any application for anything, really. More eyeballs will always help you flesh out your concepts, spot weak links and strengthen your case.

Email founders of YC companies, or founders of any company, to get feedback. We're here to help -- someone helped us.



6) What are you going to do if you don't get in?

You've got to keep working on the startup no matter what. Realize that you don't need anyone to give you a permission slip to create your own startup.


The application deadline for Summer 2014 is March 28. Apply now.

Good luck to all the applicants, and I hope to see you at interviews.

Like an inflatable hammer: Unusable software and its origins

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. 

Tenth Grade Tech Trends, 2014 Edition: Snapchat usage up 3X — 39% of teens use it regularly

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.

The API-ization of everything

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. 

Fear is like fire

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.”

That fear exists in startups too. There is much to fear in every new endeavor. Are you shipping fast enough? Are you making things people actually want? Are there enough people who want what you have created? Can you reach them and sell to them? Is this going to work? Are you going to live?

There are some startups that raise so much money that the fear is gone. There is infinite tomorrow. This is a great problem to have, but a problem nonetheless. For them, the fear must come from elsewhere. There may be time, but not for this idea and this market. Competitors are coming and they're coming for you. Ah, there's the fear again... it's useful. Use it. Harness it. 

There are others, which is to say most, where the opposite is true — there are six months left. Three months left. Or less. Then there is an impenetrable 20 foot tall wall of fear. Death is around the corner. Again, this fear will focus you. Make you ship faster. Force you to ask the hard questions, and make the changes you knew you had to do. 

All startups feel the fear. Like Cus said, there's no difference between what a hero and a coward in what they feel. It's what they do that makes them different. 

I am Jack's desire for a ice cream cone: Your brain is 100 billion cells working together

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. 

Lost to history

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.

From beyond the grave, it is a particularly striking thought. The technology exists to store everything ever said or done, and the cost is coming down all the time. I hope that's what Posthaven can be. It'd be nice to leave something behind. But there is much left to do to make that happen.

Goldman Sachs sent a brilliant computer scientist to jail over 8MB of modified open source code uploaded to an SVN repo

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.)

Aleynikov decided to take another job, but in the meantime he stayed on at Goldman to help out. That's where it got sticky for him:

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.
And so this case is disturbing to me, because a software engineer like any of us is assailed by one of the more infamous financial institutions in the world. He violated confidentiality, but 8 years of jail, really? He's spent 11 months in prison already. He didn't steal the crown jewels or the secret sauce— his acquittal was on the basis that the code saved to SVN wasn't the proprietary trading strategies at all, and it was extensions to open source software that he wrote himself. 

Yet Goldman Sachs pursued criminal charges against him anyway. And continues to pursue him. 

I'd love to know what specific pieces of software they were. Software engineers would be able to tell what was kosher and what was not. It scares me that a jury of non software engineers (truly, not a jury of Aleynikov's peers) will likely be responsible for deciding his fate. (Edit: Note, 8 megabytes is actually a good deal of code. But that's why what code it is matters so much. There's little transparency in this case here, so we are left to speculate.)

Serge was acquitted via the 2nd Circuit Court of Appeals, and released in February of 2012. (photo above) He has since been re-arrested and is being tried by the state of New York. In the United States we have a thing called double jeopardy — you can't be tried for the same thing twice. Somehow that doesn't apply here. Not when Goldman is after you. 

Sergey Aleynikov faces two felony counts in New York.