Something that I think a lot of people don't realize about YC is that it's not very fun. Don't get me wrong, I have a lot of great YC memories, but the pressure was enormous. We had yet to raise and so we were operating on shoestring. My co-founder and I fought more during YC than any other time, before or after (and often over nonsensical and petty stuff).
That being said, you don't go through YC because it's fun. You go through it because it's good for your company. It gave us exposure to investors who probably wouldn't have given two first-time-entrepreneur yokels from Minnesota the time of day. We met a lot of people who had been through the pain of building a company before.
More than anything YC forced us to take a hard look at our company and a hard look at ourselves and decide that we could do this thing even when it wasn't always fun.
This gets to a critical question about incubators -- what is the value you actually get from the process? (the followup is, how does it compare to what was promised?) As you point out, "You go through it because it's good for your company," and that mainly means meeting the right people and figuring out where your company is going.
Martin, was YC ultimately good for your company even though Rapportive was in a different stage than your batchmates? Would you do it again?
YC was (and is continuing to be) very valuable for us. Sachin Rekhi has written up a good summary, which I broadly agree with: http://www.sachinrekhi.com/blog/2009/02/26/the-value-of-the-... -- and I would add to the list of benefits the massive network of the YC partners, who will happily make valuable intros.
Many other companies in our batch soon launched too, so we soon all ended up at pretty much the same stage.
Our product development was almost stalled for months on end.
Then you're doing something wrong.
Scaling, debugging, refactoring, customer support, prospect interaction, and even raising investment must all be done in support of product development, not instead of product development.
I am a notorious single tasker who loves coding more than anything else, so I used to have the same problem. If some other task took priority, all product development stopped.
Until a artist friend of mine told me the secret of his success, 4 words I have never forgotten, "I paint every day."
Now I code every day. No matter what else happens.
With 3 of you, I would expect that at least one of you could keep building something every day without any of you dropping any of the other eggs you must juggle.
Yes, we probably were doing something wrong. That's the point of the post: to explain how easy it is to get into a situation where you are making little progress, and our story of getting out of it. I sincerely hope that others will be able to cope better when faced with a similar situation.
It's easier said than done, though. Development takes significant ramp-up time; if you spend 10 hours a day on it, you get much more than 5 times as much done than if you spend 2 hours a day. We already did what we could in terms of distributing workload amongst people to minimize context-switching.
Sometimes I think that the definition of success has less to do with intelligence, hard work, and breaks and more to do with finding a way to do that which is easier said than done.
Didn't mean to be negative in grandparent, just to take advantage of sharing some of the best advice I ever got. There's a lot to be said for making progress every day, no matter how hard it is.
> Development takes significant ramp-up time; if you spend 10 hours a day on it, you get much more than 5 times as much done than if you spend 2 hours a day.
So true. Having one hour for coding is next to worthless. Perhaps the fabled 'zone' for programmers is merely a long enough stretch of uninterrupted time to immerse oneself.
Joel Spolsky used to write a lot on this topic, one of his key recommendations were private offices with a door that closes for developers. Lately I have seen little to indicate that the industry (startups or established companies) are moving in that direction. What are your experiences? Do you know many companies implementing this? Would you? Given that avoiding disturbances is so critical to developer productivity it seems like a no-brainer, I just don't seem to see it in the field.
EDIT: Here's one of Joels pieces on the topic (great read):
He actually answers my question by saying that no VCs would allow a company to squander their money on something so lavish. Wonder if people here agree with that assessment today.
"Our product development was almost stalled for months on end."
Then you're doing something wrong.
I disagree. When we were fundraising we got no actual product development done, and from what I hear this is rather normal. "Months" may be a bit long, but they also launched around the time they raised, so combined with all the support emails (free products = lots of support...good reason to charge!) I can completely understand.
Our fundraising took around 6 weeks, I got nothing done. I tried to take on all the businessy things like support, so my cofounder could keep coding. He got work done, but it was mostly paying the technical debt we had accumulated when trying to launch quickly. I'm convinced that was the right thing to do, since it seems to have gone well for us.
I can definitely see the benefit in the "code every day" mentality, but personally the extra context switch isn't worth it for me. I'm very conscious of when I'm not pushing new code and it physically pains me, so I keep tabs on it and never go more than a day or two without coding, but I don't make any hard-and-fast rules about my coding time.
> I tried to take on all the businessy things like support, so my cofounder could keep coding. He got work done, but it was mostly paying the technical debt we had accumulated when trying to launch quickly.
... it sounds like you were following his later suggestion pretty much exactly. Also, paying down technical debt may not be sexy, but it's damned important.
You're right, but Martin already said his team was working on things like scaling as opposed to iterating on the product. I think that's what every startup needs to do post launch: harden up the quality of their product before pushing forward with new user-facing features.
I agree totally with your disagreement. I am not doing any fundraising, but we are negotiating a couple enterprise sales and I am handling all bug fixes/user support. I have hardly made any progress on planned features. It's just way too much dealing with people and constant email interruptions and trying to be innovative. I am also taking on the businessy stuff as well, while my gainfuly employeed co-founder is free to drop a couple hours a day on code. This is one of the strongest arguments for > 1 founder IMHO.
Beautiful. In Russian we have a proverb "Дорогу осилит идущий" that roughly translates as "he who walks the path will make it to the destination". It sounds much better in Russian, and I was struggling to translate this into English for a while now, retaining the simplicity and elegance. This might just do it.
Sadly, not the same. A more literal translation is "the road will be overcome by the walker". There is a sense of a struggle in it, but also a sense of an achievement in the end. And the walker is he who walks rather than stand still, that is he who exerts effort towards the goal.
You suggestion does not deliver the same emotional load for me.
The phrase itself is a grossly inaccurate translation of a biblical verse into Russian, and using the original is not much help either.
If you can't reproduce the equivalent emotional load in English, it's probably because this particular phrase is not part of the culture. You can simulate it, much like Tolkien might, by choosing words that are more likely to resonate with an English speaker. For example, the word "walker" is not going to cut it, and "pedestrian" would be worse. Your explantation is helpful.
So you could try variations like "The traveler will beat the path." Or wait for the Russian module of WordLens :-).
I agree that it does sound unnatural but I still would say it conveys the meaning better. The more correct version you wrote seems to loose the idea of struggle (to me at least).
It also occurred to me just now that original phrase presents the road from two different points of view: it is an obstacle, as its length separates you from your goal, but it is also the means to reach your goal. Does this make sense?
It seems awkward to me, probably because I have been taught to despise the passive voice in writing. I prefer 'The walker overcomes the road' which feels more better :)
Well, I think from a customer point of view they see "making things more stable/reliable" as "no progress". Customers, rightly so, expect things to be stable and reliable from the start. Otherwise, they are testing your product and not every customer wants to do that.
I feel like Twitter was very lucky that they did not see a decrease in use and adoption while they had many problems with scaling.
I think Twitter benefited from having no attractive competition during that time (mostly there were similar sites, with little innovation and few users).
Also I think you get a 6-9month grace from early adoptors while they can see you scaling up staff and getting funding. However, after a certain point they start putting up blog posts about the lack of progress and pointing out alternatives. I think this is partly because it takes a while to get really used to what your app. does and how it's useful to them.
I think the biggest benefit for Twitter was that thanks to their API there were developers working on improving an innovating on top of the product even when Twitter was focused entirely on scaling.
Yes, Twitter was lucky in more than one way. I agree with what you said about early adopter. I'd label these people as "willing to test products", even if that means they will encounter some bugs or issues. However, not every business will be able to say that about their first set of customers.
Naw. Everyone who raises money learns the same lesson. Fundraising causes your product to nearly stop. It sucks, but I've never seen it not be the case. Add to this that these guys had an early crush of users and I can imagine how painful it was.
> > Our product development was almost stalled for months on end.
> Then you're doing something wrong.
Easier said than done.
I reached a point where I finally realized how deep in technical debt my startup was. Actually, that's not true. At some point I realized "OMG, I've got three months of work to do just to stop stuff from breaking every day". I was wrong. It was literally 12 months.
I'm now at the end of that 12 month slog.
I will never let stuff get as bad as it got then, so this was a wonderful learning experience.
...but to say that, based on where I was, it was the WRONG decision to put out the house fire before building more additions on the building is to speak without the detailed knowledge that someone in the situation brings to the problem.
I think it's interesting how different people view the same tasks as pleasant or unpleasant. I find breaking things, scaling infrastructure, and talking to (potential and current) customers vastly more pleasant than planning/managing development or writing code. Logistics (for moving bits, boxes, and people) is great fun too.
Recruiting is amazingly fun when you're not already under the gun for a specific position, because it's basically selling your idea and meeting someone new. It sucks if you're behind and need to hire a lot of people quickly, because you're going to have to make a lot of compromises you shouldn't be making, and you know it.
I'm sure there are people out there who enjoy admin, accounting, and immigration bureaucracy, but those people are not me.
Maybe figuring out what things your team enjoys (and presumably is good at doing) should inform what kind of product you build more than it usually does.
It all depends on the circumstances. I love hacking away on Playtomic and scaling it and talking to my users or potential ones, and everything else.
Until things go wrong. Logs aren't being processed, 100s of megabytes a minute are piling up, shit keeps on crashing... compile again ... deploy again ... hope this time the problem's fixed ... hope it really is this time cause it's 2am and I've been up since 7am. It looks like it's working finally ... I'm going to bed at last ... if it's not fixed tomorrow will be a fuck of a day racing to get those logs processing again before that server runs out of disk space, while people ask when their reports will be updating again or tell me there's some problem.
On a somewhat un-related note, I am interested in hearing about your immigration issues. I realize an immigration attorney's advice is probably golden, but I would like to hear what visa categories you considered and applied for and what problems you encountered while applying/gathering paperwork.
I was planning another post on that topic :) in a nutshell, we got H-1B visas. With a good attorney the paperwork is mostly tedium, but lots and lots of tedium. The process is very opaque and full of uncertainties.
To me, the phrases 'H1B' and 'startup' are inherently disconnected. I -- and many others, i imagine -- would love to read your post on your immigration issues. Thanks!
Were you able to leverage the YC "old boys" network? (I mean that in the positive sense, not the negative one)
That is, did having access to talented former-YC people help you get over the technical humps and hurdles? I believe one of the main pros to joining YC (apart from getting mentoring from PG et. al.) is that many of the people that went before you are on tap to help resolve things in a "pay it forward" fashion.
Erm, the OP was explaining that if you have already launched, your YC experience differs from what you might expect. Fair point I thought, and might be useful for those considering the timing of their YC application. I have noticed that some people feel that having launched already gives them more "cred" in the process, and the OP points the downside to that.
The funny thing about it, though, is that most of their problems during this time came from the fact that they were getting traction. I think these probably pale against the problems one has when one is not getting traction. Yes, not having users lets you keep building the product... but this is of rather less comfort when you're simultaneously wondering if anyone is going to use it.
For a second I thought that was graph of the company I work for...right now we're in the wiggles of false hope having just come out of a very rough crash of ineptitude under a previous administration.
Nothing is fun when it goes beyond a certain level. User support is interesting, but it gets a bit repetitive if you need to do it all day long. Scaling is really interesting, but getting no sleep because the database is on fire is not fun. Fixing bugs is not fun if they happen on other people's weird configurations that you can't reproduce. And raising capital... sure, it's glamorous, but in the end it's pretty tedious.
The amazing thing about a startup is that you can quickly translate your intuitions about a product you think that people want into an actual product. Making a good product and making people happy is what I care about. The other things are enablers.
On an unrelated note, that whiteboard graph disturbed me a bit. Does every YC startup hope to get bought out? Why would that even be a goal or something to aspire to?
It seems to be part of the definition of a startup that the end goal is either acquisition or IPO. PG has said (in an interview, might have been on Mixergy) that YC can't make a profit on a startup unless it has an exit.
On a mostly unrelated note, I installed rapportive and discovered that someone had signed up for a social network with my e-mail address that wasn't me. So I had the site send me a new password and deleted the account. Why do people do that?
* Answering many, many support emails and tweets
* Raising our seed round
* Stopping our infrastructure from collapsing under our user growth
* Responding to press and bloggers
* Reading resumés and interviewing job candidates
* Fixing gnarly bugs in production
* Applying for visas, so that we could work in the US
* Attending YC dinners and office hours
How is all this not moving the product forward? I am genuinely curious, to an outsider like me, this is what is the growth of the company. All these things have to be done one time or another.
The article mentions other companies frequently rolling out new features. In that context, the product wasn't moving forward because no new features were added during the YC phase. While scaling and bugfixing probably count as moving the product forward, the rest is arguably moving the company forward.
wouldn't the company die if there is too much focus on the product part and not much on the selling part. I mean if you stop customer support, many users will move out. Also if the solution fails often, why the heck will one use it?
"The product" is defined as the activity whereby the engineering organization delivers new products and features to customers. All of the above activities are important, but they're not "the product".
A product is something you offer to the user, to me if I am buying a service or a product I am also buying the customer service and the reliability (the service should never stop unless its supposed to). So the support emails and tweets are the product, as is the Fixing gnarly bugs in production and Stopping our infrastructure from collapsing under our user growth.
If you are growing, you will have to have new employees so of course you will have to Read resumés and interview job candidates. This is essential for developing the product (even as defined by you).
The only slightly unnecessary thing on the list is the responses to press and bloggers and applying for visas. I say this because both could be avoided if 1) your product does not require much press(as in, it is a tool which is used by experts, not something which has to be advertised) and 2) you can work in what ever country you are in.
That being said, you don't go through YC because it's fun. You go through it because it's good for your company. It gave us exposure to investors who probably wouldn't have given two first-time-entrepreneur yokels from Minnesota the time of day. We met a lot of people who had been through the pain of building a company before.
More than anything YC forced us to take a hard look at our company and a hard look at ourselves and decide that we could do this thing even when it wasn't always fun.