Simulating YC

By Ivan Kirigin –   - comment

Right about now, many startups are learning whether they got into Y Combinator’s W16 batch. Congrats to those that got in, and for those that didn’t, please keep going.

Even YC companies try to continue the momentum after Demo Day. So how can you simulate YC — whether you didn’t get in, can’t move to California, or your batch is done?

matrix jump good

This is like software or UI design patterns. If there is a good idea that works, we should make them more common. We’re simulating an accelerator, so this is just another way of exploring how a more startups can win.

For context, my startup YesGraph just went through the W15 batch. It was my second time through, after my first startup Tipjoy was in W08. Plus YesGraph helps apps grow, so I talk to many companies about their growth constantly.

Picking Your Goal

It’s incredibly important to have a true north for growth. I’ve written about how important picking a goal can be for your startup’s growth. Growth solves most problems in startups. You can get a lot wrong and still win because of good growth.

You should work with investors and advisors to pick a goal. It’s something that partners at YC will focus on during office hours. You can revisit whether you’ve picked the right goal, but mainly you’re looking for a baseline for the real work.

Driving Towards a Weekly Growth Target

If you have a goal, then you need to keep score. In group office hours and meetings with partners, YC focuses with brutal honesty on hitting metrics. Many founders describe how motivating this routine can be for maintaining momentum. For example, Airbnb would put their target growth graph everywhere — they couldn’t avoid keeping score and getting motivated.

Startups can be busy and frenetic. Mania about your specific goal actually helps you focus on cutting out everything that doesn’t help achieve the goal. During YC you might even make temporary sacrifices, like not meeting up with friends socially.

Find the right balance for you, but try to cut away everything getting in the way of hitting your goals. This is why so many investors focus on founders that are relentlessly resourceful.

Routinely Meeting With Other Founders

The YC batchmates provide a big part of YC’s value because other founders have your same problems. But they aren’t your investors, your boss, your customers, or your employees. You can be direct and blunt in a way that is very rare compared to your other relationships.

This level of candor helps you be honest with yourself and helps you prioritize. It also helps get feedback and advice from just enough people. Not one person’s opinion and not a crowd that can’t see the future you’re building.

Try to keep this group small — no more than a dozen companies. As groups grow, meetings become cocktail parties not counseling sessions. Harsh feedback is less direct or not given at all. 

Demo Day = Refined Pitch + Meeting Density

YC’s Demo Day is an incredibly valuable tool for startups. The reason is that a higher density of meetings dramatically changes the results of your fundraising efforts. Having 100 meetings with VCs over 3 months will not be as effective as 30 meetings in one week.

So to simulate Demo Day for your next round, make your fundraising a punctuated event. Don’t take investor meetings if you’re not fundraising. No one will think less of you if you say “thanks, but we’re heads down building our product and plan on fundraising on X”. Don’t even take intro phone calls if you find it hard to be disciplined here. Then when you want to fundraise, try to plan all your first meetings within just a week or two.

If you don’t have the YC investor network, leverage your personal network. In a spreadsheet, make a list of every investor you know. Then make a list of every founder you know. Ask every founder which of their investors stand out, add those to the list, and then ask for an intro. Make a list of other notable investors and research who you know that can intro. Then request the intro and add the investors to the list. This list is now your CRM. Work the list to arrange a tight sequence of meetings.

I meet many founders that don’t understand the numbers here. That’s one of the benefits of YC’s demo day: default high scale. You can’t just take one meeting and decide your fate from the result. Plan on a large number of meetings and a large number of “no”s before you get to a “yes”.

Another part of demo day is pitch practice. The actual pitch is just a few minutes long, but this is abnormally short for talking to investors. Still, your core message should be very polished to match this level of refinement. The best way to get good is to practice. Record yourself and watch the recording. Refine and repeat. Ask friends that understand startups to give feedback — do it live or share your recordings.

A coherent story comes from refined thinking.

Growing and Using Your Network

YC’s community is very strong, built with a pay-it-forward culture of helping future founders. Batch mates have stronger rapport than across batches. But this pattern just mirrors how real life networking works: it’s all about trust. Certification by an institution can help build trust without direct experience, like trusting someone is good because they went to Harvard or worked at Google.

Without the institution to impart proxy trust, the way to build a network is by interacting with people directly. There are plenty of navel gazing startup events with vapid conversation. I’ve found that the best contacts come from environments that foster closer relationships and higher bandwidth interaction.

