I think of YesGraph applying whenever a user takes an operation over their contacts. Invites, sharing, referrals etc.
For B2B that can be a collaborative software for companies like Slack, Yammer, or a tool a team uses like CRM. For consumer, invite flows to add friends on an app have a lot of room for optimization.
The idea is based on what pioneering social networks like Facebook and LinkedIn have done with tools like People You May Know (PYMK). They drove an incredibly amount of performance improvements.
[Disclosure - I work at YesGraph]
What are some lessons learned from Tipjoy (YC W08) that you're applying here or doing differently with running YesGraph?
I also find myself giving this advice to others, including YC batchmates. The hard part is being diligent in applying it.
The first TechCrunch launch for Tipjoy was when we turned the product on. And were were traveling, so we were fixing bugs in the airport. Don't couple your press launch with your product launch, kids
Firstly - congratulations on your company's success and fundraising round.
As for the AMA, I'm curious of the differences you see in YC between now and 7 years ago.
There are some obvious ones, like larger class sizes, more partners, different funding amounts.
But YC is way more popular now, some of its earlier companies have had tremendous success, and I'm sure YC partners have learned a lot in 7 years of what works well and what doesn't. So I'm quite interested in how their strategy has changed in 7 years from the point of view of a startup founder. Eg, is there a different relative focus on building customer base vs product development, or a different view on accepting VC funding, etc? Are the office hours more intense, and does YC expect more progress faster throughout the program?
The other day they had a YC Alumni party and Jessica Livingston, my wife (+Tipjoy Cofounder), and I were chatting. The general sentiment is "OMG 7 Years!"
Yes, the obvious things are obvious: much bigger and more advanced. The reputation has improved. The process is more solidified.
Much of the advice is part of my DNA now when it comes to how to build companies. So when I hear it, the ideas are reinforcing rather than new. I can easily predict how a VC might answer a question, for example, about their process, what they look for, etc.
So the big difference is what I'm looking for out of YC. I want more anecdotes and operational details to enrich my understanding of how to build a great company.
Beyond that, one difference is how they need to treat the batchmates. They have warnings about what not to do that sound like they are talking to children. I think "why would anyone do that?!" when hearing the warning of what not to do. It turns out that at scale you see a lot, so they warn against things they've seen. Surprising, but true.
Another difference is that a lot of the speakers are YC alumni. I think they can commiserate and tell more interesting stories than people that have been very established and rich for a very long time.
Another difference, related to size, is that I don't know everyone. This is a pretty big difference but I end up talking to a few people repeatedly, making a closer connection.
I could go on, but I think this should probably be a blog post :)
LOL at $1M being small. Imagine explaining that to your grandparents.
But you're right! This is just a seed. Demo day is coming up, so we're thinking about the strategy there with a larger seed. I guess I'm not allowed to say I'll be fundraising because of SEC rules? [edit: for those confused, there is a rule that you can't fundraise in public. I think that means I can't say "we're fundraising" but I'm not sure about future tense. IANAL]
We have a team of 4 and I'd like that to be 6 or 7 soon. Payroll makes up most of our costs.
As for others, I built this concept in 2011, unfortunately Facebook shut us down after we hit about 1.5 million queries per month. Never got access to LinkedIn.
Facebook is certainly concerned about passing around user tokens, so we won't do that.
Facebook doesn't control the email or phone number graphs though. And users don't connect directly to Facebook via a YesGraph Facebook app, so there is nothing to shut down.
There is more to say about platform risk here. I've built apps on every major platform. Email me: ivan@yesgraph.com
These invite systems are often fairly basic – they connect to a phone’s address book and then force the user to sift through their hundreds of contacts for those they think would be interested in joining the new app, too.
A Y Combinator-backed startup called YesGraph wants to make these invite and referral systems more intelligent, with a tool for developers that puts the best contacts – meaning those who are most likely to accept an invite – at the top of the list provided to users.
So they want to mine your contacts list, identify likely suckers, and spam them.
This is why most apps shouldn't have access to your contacts list.
Actually what most apps do without YesGraph is try to get users to send-all to every contact. Ugh. We want to fight that.
No one wants spam. It is a bad experience and has horrible conversion rates. No one wins. I literally pushed for removing send-all while running growth at Dropbox. We saw an 80% decrease in emails sent and only a 3% decrease in signups.
We want to make apps smarter using the data users have already shared with them. It's a better user experience that drives deeper engagement. Everyone wins.
In short, look at # sending, # invites, and % accept. We know we can do a lot better than the status quo.
Invite all: very small # sending, large # invites, very small % accept. By the way, getting marked as spam hurts all your invites, lowering your overall acceptance rates even for direct invites that weren't spamming the whole list.
YesGraph: larger # sending, more # invites, larger % accept.
This by the way is how to tell the difference between buzzword bullshit "viral" and real products: Math.
I can understand how YesGraph gets a larger % accept, and probably larger # sending because you are so much better than the terrible "solutions" built into most apps, but I don't see how larger # invites directly follow from what you have. Isn't the point fewer, better invites?
When comparing to reply all it will be fewer. Most people sending invites send one or two. Making that two or three, on average, is huge.
It's hard to generalize about performance like this because apps are so different. Even within Dropbox for example, there are multiple invite channels, and their performance stats aren't similar.
I've heard that idea a few times: that word of mouth will find a way. It is generally true that great products spread, so I don't fundamentally disagree.
But for everyone that has ever worked on building a product that didn't get traction (and I presume MANY people on HN fall into that camp), they need to know this isn't the whole story. You can drive far more performance by making sharing easier. Before you had to put a lot of engineering work into it, which is what YesGraph wants to solve. We'll do the heavy lifting for you.
This is all from experience at companies at Facebook and Dropbox. I've seen the inside and know how it actually works.
Why did you guys pivot away from employee referral amplification? The original idea seemed incredibly powerful - we all know hiring is broken, and amplifying the referral graph seemed like a great way to add a lot of value to growing orgs.
#1 This new idea is better. It's a bigger opportunity with larger barriers to entry that we're especially well positioned to take advantage of.
#2 Deployment of the recruiting app was challenging. The old app worked like this: you connect to Facebook, LinkedIn, and email, and we parse and rank your contacts to find matches for a job rec. But that means employees go through multiple auth flows -- and recruiting teams need to push their team to do it. Recruiters are pitched new products weekly, and have a barrier to getting their team involved. As a result, most recruiting teams are incredibly inefficient and make poor use of technology. It is hard to change that.
#3 We saw better traction with pilot customers for the new idea. That is how I decided to change directions: sell the idea before making the product. I highly recommend people focus on customer development when thinking about a new product -- rather than just on what is technically possible.
24 comments
[ 2.7 ms ] story [ 71.6 ms ] threadThis is actually my second time through YC. I was in W08 with Tipjoy. AMA
For B2B that can be a collaborative software for companies like Slack, Yammer, or a tool a team uses like CRM. For consumer, invite flows to add friends on an app have a lot of room for optimization.
The idea is based on what pioneering social networks like Facebook and LinkedIn have done with tools like People You May Know (PYMK). They drove an incredibly amount of performance improvements.
We want to bring that kind of insight everywhere.
Overall the core advice is the same. I just listen to it and apply it better. This post gets it right: http://blog.samaltman.com/startup-advice-briefly
I also find myself giving this advice to others, including YC batchmates. The hard part is being diligent in applying it.
The first TechCrunch launch for Tipjoy was when we turned the product on. And were were traveling, so we were fixing bugs in the airport. Don't couple your press launch with your product launch, kids
So, yeah, not making that mistake this time :)
As for the AMA, I'm curious of the differences you see in YC between now and 7 years ago.
There are some obvious ones, like larger class sizes, more partners, different funding amounts.
But YC is way more popular now, some of its earlier companies have had tremendous success, and I'm sure YC partners have learned a lot in 7 years of what works well and what doesn't. So I'm quite interested in how their strategy has changed in 7 years from the point of view of a startup founder. Eg, is there a different relative focus on building customer base vs product development, or a different view on accepting VC funding, etc? Are the office hours more intense, and does YC expect more progress faster throughout the program?
Cheers and thanks for offering the AMA!
Yes, the obvious things are obvious: much bigger and more advanced. The reputation has improved. The process is more solidified.
Much of the advice is part of my DNA now when it comes to how to build companies. So when I hear it, the ideas are reinforcing rather than new. I can easily predict how a VC might answer a question, for example, about their process, what they look for, etc.
So the big difference is what I'm looking for out of YC. I want more anecdotes and operational details to enrich my understanding of how to build a great company.
Beyond that, one difference is how they need to treat the batchmates. They have warnings about what not to do that sound like they are talking to children. I think "why would anyone do that?!" when hearing the warning of what not to do. It turns out that at scale you see a lot, so they warn against things they've seen. Surprising, but true.
Another difference is that a lot of the speakers are YC alumni. I think they can commiserate and tell more interesting stories than people that have been very established and rich for a very long time.
Another difference, related to size, is that I don't know everyone. This is a pretty big difference but I end up talking to a few people repeatedly, making a closer connection.
I could go on, but I think this should probably be a blog post :)
I for one would be interested in reading a more detailed blog post if you are able to get to it.
Cheers!
Good luck
But you're right! This is just a seed. Demo day is coming up, so we're thinking about the strategy there with a larger seed. I guess I'm not allowed to say I'll be fundraising because of SEC rules? [edit: for those confused, there is a rule that you can't fundraise in public. I think that means I can't say "we're fundraising" but I'm not sure about future tense. IANAL]
We have a team of 4 and I'd like that to be 6 or 7 soon. Payroll makes up most of our costs.
As for others, I built this concept in 2011, unfortunately Facebook shut us down after we hit about 1.5 million queries per month. Never got access to LinkedIn.
Facebook doesn't control the email or phone number graphs though. And users don't connect directly to Facebook via a YesGraph Facebook app, so there is nothing to shut down.
There is more to say about platform risk here. I've built apps on every major platform. Email me: ivan@yesgraph.com
So they want to mine your contacts list, identify likely suckers, and spam them.
This is why most apps shouldn't have access to your contacts list.
No one wants spam. It is a bad experience and has horrible conversion rates. No one wins. I literally pushed for removing send-all while running growth at Dropbox. We saw an 80% decrease in emails sent and only a 3% decrease in signups.
We want to make apps smarter using the data users have already shared with them. It's a better user experience that drives deeper engagement. Everyone wins.
Total no-brainer to use a drop-in like this. Make onboarding a way better experience, captures exactly the same, if not more, value on referrals.
In short, look at # sending, # invites, and % accept. We know we can do a lot better than the status quo.
Invite all: very small # sending, large # invites, very small % accept. By the way, getting marked as spam hurts all your invites, lowering your overall acceptance rates even for direct invites that weren't spamming the whole list.
YesGraph: larger # sending, more # invites, larger % accept.
This by the way is how to tell the difference between buzzword bullshit "viral" and real products: Math.
I can understand how YesGraph gets a larger % accept, and probably larger # sending because you are so much better than the terrible "solutions" built into most apps, but I don't see how larger # invites directly follow from what you have. Isn't the point fewer, better invites?
It's hard to generalize about performance like this because apps are so different. Even within Dropbox for example, there are multiple invite channels, and their performance stats aren't similar.
But for everyone that has ever worked on building a product that didn't get traction (and I presume MANY people on HN fall into that camp), they need to know this isn't the whole story. You can drive far more performance by making sharing easier. Before you had to put a lot of engineering work into it, which is what YesGraph wants to solve. We'll do the heavy lifting for you.
This is all from experience at companies at Facebook and Dropbox. I've seen the inside and know how it actually works.
#1 This new idea is better. It's a bigger opportunity with larger barriers to entry that we're especially well positioned to take advantage of.
#2 Deployment of the recruiting app was challenging. The old app worked like this: you connect to Facebook, LinkedIn, and email, and we parse and rank your contacts to find matches for a job rec. But that means employees go through multiple auth flows -- and recruiting teams need to push their team to do it. Recruiters are pitched new products weekly, and have a barrier to getting their team involved. As a result, most recruiting teams are incredibly inefficient and make poor use of technology. It is hard to change that.
#3 We saw better traction with pilot customers for the new idea. That is how I decided to change directions: sell the idea before making the product. I highly recommend people focus on customer development when thinking about a new product -- rather than just on what is technically possible.