In a couple week's time, the teams YC has invited will be flying out to Palo Alto for a quick, shotgun style interview that they'll base their funding decisions on.
If you've been lucky enough to get invited, here's a bit of advice on what to expect and how to get through it successfully.
What to expect
You only have 10 minutes, which is a surprisingly short amount of time to discuss your business. You won't have any powerpoints or presentations, but you should have a demo. You'll start off, talk for about 15 seconds, and instantly get bombarded by questions for the next 9 minutes and 45 seconds. It's easy to get off-track, so you'll need to answer the questions quickly while trying to steer the discussion on-topic. Don't be surprised if multiple simultaneous conversations end up breaking out (at one point during our interview, I think I was having 2 simultaneous conversations -- one with PG and one with Trevor, while Chris and Dan were having a separate discussion with Jessica).
What you want to accomplish
You have ten minutes to convince the group that:
(a) Your idea is pretty good (it doesn't have to be take-over-the-world good, but it can't be bad -- that reflects negatively on your judgement).
(b) You're smart, and are otherwise equipped to accomplish your goal.
(c) You can get shit done.
Preparing for the interview
Experiences vary, but our demo was a crucial part of our interview. It's very helpful keeping the discussion on topic, lets the team visualize your product, and, most importantly, proves that you can actually build what you say you can.
Having an idea is pretty easy, but actually being able to put it together with the right parts -- easy to use, decent design, smart UI choices, functioning feature set -- in a short amount of time is what will be the difference between your product launching or not. Not all launched products are successful, but all unlaunched products fail, so proving that you can get your product finished and out the door is important.
Code frantically to get some kind of working demo done before the interview. Two weeks should be more than enough to get something basic done. If you can't, or your demo is going to look like hell, I wouldn't bother showing it.
If you couldn't already tell, memorizing some kind of presentation isn't going to work too well. Sticking stubbornly to your guns is also not advisable. As others have mentioned, you want to strike a balance between being open to suggestion, and defending your opinions -- just be sure to defend the right ones.
Having said that, be sure you know your market in and out. You better know who your competitors are ("We don't have any" is not an acceptable answer), the history of the market (What previous companies were similar? Were they successful? If so, how did the exit? If not, how are you going to do better?), how you are realistically going to make money (for a 3 person company, at least $30,000/month), and a very good technical understanding of how you are going to get all this done. The YC application is a great place to start to look for questions to prepare for the interview.
Before the interview
Relax. Put on some music to get yourself pumped up on the drive over. Try not to be nervous (even though everybody is, to some extent). Investors make a lot of decisions based on their excitement, so get excited about your idea! It'll rub off on them. Get there a few minutes early to hang out with some of the YC Alumni. You can also practice your pitch, and get some quick last minute feedback.
After the interview
You'll get a call that Sunday with the news. Don't freak out if it's late (ours was almost 2 hours later than they said it would be, and I was nursing some serious stomach ulcers at that point).
If things are still the way they were, you'll only have one variable: what your valuation is going to be. Decide ahead of time what is the lowest valuation you'd accept (if there even is one you wouldn't), so that you are prepared to give an instant answer to PG when he calls.
After the call, take a few shots, call everybody you know and enjoy yourself! Then get ready to work your ass off and eat ramen for 3 months.
Note: If there are any Penn State groups interviewing this session, be sure to shoot me an email! I'd love to get together over a few drinks and hear about your idea.
You've built a cool product. Great! Now, you need to show it off to people. Usually, this is a demo: a quick, 5 minute tour around the product.
Giving a demo is a lot better than trying to explain what your product does in words. It lets people see exactly how things work, and is the fastest way to help them understand your product. There's also an important set of people that will be particularly interested in your demo: investors. When raising money, a good demo to investors can make-or-break the decision process. So how do you give a good demo?
When raising money for Weebly, our demo was pretty simple. We'd spend about an hour ahead of the meeting looking up the investor's website, downloading the pictures and text, and importing the template into Weebly. Then, we'd spend a few minutes to practice creating the site quickly. The end result: we'd recreate an investor's site "from scratch" in front of them in 3-4 minutes. It definitely had the intended "wow" effect.
How do you put together a good demo? Here are a few tips:
- It has to be short. It should take 5 minutes or less in person. An online video should be no more than one and a half minutes long.
- It has to look really, really cool. The demo is a visual tour, and your audience will be concentrating on what they can see. Your goal is to get them to say "Wow!" Fades and animations get annoying in the final product, but they can look really cool for a demo.
- Adapt your demo for the audience. In our case, we would tailor the presentation to the investor we were presenting to. The person you're presenting to should be able to relate perfectly to the need for your product.
- Use real data. Don't ever type in "asdfasdf" for a form field. It's so much easier to understand what an application does when you can simulate a real user. Junk data makes it much more difficult to understand the use cases. Make sure to pre-populate your application with real data that highlights the story you're telling.
- Don't demo all of your features. Just demo the ones that best show off your product and give the maximum "wow" impact.
- Follow one general topic. If you're going to switch themes, make that very, very clear. It's like driving a car: if you want to change directions, you have to stop the car first.
- Have an offline or backup version ready. The worst thing is having to fiddle with the wifi connection for 10 minutes, or something going wrong with your host/colo while you're presenting. You might only have one chance -- make sure to have an EVDO card in case wifi doesn't work, or a local version.
- Show your product in the best light. You can be realistic about the shortcomings later, if/when asked. Make sure to always show off your product, and don't ever purposely demonstrate any shortcoming.
Finally, be confident and excited! You've built something really cool, and you should be conveying that message to the audience. If you're not excited about your product, why should they be?
When we started raising our angel round, the first thing people told us was "Keep working!" We started to realize why very quickly: It's pretty difficult to code and raise money at the same time. I also started to try and figure out why doing both at the same time was hard -- it seems like it shouldn't be. Since most companies have to go through this at least once, and some companies go through the process multiple times, it's probably worth trying to optimize.
Different people have different ways to deal with the inefficiency. Y Combinator makes the process as short as possible: literally, less than 8 hours total time spent. Many companies choose one founder to raise money, and others to continue programming. Even so, it can be really exciting to meet with investors (especially if it's your first time). In our case, we each added to the team, and we thought bringing all three of us would work best.
From my experience, there were a couple reasons getting work done was difficult:
1. Meetings break up your day and schedule. Getting in the zone is tough when you have a meeting at 3pm in Palo Alto, an hour away. Add 1-2 hours debriefing after the meeting, and your day has been split up into smaller, less work-friendly chunks of time. Somehow, we always ended up with exactly one meeting per day, the entire week.
2. Raising money is exciting. Much more exciting than fixing that bug that doesn't event really matter because it's not that bad and only 5 people use that feature anyway. The meetings were pretty much all we wanted to talk about.
3. Raising money makes you look at the big picture. We were looking at our business from a mile up. From that perspective, you're talking about major initiatives and the entire direction of the company. You can't even see the day-to-day stuff from that high.
4. Last but not least: Selling and coding are opposites. I work my best when I get in a zone where I lose track of time and manage to fit every exact detail of what I'm working on in my head all at once. If I get too excited, I want to sit down and talk about how we're going to do x-and-y and it's going to be amazing, and it's much harder to concentrate.
There was one moment in particular that illustrates the last point, and when it hit me how opposite the two roles were. We had closed our initial round, and the definitives were signed, but we had left a smaller portion open for a potential investor that would be in a second closing. We had gotten all of the selling and raising money stuff out of our heads, and had been pulling 24+ hour shifts all that week, working on some time-sensitive new features. We woke up, drove to Stanford, and talked the entire way about our daily progress.
When we got there, things started off slowly: we weren't selling our product, we were answering questions with factual replies about it's current state -- mostly in a dry, factual manner. Little by little, we started to warm up and started getting back in the flow: Explaining how cool a certain feature was, talking about the potential markets, selling the vision on where we wanted to go, and getting ourselves really excited about what we had coming. The meeting went well (the investor later told us he was in), we got back in the car, and talked all the way home about all the cool things we were going to do. We decided to eat lunch out, and we probably went food shopping, got a haircut, took a bike ride... Anything that wasn't coding -- because that was boring, and we were really excited.
So how do you get work done while raising money? If we had to do it again, I would:
- Understand the process, and why I'm likely to get distracted.
- Try to organize most meetings in 1 or 2 days of the week.
- Do my best not to feel entitled to breaks, just because I have been talking to investors.
- Do my best not to feel entitled to breaks, just because everyone told me I wouldn't get work done.
- Set hard deadlines for feature releases that have to be met.
- Raise money as quickly as possible (you might get a higher valuation by shopping for 2 months, but what's the opportunity cost?)
If you've been through the experience, be sure to chime in and comment.
And on a side note, I just re-published my feed through Feedburner. If you've added this blog to your feed reader, please update to the new feed.
I've heard many entrepreneurs make a decision based on reasoning that goes something like this: "If I do that, I'll grow too fast, and I'll run out of money to pay for hosting."
It's an easy trap to fall into, because you're probably convinced everybody is dying to use your product (if you're not, why are you making it?). For me, it was when we were sitting on the closed side of our beta, and had no idea how we were going to scale. Our decision was whether to continue with an invitation only-beta, or open public. We also thought that an invitation-only beta could encourage some kind of exclusivity or competition to gain access to our app, which could fuel growth (we were wrong, more on that in a future post).
It ends up that you probably won't grow that fast, and if you do, you'll be damn lucky. There's basically two opposite scenarios: One, you'll grow really, really fast and you'll need more servers and have a hosting bill you can't pay (sounds bad, right?). Two, you're not growing that fast and you'll be perfectly fine with the infrastructure you have right now. Now just picture that you can make a decision that gives either scenario A or B, depending on what you choose -- or even just makes one or the other more likely.
In the first case, you are growing really quickly. That's great! Your idea has been (more or less) validated, because you're solving a need for a bunch of people. But your servers are on fire. There's good news, though: call any investor in the valley and tell them "I'm growing so fast and I need $15,000 to pay for servers and hosting" and you'll have convertible note paperwork signed by the end of the week. (If you don't know any investors and are growing so fast you're running out of money, email me). That 15k buys some new servers and gets you a couple months to go out and raise a round.
End result: You are now the proud (co-)owner of a business well on its way to success. Your website survived and you raised a couple million dollars two months later at a terrific valuation.
In the second case, your growth is slow. You probably run out of money because you're not making enough to pay rent (you don't have enough people using your site!) and you're having a hard time convincing investors to give you money.
End result: Your website isn't growing fast, and your life sucks.
I should qualify this scenario just a little bit: This generally applies to most startups, especially those where there is a decent chance of generating enough revenue to cover your costs at some point. (It's probably a bad sign if that's not the case)
It doesn't sound realistic but it tends to be true: money will kind of appear when you're on the right track. In the short-term, there's also probably a few friends or family members that will loan you a couple grand. The much larger risk: not growing as fast as you can, or at all.
In our case, we were growing by 5-10 users a day in an invitation-only beta. PG convinced us to open it up, and 3 days later, we were covered by TechCrunch and had over 4000 users sign up in a couple days.
To sum it up: since growth is key to your success, make decisions that favor growth over some short-term problem.
If you haven't read it already, there's a great story about how HotOrNot dealt with growing extremely rapidly in Founders At Work.