I recommend approaching this in a tactical way: learn more about something you need by tapping your current network to grow your network. If you need to learn more about sales, talk to your network to find and build connections with people that know a lot about sales. Do the same for other topics: engineering recruiting, managing a team, automated testing, building a brand, getting PR — whatever. Cold outreach also works. To get a better response rate, target people rising in their career but not at the top.

Consider Sharing an Office — Thanks Andrew!

A shortcut to getting a close group of founders is to share an office. YC actually recommends against this because having a space to call your own is important. I don’t agree, especially given how expensive that can be for just a handful of people.

Right now YesGraph is sharing space with another small startup called Esper. Esper makes software for executive assistants, an under-served market.

Esper’s founder is Andrew Lee, and we regularly commiserate and strategize about our companies. It’s a microcosm of a YC batch: two founders talking.

11082264_10152884761385805_8943615801667347342_o

What are Your Tactics?

I’m sure we’ve missed some tactics here. What are yours? Leave your answers in the comments or email me at ivan@yesgraph.com

If you want to get future posts about startups and growth, subscribe here.

And if you’re looking to grow your startup, check out YesGraph!

5 Changes to YesGraph’s API: Faster, Stronger and More Flexible

By Ivan Kirigin –   - comment

We’ve made a few changes to YesGraph’s API that allow for new product features and better performance in your app.

hulkbuster tight

1. Recording Seen Suggestions

We’ve added the endpoint /suggested-seen.

This helps keep track of which contacts a given user has seen. When we rank contacts, we don’t know what end users see — for example the top 5 or 10 could be featured. With this endpoint, now we do.

This matters because users can be constantly shown new suggestions.

Besides the input of seen suggestions, you can filter them out of the ranked results. This is by default on, but you can control it with a filter_suggested_seen flag on the /address-book endpoint.

2. Get Ranked Contacts Immediately

Previously, contacts were input with POST /address-book and retrieved with GET /address-book. Now we’ve optimized ranking to the point where we’ll return the ranked results immediately on POST.

This is a big deal because of the time it takes to run two requests. Previously, the client would make an API request to input contacts, wait for the response, then make a request to get the contacts out, and wait for the response again. The network time between these two requests is a big part of the waiting that will impact end users. On a slow mobile connection it might be 500ms each way. Removing network steps makes this a far better user experience.

3. Removing Landlines from Mobile Contacts

We’ve recently enhanced our ranking to find contacts which belong to businesses and landlines. This is a powerful change because landlines can’t receive an SMS. They literally can’t be invited in many cases, even if the contact is a close connection.

This kind of enhancement is exciting because it highlights that better modeling on YesGraph’s end can dramatically increase invite performance — without your needing to worry about it. We’ll continue to add new signals to drive even better performance.

4. Dramatic Speed Boosts

We’ve made our primary ranking endpoint 4X faster. We now return on average in 200ms, and frequently less than 100ms. This doesn’t count network time from making the request, which can be highly variable based on the user’s connection. With our new iOS SDK, we’ll be tracking end user performance closely.

Beyond YesGraph’s ranking performance, we can now state with confidence that we’re faster than rolling your own systems.

How did we do it?  This isn’t one change, but the result of many small changes. We added caching layers for different data processes. We moved some processing to the background. We optimized our queries and models for the data. We still want to get faster, but considering the volume of data we process, it would be a challenge to replicate these results by doing it yourself.

5. Android On Its Way

We launched our iOS SDK and now have started work on our Android SDK. This is a big deal to help apps drive consistent performance across every platform.

Android has some differences, like how users request permissions and how Facebook and Twitter native flows work. This also varies by version of Android. But you don’t need to worry about that with our SDK. We’ll take care of it, on top of managing YesGraph’s API to recommend exactly who a user should invite.

If you want to dive into these changes, join our growth community on Slack here.

To get the latest news about YesGraph, subscribe to future posts right to your inbox here.

3 Things You Must Do Before Building a Referral Program

By Ivan Kirigin –   - comment

I worked on dozens of tests and optimizations of Dropbox’s referral program. There is an incredibly amount of work on product and engineering that goes into making systems like that to be so successful.

But where to start?

What if you don’t have any referral program? Here are a 3 things to do TODAY to get started.

1. Measure: Do People Like My App?

People tell their friends about things they like. Referral programs, whether incentivized or not, just make that easier to drive good performance.

