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.
Martin, was YC ultimately good for your company even though Rapportive was in a different stage than your batchmates? Would you do it again?
Many other companies in our batch soon launched too, so we soon all ended up at pretty much the same stage.
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.
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.
Best wishes for your continued success!
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.
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.
... 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.
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.
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.
So you could try variations like "The traveler will beat the path." Or wait for the Russian module of WordLens :-).
Also, it sounds like development was going on, improving architecture for scale and fixing bugs.
I've heard several people rave about rapportive so whatever they are doing is obviously working.
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.
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.
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.
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.
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.
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.
Then it's not so fun.
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.
Are all YC startups encouraged to get acquired?
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.
[Edit - grammar fix]
The entrepreneurial mindset seems more geared toward building cool stuff, which makes the next stage of scaling/support much less fun.
* 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
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.
The product is great too I use it every day..