So how can we measure whether people would even use a referral program?

Luckily, there is a very well understood marketing survey that literally asks, “On a scale of 1-10, how likely are you to recommend this to a friend?”

It’s called Net Promoter Score, or NPS for short. You take the percentage of respondents that answer 9 or 10, and subtract the percentage that answer 1-6. The thinking is that people that say 5/10 actually have a strong reservation that would make them not actually recommend the app — maybe even prevent a friend from trying it if it came up.

If you survey your users and your NPS is less than zero, I wouldn’t bother with a referral program. You might get some people telling friends, but not enough to justify the product engineering investment.

Another way to measure happiness is retention. Plot percentage of users retained by user age. This isn’t retention by calendar time, but measuring relative to the user’s signup date. If all your users go away, your problem is the quality of your product, not your top of funnel growth.

Sometimes higher density changes retention, but be very wary of making excuses for terrible retention. The simplest explanation is that you can’t read minds and didn’t correctly predict what people want you to build.

retention

If your NPS or retention are good, proceed. Side note: if you continuously survey NPS, prompt people that answer positively to use your referral program. I wish this were baked into survey tools. My friends at SendWithUs have a great template to try here.

2. Send a Basic Request for Referrals

Ok, so you know people like your product. The simplest way to test whether they would use a referral program is to ask them to refer people. But you want to make it at least trackable to get some insight here.

You can compose invite links that show the user they will get credit. Send an email to everyone asking for referrals, and make the invite link really obvious. This global link is often important in referral flows anyway, so get some practice on highlighting it.

yoursite.com/#invite?u=ivan@yesgraph.com

You can send this to all your users once. For a real program, make it part of the user lifecycle.

Here is what that email might look like:

letterhead

Hi [Name],

Thank you so much for using [Example]. We’re delighted to have the support of early users like you.

I wanted to ask if you could tell your friends about [Example]. It would help us grow and expand — and also help your friends get [simple value prop].

You can just forward this email, or just share this invite link: www.example.com/#invite?u=ivan@yesgraph.com

Thanks,

Mary McFounder

3. Decide to Invest More – Or Not

Now you have a great deal of evidence to understand your users and the potential for a referral program.

Almost any outbound email tool can templatize that invite link based on the recipient. Almost any analytics tool will tell you which pages people see. So you can track opens on the email, clicks on the email, and then clicks on the link. With a very small amount of work, you can track which signups came from your brand new referral channel.

Generally, this is how you should be running all your growth experiments: what is the least amount of work to learn as much as possible and drive the most results.

The same applies to everything you do downstream. Measure where in the funnel this invite flow break. Check out this post about the metrics I recommend measuring for any viral flow. Then come up with experiments to improve the results.

If your engagement with this basic referral program is atrocious, then the product or your users need to change. There is a chance that designing the referral program differently can make a big difference. But this test touches many users and should serve as a good baseline.

How should you decide to invest more? That depends on your product and competing acquisition channels. Judge from first principles whether this experiment was a success for you.

If you have questions about this post or growth, join the YesGraph growth community on Slack: http://community.yesgraph.com

Or just email me: ivan@yesgraph.com

Grow Faster with YesGraph’s iOS SDK

By Ivan Kirigin –   - comment

We’re delighted to announce that YesGraph’s iOS SDK is now available. It’s the easiest way to use our API. Plus you’ll get a high performance invite flow for free.

We’ve built in the best the growth design patterns from the best apps. Our SDK will be as easy to integrate as the native share sheet — the difference is it will actually work and help you grow. The best part is that we’ll be continuously testing and improving the flow, so using our SDK means you can run more growth experiments for free.

YesGraph iOS SDK 100

Let’s walk through the user experience.

First a user triggers the flow with the click of a “share” button. Then we explain how sharing works and give a few options — Facebook, Twitter, your contacts, or a link to copy.

This is entirely customizable — the colors, the copy, the default text for the messages — everything.

If the user selects contacts, we prompt to get permission to access the contacts. Using a share splash and double native modal, we help the user understand why we’re requesting contacts. This way we maximize user trust and conversion rate to approve the sharing.

We manage using YesGraph’s API under the hood. We take care of network errors, local caching, and a bunch of other issues.

Finally, we show the user’s contacts, including YesGraph’s suggested contacts at the top. Under the hood, these suggestions are based on our machine learning and social graph analysis. These personalized recommendations improve the user experience and your app’s invite metrics. YesGraph gets smarter over time — all without your needing to worry about it.

Oh — and everything is open source. Check it out on Github here. Star the repo and share it! We also just opened up a community slack channel to chat growth and help with integration. Or just email us: support@yesgraph.com

Up next: an Android SDK. That’ll come with some awesome new features, so we’re working hard to get it done as soon as possible.

Why We’re Ditching Traditional Coding Interviews

By Ivan Kirigin –   - comment

There is a problem with traditional coding interviews: they don’t measure what you hope they do.

Companies want to hire people that will do high quality work efficiently. For engineers, this involves values, taste, system design, collaboration, programming, and other skills. This is a lot! So your assessment better represent the real work of a job well, or else you will filter out people that might thrive and hire people who are a poor fit.

The problem is that you want a repeatable, scalable process in hiring. This means reducing down questions to basic forms. For software engineering, this means a basic coding question. The code is often trivial.

For example, print out “fizz” and “buzz”, alternating, and repeat to match the fibonacci sequence. This is slightly more complicated than a basic FizzBuzz. Here is one solution.

Screenshot 2015-07-07 15.32.37

A more sophisticated interviewer might ask where this will fail. In this case, the fib array grows without bounds, so for large input values, you’ll run out of memory. Nevermind that the task requires exponentially increasing printing.

The point is that this question has no point. It has no meaning or purpose. You can dork out over different approaches and their limitations, but you aren’t learning much about candidates.

When it comes to assessing specialized knowledge (for example we’re hiring for mobile and data focused engineers), this is terrible assessment.

There are other problems too. People rarely write code on a wall, no matter what The Social Network tells you. People rarely write code under tight time pressure, where a minute of silence would flunk. More complicated problems routinely involve long blocks of uninterrupted times, so much that we call it the “maker schedule”.  And then there is Google. Everyone, even great programmers, constantly look up answers to questions.

social-network-window

At YesGraph, we’re hiring engineers focused on data and machine learning. We needed to come up with something else.

So instead of a programming interview, we’re making a take-home problem focused on a real machine learning challenge.

This is better in a few ways. The problem is realistic, if confined. We removed only some of the data gathering and cleaning typically involved in learning. Candidates will produce significant code that actually looks like the code someone would write in production. It tests high level knowledge of learning. If you have no experience, you probably won’t know where to even start. But it also allows for differentiation and personality, so that great candidates can shine. The problem is asynchronous, so people can do it when they feel up to it. It also allows people to work in their familiar development environment. The problem is complex enough that it assesses communication and reporting as much as coding.

There are still some limits that aren’t perfect. It takes hours not days. Most complex projects don’t take hours. We don’t help someone come up with an answer, so we’re not testing collaboration. It only involves one or two kinds of problems, so it doesn’t measure breadth of knowledge.

For those things, we’re relying on a Q&A format, where we probe deep into someone’s experience and knowledge. There we’ll look at how well they communicate in addition to how much domain knowledge they have.

I bet a lot of people reading this are curious about the test. If you can promise not to share it, email ivan@yesgraph.com and I’ll give it to you.

I’ll publish it here on this blog after a while of using it. We want to balance establishing a baseline for future interviews and sharing with the community, like this post! So we’ll periodically retire and publish our problems.

Subscribe here to get future blog posts.

How to Get to the Top of HackerNews

By Ivan Kirigin –   - comment

So you wrote a good blog post or made an infographic. Maybe you have a product launch story in TechCrunch. Now you want to get it on HackerNews, because the site can send massive traffic.

Don’t.

Seriously, you need to stop trying. I say this not because I don’t want spam; I want you to win! Your efforts to manipulate the site are going to hurt you.

For context, I’ve been posting to HackerNews for years. I would routinely hit the front page.

This matters because getting 10 points and hovering on the second page will send orders of magnitude less traffic. Content marketing is in vogue, and many are learning the hard lesson that over half your efforts should be spent on distribution. Here is a graph of our last 10 blog posts by traffic. Guess which ones got onto HackerNews? Hint: two did well and one did OK on HN.

Screenshot 2015-06-04 10.24.46

What used to work: you could get a few friends to submit a story and vote. It seems harmless enough, getting 2 or 3 people to vote on a story right after submitting. It would get you to the front page, and if your post was good enough, it would stay. If you engaged in the comments you could help out the effort. If you asked others to comment, that also helps, but it’s a bigger ask.

What changed is that the software team at YC got a lot bigger. There are people besides pg working on it. They focus on scaling, but also on killing spam. They implemented a voting ring detector that is now incredibly aggressive. Your story will stay alive, but it won’t hit the front page.

killed

So what should you do now?

  1. Make great content that you think will resonate with the community on Hacker News.
  2. Ask friends to make comments. If this is about a product, you could ask good customers to chime in. This isn’t that different from asking for a referral or a testimonial on your home page. You could take their comment and repurposed it as a testimonial anyway.
  3. Think of Hacker News as just one of many places to get a story distributed. There will be downstream positive effects because some small percentage of your audience that promotes your story elsewhere. I’ve been told repeatedly that the #1 source here is the built up list of people that subscribe to get each new blog post. Growing that basis makes distribution higher for every new post.
  4. Review performance of your content regularly to understand what resonates with what communities. Make sure to track to your real goal, be it recruiting, subscriptions to your mailing list, or signups for your product. You don’t want high traffic to posts which converts very poorly to your goals.

What is our goal for this blog? We make YesGraph, a new product that helps companies grow. We blog to help companies with their growth and explain how to use YesGraph. Our concrete goals for each post are getting more subscriptions to the blog mailing list and getting visitors to try YesGraph. If you see any share buttons or prompts to subscribe, now you know why.

If you have questions, ask me in the comments on Hacker News 😀

Building a Perfect Mobile Share Flow

By Ivan Kirigin –   - comment

UPDATE: We’ve launched our iOS SDK. READ MORE HERE. It doesn’t include branch.io integration yet.

Screenshot 2015-04-28 12.38.05

We’re building something new at YesGraph, and we wanted to let you know early because you can get involved. It’ll be 100% open source.

Mobile apps have a choice for share and flows: build their own or choose the native flow. The native flow is a pretty horrible experience, but building your own is a lot of work.

We also want to make it easier to use YesGraph. We want to make using our API easier than doing anything else. Our standard is the native share flow — it needs to be just as easy but with far better performance.

So we’re going to build an SDK for iOS that manages the sharing and invites. We’ll have connecting to a mobile address book, and we’ll use YesGraph contact ranking to drive a huge performance book there. This is the next step after building a Python SDK to use YesGraph.

It turns out our friends at Branch Metrics have already built a flow that has a lot of things we like. So we’re going to enhance it with YesGraph’s API. Go see the fork here on Github. The original repo is here. This means all the links sent can be wrapped with Branch deep links. Bonus!

We’ll also optimize the experience for sharing with a few design changes. This is going to be a work in progress that gets optimized with behavioral data over time. We’re following a pattern started by Stripe, who made an optimized embedded checkout flow. We love using that, and want to make a similar flow for sharing. You can expect Android, web, and mobile web versions too.

We need your help. We want feedback on how to package up our API wrapper and on how people want to customize and tune this flow. Please get in touch on Github or at support@yesgraph.com if you’re interested in helping.

We’ll also publish a few posts on this blog related to the effort. We’ll talk about the design patterns of what makes this flow work really well. Subscribe to get future YesGraph posts here.

Finally, we’re hiring for a mobile focused engineer. We think this effort is so important that we want someone on the team dedicated to building the best share flow ever. Email me at ivan@yesgraph.com if you want to help.

When to Layer Virality

By Ivan Kirigin –   - comment

Pernicious ideas around virality are too common. People think they can just sprinkle virality on top. People often think they need to work on virality really early when developing a product. The right answers are more textured.

Screenshot 2015-04-28 08.52.23

Activation and retention should be your primary focus. Don’t worry about top level growth. Don’t worry about K-factor or some other viral jargon bullshit. It is much simpler than that.

Just answer this question: “do people like my product?”

Activation is a measure of someone getting into your product to really experience it. At Dropbox, activation is measured by installing the desktop client and syncing a file. Mobile might be changing this, but for years it was an excellent measure. The reason is that almost no good users didn’t first follow those steps.

Onboarding is tricky, and getting someone to have a great first experience is an essential part of making them stick around, a.k.a. retention.

Retention is actually the most important part of virality. Go read this post of ours on the core metrics to any viral flow. The very first number I recommend tracking is what percentage of your users are sending invites. Practically, only retained users are sending invites.

If only 25% activate and 25% of those that do are retained, then your user base you hope starts inviting others is much smaller. It is easier to make activation go from 25% to 50% than it is to double your virality. Plus onboarding and retaining invited users still matters — so increasing retention increases the number of new active users you get from those invited via virality.

Exception: Density Impacts User Experience

There is an exception to this focus. Some applications have a dramatically different user experience when they are empty or full of your friends. Google+ is a bad experience because no one is on it, not because it lacks feature parity to Facebook.

How do you get density without being huge? Isn’t there a chicken and egg problem here?

The solution is to focus on density at the start. Facebook started at Harvard, Airbnb started in San Francisco, and eBay focused on niche products.

Alternatively, make a single player experience in your app that works without other people. Instagram made your photos look cool and easy to share to other networks before they had their own network. Dropbox syncs files across your computers before you had any shared folders.

Density can be achieved with community engagement or paid acquisition targeting a narrow area. It can also work with people inviting friends because friends tend to be in a cluster.

For YesGraph, we have a network effect with data not with people. The more we see, the better we perform. Luckily, we have a “single player experience” that helps us understand your data without needing to see all the data in the world.

Exception: Density Impacts Operations

If you’re working on an on-demand product, often times the density will affect whether your business is viable or not. You often have fixed costs proportional to peak load, meaning low density might cause negative unit economics. You lose money per transaction. With higher density, that can be flipped, so that your fixed costs help you scale really fast. 

This and the previous example are both network effects, and you need a way around them. Most on-demand services start in a single city, even a single small area within a city.

Make Sharing and Invites First Class

If you do think being social is an essential part of your experience, you must make it a first class citizen. You must make the sharing and invite features so central to your app and so obvious to use that almost everyone in your app does them.

The best example here is probably WhatsApp. It’s a messaging tool that literally doesn’t work without others. There is a social network effect with no single player experience. Even Facebook started with building profiles for yourself.

The invite flow is so good it feels like a native experience. It is also incredibly easy to get into the flow — just try to message a friend.

YesGraph Helps You Grow

Our goal at YesGraph is to make your sharing an invite flows perform a better. So when you do focus on this, try us out. Here is how it works: we can recommend who a user should invite. We first process a user’s network, like their mobile address book, Facebook, or email contacts. Then we recommend the top contacts for the app. We adapt and tune the ranking for your app — whether it is B2B or something for consumers.

 

Subscribe to get future YesGraph posts here.

YesGraph’s Traffic and Conversion Numbers from TechCrunch, Product Hunt, and Hacker News

By Ivan Kirigin –   - comment

nuclear artillery

YesGraph is just getting started with our growth focused API. We announced our seed round on TechCrunch, then opened up our closed beta on Product Hunt. More recently, we had a few blog posts on front page of Hacker News.

Because we’re so young, it is really easy to differentiate traffic and impact. When you get a big spike, you know where it came from.

This means that we can compare the stats from those different sources, and also the downstream behavior.

When we announced on TechCrunch, we weren’t open for signup. So as a proxy, we are showing subscription to our waiting list. For Product Hunt and Hacker News, those are actual signups.

We’re showing total number of signups and visitors, not breaking out the source. So when we hit our mailing list that you could sign up, lots of conversions probably came from there.

We have a developer facing product. That means companies integrate our API into their products. As a result, it isn’t like a signup is what we really care about. We care about apps live in production. The eventual conversion rate isn’t obvious because that takes time to accumulate. So we’re not showing those numbers.

TechCrunch

  • Story link
  • Date: February 27, 2015
  • Uniques: 2,281
  • Mailing list signups: 369
  • Conversion rate to mailing list: 16.2%

Product Hunt:

  • Post link
  • Date: March 25, 2015
  • Uniques to PH specific landing page: 4,767
  • Total uniques: 9,081
  • Votes: 376
  • Mailing list subscribers receiving announcement: 6,237
  • Opens on announcement email: 2,511 (40.3%)
  • Clicks on announcement email: 470 (7.5%)
  • Signups: 705
  • Conversion rate to signup: 7.8%

Hacker News:

  • Store your own analytics data:
  • The Math of YC Dilution,
  • What Changed at YC from W08 to W15,
  • Uniques to home page: 1,855
  • Signups: 44
  • Conversion rate: 2.8%

So what can we conclude from the numbers? The conversion numbers are a little off. It is easier to signup for a mailing list than for a service. Also my blog posts brought some traffic but it didn’t convert well. The post about analytics actually converted traffic to signup much better than the posts about Y Combinator.

We also see the relationship between Hacker News votes and traffic. The visits per vote go up with more votes.

The elephant in the room is that Product Hunt sends a hell of a lot more traffic than TechCrunch. I think the reason is that there are lots of TechCrunch stories that split attention, but we were in the top 5 on Product Hunt for the whole day. TechCrunch has a larger audience for now, but Product Hunt’s audience likes to get out and try things.

Overall, you should borrow these numbers if you’re trying to estimate impact of a press launch. Each of these bits are successful. It’s great to be featured in TechCrunch, we were at the top of Product Hunt, and we’ve had multiple front page of Hacker News blog posts.

I often see people have unreasonable expectations around what getting each of these produce. The best is to focus on building a great product and take a measured approach to getting publicity. It isn’t a silver bullet, because silver bullets don’t exist.

 

Subscribe to get future YesGraph posts here.

 

What Changed at Y Combinator After 7 Years

By Ivan Kirigin –   - comment

My startup YesGraph just went through the Winter 2015 batch of Y Combinator. This is actually my second time, after going in Winter 2008 for my first startup Tipjoy. A lot changed and a lot stayed the same, so lets walk through it.

bttf22

Size

The W08 batch had 21 companies. The W15 Batch was 116. You can probably guess what needed to change for this to work. Size is in the background of this entire post.

Focus

YC is all about a focused effort to build your startup. They’ve refined how they phrase this, but the intent is that you exclusively:

  • Code and talk to customers
  • Eat, sleep, and exercise

You should do these at the exclusion of everything else, including hiring, fundraising, long term biz dev, conferences, vacation (obviously), and anything that isn’t about your health or your company’s core health.

The hiring bit was tough for me in W15 because we raised $1M before YC. I was eager but I’m only now ramping up. In W08, we’d raised $50K from friends and family, making it a non issue.

Partners

YC went from the 4 founding partners to over 20 full time and many part time. Paul Buchheit was always around in W08, though I don’t know if he was an official part time partner. He invested in and gave advice to the companies in the batch (thanks Paul!). Carolynn Levy was still at WSGR, but came by to give advice. Kate Courteau was also around, but again not officially besides doing all the great architectural work of the space.

Now you have a dozen YC alums that are back as full time partners. This increased firepower is the main way YC scales: horizontally. Everyone wants to meet with Paul Graham because his essays were startup preschool for many founders, but there just aren’t enough hours in the day for him to meet with everyone. Now he is retired from the day to day, and only does periodic office hours that almost instantly fill up.

Groups

YC has tried to mimic the earlier days by breaking the batch up into groups with group partners. So instead of talking to PG & JL, I mainly talked with Garry Tan and Justin Kan. It is important that these group partners know who you are and know your product and market. With so many companies, it is really easy to get lost as an advisor. This focus bring deeper insights.

Paul Graham is a kind of stateless incisive advice machine. I bet he couldn’t name what YesGraph does. Our last conversation was more cocktail party than office hours. In fact I didn’t have official office hours with Paul or Jessica or Trevor, though talked to them all informally. It’s actually great being an alum and coming back because it’s like meeting up with a friend you haven’t seen in a while.

Group Office Hours

The weekly dinners when there were fewer companies in W08 brought a more intimate setting. YC has tried to mimic this with group office hours. I should preface that they are always experimenting and changing things up. I probably missed some earlier versions of this and will miss what they try for the next batch.

There are certainly lots of questions that benefit the group. Many companies are trying to scale sales. Many companies are trying to grow a consumer audience.

There were more product demos and founder to founder feedback in W08 than in W15. There was more product advice and less growth advice.

Network

The YC Alumni network is huge. That is amazing to get reach into so many companies and their networks. But there is no such thing as an intimate group of thousands. With size comes dilution per relationship. Sam Altman said, “you can’t all just email Drew Houston at Dropbox about anything; respect their time.”

I completely agree, but in 2010 I started working at Dropbox by emailing Drew.

Going through a second time is interesting because I was ostensibly already part of the network. But there is a difference between having had a YC company and currently running your YC company.

Dinners

YC in W15 has a chef. YC in W08 had PG and crock-pots full of slop. That is what they called it, but I actually really liked it! They still serve no beer, which I’ve always found a bit odd. Founder bring their own sometimes.

The dinner speakers are stellar. There were more YC alums in W15. There seemed to be more billionaires in W08. On balance, I bet startups that recently escaped the trough of sorrow to reach initial traction are more valuable for young companies. In W08, Ev Williams doesn’t actually know why Twitter took off. Marc Andreessen is a lion and gave a convincing case in W08 for why Ning’s “double exponential” viral loop was going to take over.

Advice

At this point, I’m already connected to very many notable people in tech. I’ve seen everyone important at least give a talk. I can predict exactly what an investor will tell the batch about how to pitch them. I’ve successfully pitched many investors and go to them for advice.

But there is something useful about being told the fundamentals. It isn’t as complicated as you like to think. You aren’t special. You just need to do the work (code and talk to customers) to win. Growth solves all problems.

There was less product advice in W15, but the advice I got was good. That is probably because the product I’m building is more complicated and harder to give advice about. Partners aren’t going to dig into YesGraph’s machine learning or social graph analysis. It was easier to advise building something for Twitter at Tipjoy. There are many developer facing startups that have successfully gone through YC, so I did get great advice there. Some came from part time partner and Parse founder Ilya Sukhar, which shows that the part time partner contribution is significant.

The best advice came from 1:1 office hours, like with my group partners, Garry and Justin, and Sam Altman. It was the most detailed and focused.

Software

YC has more software to organize things, but it is just getting started. The office hours booker is convenient, but doesn’t have notifications. Hacker News now has a YC founder forum that helps scale the community, but it also doesn’t have notifications. There is software to organize group office hours, but that software is google spreadsheets.

Overall I’m excited to see what they can do here. LinkedIn has one core job, professional networking, and it fails miserably for a group as powerful as YC. Once YC ups their software game, it will be more powerful than any other tool out there. They definitely have top software talent working on it.

Tone

The founders in the batch are really excited. Nothing has changed there, and I love it. Many are really fresh. Many more are far more experienced than I was the first time through. Everyone wants to win. But startups are highs and lows, and when companies are going through tough times fundraising, the network is there.

Sometimes they need to say things that I’m surprised they need to say. This is what happens at an operational scale I guess. I’ve heard some surprising things about what some idiot alumni have done, and they just don’t want to see it repeated. They also need to be crystal clear in their advice, which means saying some things obvious to almost everyone. That “almost” is the key bit.

The partners are all wonderful people. This post from Jessica Livingston about culture is spot on. There is something special about the people they recruit to be involved in YC. Their advice is often blunt, and there is a fine line between incisive and harsh. The tone sets up an environment that balances willingness to ask any questions with the direct advice needed to solve the problem.

YesGraph Specific

So why did YesGraph apply? We actually got rejected for W13 when we applied with a recruiting idea. Thankfully we eventually got in so I can actually tell that story! You’d be surprised by the number of YC alums that get rejected when applying again — and they eventually get in.

After we pivoted to focus on growth and raised a new round, we were focused on something in our wheelhouse. The team was better suited for the product and market and overall in a better position to win.

So why apply again? The advice and network are a wonderful reason to do YC. It’ll help with recruiting and future fundraising.

For YesGraph specifically, another strong factor was that we were a developer facing service. Our batchmates proved to be excellent early customers, giving essential feedback on the product. I talked to lots of companies about growth, and hearing their concerns and how they thought about the world was wonderful. This focused user research would be hard to replicate because the tone of willingness to help is more rare with normal use research.

Also, there have been some amazing developer facing services coming out of YC. Heroku, Parse, Stripe, Docker, and more. I think it is because the partners are so much more technical than most investors, and they’ve built companies of their own. They know such services matter and how to support them.

Another factor is Demo Day. I’ve fundraised enough to know that it is painful at best, and deadly at worst. Demo Day is something special, and many companies going through it don’t even know how good they have it. Demo Day sets up the perfect environment to make a market with artificial deadlines with investors filtered in batch. If fundraising is a painful marathon, Demo Day is like steroids. It makes it easier to get to the finish line and is an unfair advantage over other startups.

A personal emergency actually prevented YesGraph from presenting at Demo Day. Considering we raised a seed before YC, this isn’t bad timing actually. We’ll make it up in the S15 demo day, hopefully targeting our Series A. We have a lot to do between then and now to earn it.

If you want to help us make it, go try out YesGraph. We help your app grow by recommending who users should invite. If you already are using us, tell your friends about YesGraph.

 

Subscribe to get future YesGraph posts here.