Problems in the Recruiting Market

YesGraph pivoted away from a product in the recruiting space. I get asked about recruiting a lot by other founders, so I wanted to explain some problems that startups in the space might face.

I’ll also cover how we decided to pivot, how we decided to take the plunge. But that will be in a future post, so subscribe here to get new posts right away.

Because I’m not in the recruiting business anymore, I don’t have to be nice to the key players. That’s great news for you because so much written about the space is vapid bullshit.

How Old-YesGraph Worked

Today YesGraph helps apps grow through social graph analysis. We started out as a recruiting app which helped companies boost referral recruiting.

It worked like this: first create a job spec and invite your team. Your employees connect to Facebook, LinkedIn, and email address books. YesGraph would parse and clean up these contacts, and rank by the ones that fit the job. We created a feed of your contacts, with “yes”/”no” one-click referral actions. Those referrals enter your pipeline. Our core problem was not enough companies got that far.

Saturated Market

Finding and keeping the best people is literally the most important job at every company stage. From cofounders, to early team, to growth stage, to retaining talent past an IPO. Recruiting is valuable!

But this isn’t a secret and the space is incredibly crowded. Just look at AngelList for “Social Recruiting”

companies better

This is obvious even to casual observers.

What isn’t so obvious is how this affects people in the market. You might think your product is better than everything out there, but the recruiter you’re pitching might have heard that every week from a new startup. This can dramatically affect how easy it is to sell your product.

At YesGraph, this became a problem with team onboarding. We were actually 10X better… once you were inside the product with your data. This required recruiters to tell their teams, and the employees to connect to the data, and then you’re in. So there were two kinds of companies, those which did this and got a huge number of great referrals, and those that didn’t.

Problems with Pricing

We started out with $19/employee/month. The logic here is that a typically referral bonus is a few thousand dollars, and the cost of other channels are higher. So if we enabled a single referral per seat per year, we’re still incredibly inexpensive.

The problem appeared to be mentally mapping that price to a whole organization, and it was a lot of friction to even try a pilot. Anchoring to the value of a new hire with referral bonuses seemed too much for some recruiters. They treated referrals as “theirs”, despite wanting more of them.

Then we moved to a model with tiers of the number of employees. We blogged about it here.

new pricing

This was definitely more effective. But this was on top of other tools companies were paying for, like their applicant tracking systems. Once you get outside of tech, this starts to be a budget problem. Some companies just don’t hire for a whole quarter or year, and their appetite for SAAS subscriptions is weak. That isn’t like CRM or other markets where your company is dead if it isn’t closing deals.

A common model for sourcing tools is to pay a placement fee for a hire. Sometimes it is 20% annual salary or higher, which is CRAZY expensive.

I should stress this is common in executive recruiting and in hot tech. For most companies, this is wildly too expensive. I expect the next contraction in tech will cause a bunch of recruiting companies to lose momentum as their placement fees aren’t tolerated.

I regret not experimenting with fees for placement. It could have been much more revenue, but I didn’t think it was fair. I shouldn’t have been so opinionated.

One wrinkle I’ve seen is how some companies get paid incrementally over years. So instead of 15% salary upfront, it is 20% paid in 1% increments monthly. This makes sense for startups because the discount rate is so high. The net present value of future round money is small. It’s better to spend less now, live longer, and build your team to earn the round.

The Cluster Fuck of Applicant Tracking Systems

This is such a disaster, it’s hard to know where to start.

Applicant Tracking Systems (ATS) are a collection of tools to help companies manage the recruiting process. This means different things to different companies, so the result is a hodgepodge of features and flows. Document management, req writing, syndicating to job boards, processing applications, collecting interview feedback, managing referrals, and a dozen other things. Most end up as a product design mess.

Some are tailored to different market segments or focus on different kinds of talent. Some are for huge companies with crazy analytics and automation needs. This means that there is no standard, but huge fragmentation.

Switching costs are incredibly high and recruiting teams are afraid of it. This means selling to users of one ATS hoping they switch to yours is hard.

Worse yet, most are closed and don’t care about your integration. These aren’t modern, developer-friendly services. If APIs are BD 2.0, ATSs use BD 0.1: GTFO. They want to lock down the pipeline and implement everything themselves, poorly.

So where does a new company start? Do you compete directly and implement the features? Do you try to integrate with dozens of players? Do you ignore it and hope it doesn’t matter for your early traction? Do you try to hack an API around a service that doesn’t have one? What a mess.


LinkedIn Fucks Users

I should stress that I love LinkedIn. I use it all the time. Plus the people that work there are incredible.

But they did something really bad. They promised a network, and then closed it down. Their API no longer allows a user to share their network with another app. This eliminates the main value of LinkedIn, the network. Yes, LinkedIn earned it, but the opportunity cost here is incredible. New products can’t be made by other companies that leverage their network.

Some startups have decided to scrape lots of that data, but that is dangerous territory because LinkedIn’s legal team has a budget 10X that of your last round.


So LinkedIn keeps the data for themselves, and then they don’t do anything new with it! Where are the productivity tools that leverage the network? Besides recruiting and some sales, why aren’t professionals on LinkedIn all day?

They could definitely implement a better version of the old YesGraph for referral recruiting, and 4 years after I had the idea for it, they might just implement it. They could compete with Slack with full knowledge of your org chart, but they don’t. They could build a CRM, but they haven’t. They could build an ATS, but they haven’t. They could build tools for career discover, knowledge management, online education & certification, company directory & interest graph, internship applications, automated assessment, a remote freelance marketplace, crowdfunding, crowdsourcing, and a million other things. But they haven’t.

I hope they start to move here, because I want to live in a world with these better tools.

Recruiters from Mad Men

I’ve worked with many very savvy recruiters. I’ve also worked with some that think about recruiting in no different way than the characters on Mad Men. I mean literally their thinking hasn’t changed in 60 years.

Find a stack of resumes, and work through the list.

As a technologist, I don’t get this. The process of managing recruiting is painful for everyone involved. But there appears to be a huge amount of resistance to the upstarts working to solve problems.

mad men

Let me give a really simple example. I have some resumes. Some passed my filter and some didn’t. Train an automated filter to go through and score future resumes by likelihood I’ll like them. Then instead of processing the first in first out, look at a ranked list. It’s been 15 years since we solved the email spam problem, but my idea is actually innovative in recruiting. It’s a tech backwater focused too much on people. Ironically, better tech could free recruiters to focus more on the human aspect of recruiting.

Another, simpler example. Why do people stop making referrals? The common guess is that it’s because they run out of contacts. Nope, consistent feedback has been that an employee has a bad experience and doesn’t want to do it again. It can be literally as simple as telling the employee who made the referral the current status of the candidate. All you need is more transparency, even if the candidate is rejected. Getting this done is an innovative idea, and that’s sad.

Naive Founders

The technical innovation potential is clear to engineers. The problem is that they might not understand recruiters — especially how recruiting works outside tech hubs. This is a big deal when your go to market and sales process are essential to getting traction and reaching the large audience your VCs expect.

For example, I just met a founder working on some cool tech in the space. I like the problem and I hope they win. But he had never hired anyone. He had never done sales. There is just no chance he understands his customers yet. If you’re self aware, you’ll figure this out and solve it. A founder’s naiveté can be an advantage in daring to take on a huge industry. Just look at Stripe taking on payments. The difference is the Stripe founders really understood their customers, the developers, and the industry knowhow was just an implementation detail.

Engineers that understand the tech but not the customer should focus on how fast they can learn about their customers — table stakes for deploying your tech.

Leaving Recruiting

YesGraph ended up exploring and executing a pivot into a whole new product outside of recruiting. Sure there were problems with recruiting, but we found something compelling to go forward. Now we help apps grow through social graph analysis, and I’m incredibly excited to blaze this trail.

We’ll cover exactly what we did to pivot in our next post. Subscribe to updates here.

And if you’re at a recruiting startup and traumatized, come chat in our growth-focused community slack:

Growth Teams Must Have Aggressive Parallel Execution

bolt 3

Who is the most aggressive person in your company, driving the hardest to hit your goals?

They say the most aggressive person should be the head of growth, with #2 being the CEO. Growth teams should be so aggressive and autonomous that the only person reeling them in is the CEO.

Your company picks a goal and knows how to move the needle by building a map of the product, analytics, and marketing. You come up with new ideas and triage by cost, benefit, and risk. Next comes execution. Execution needs to be aggressive and parallelized to drive as much learning and experimentation as possible. It’s a race for your life — your startup’s life.

So how do you do it? This is actually a question about how you organize your teams. It’s a question of company culture. We’ll explore these ideas in this post.

Growth Team vs Growth Managers

Should you have a growth team? Or should you have people responsible for growth on individual teams?

For a small startup, the answer is easy: the CEO is the head of growth. You need to know you metrics inside and out. You need to understand the strategy to get traction, and you’re probably the one executing on that mission. You need to deeply care about your customers and understand what makes them tick.

What about larger organizations? The answer isn’t obvious and it probably depends on how your current company is organized.

If there is a dedicated growth team, who triages the product roadmap for other teams? What rubric is used in that triage if not hitting some clear objective? Who owns the metrics?

If you have individual members responsible for growth, how do you test bold new growth ideas that take dedicated resources? How are lessons learned shared across your organization?

When designing the shape of your company, the important part is understanding these tradeoffs and making your objectives clear. You should experiment with changes that fit your company and see what works best.

In-House Growth Consulting

If I were joining a new company without a strong focus on growth, where might I start?

I’d go to every other team and ask two basic questions:

1- What are you working on?

2- What do you think will happen when that launches?

It’s shocking how many companies don’t ask such basic questions. There are a myriad of excuses — maybe focusing on quality over performance. Maybe thinking that a lack of corollary makes predicting the future hard.

Call this out. Prediction is hard, but that’s no excuse.

Going through a product development cycle with these questions in mind gets a company on the right track. After a launch, did things go as expected? Why not? What did we learn? What can you do next time? How can we organize our team in a way to deliver better results? If that worked, what can we do more to double down?

This is how a growth team thinks. Start by asking your product leaders some basic performance focused questions and keeping score.

Analytics Life Blood

Growth teams must make informed decisions to win. Early on, this might be qualitative data from talking to customers. At larger scale, aggregate behavioral data speaks volumes.

How are questions answered in your company? Put aside the mechanics, though they do matter. This isn’t about your analytics tech stack. If someone on your team has a product question, what do they need to do to get an answer?

Can they get an answer themselves? Do they need to be in good graces with Bob running the analytics servers? Do they need to know SQL? How are questions triaged? How are answers shared?

Build an organization where the cost of asking questions is as low as possible. Friction means some questions just won’t get asked and you’re on track to building a culture where data, even anecdotal from customers, isn’t needed to make decisions.

I’ve seen different organizations deal with this in different ways. Certainly there are instrumentation and exploration tools that can be bought or built to enable teams to answer questions. The collaborative side to these tools is the most interesting.

Dropbox at one point built a system jokingly called Coura. It was simple: ask a analytics question and say why you want to know the answer. When someone was ready to work on it, the system asked if the information was still needed. Anyone could see the other questions asked and their answers. Engineers were confident that the work they’d do to run an analysis was always needed and impactful.

At another company I helped, they built a system for managing complex queries over large data sets. One interesting byproduct was the ability to see the queries others were asking. This become an onboarding tool for product analysts. It wasn’t treated as such, but the teaching and sharing power was incredible.

Such social tools within organizations aren’t developed enough.

There are many vendors selling analytics tools and and business intelligence solutions. Their sales process and user interface distract you from the main issue in deciding what to use:

Product Needs Drive Analytics

Way too often, product teams dig into analytics tools and try to learn what the hell is going on with their product.

This is backwards. You need to start asking questions from the product side and answer in whatever way is possible. This often means writing custom code to get a real answer. This often means adding a new tool to slice and dice your data, or connect multiple data sources together.

Starting from the tool and working through questions doesn’t work well. The reason is that tools are general and not designed specifically for your company. They have a language, and not knowing your dialect means you don’t even think to ask your questions when you start from the tool.

For example, Google Analytics is very focused on pageviews. It doesn’t focus on users and their actions. If you started with GA, you’d be asking the wrong questions and working towards the wrong goals. If you focused on your product and users, you might then instrument the product with something like Mixpanel, and focus on what is really going on.

But even Mixpanel has some strong opinions. They are great at funnels and events. But if you launch a new feature and want to know how that affects retention, their cohort analysis tools aren’t as strong as Amplitude, an upstart analytics tool that focuses a lot more on cohorts.

Whatever the tool, the point is that you should focus on what is really going on with your customers and your product. Trying to understand that will yield questions that some tools can answer and others can’t.

Company Wide Performance Sharing

Some companies are really tight lipped when it comes to performance and revenue. The tide is turning here because there are huge benefits to sharing this information.

One of the easiest ways of building a more data focused product culture is to share performance data.

Dropbox did this with a daily metrics email. They built an in house metrics dashboard, and then took a daily snapshot and emailed it to everyone in the company. They included investors as well.

This has a huge impact on a company because you make what you measure. If you are measuring and sharing growth numbers, everyone in the company will internalize and represent those goals in their work.

This focus on performance was pervasive at Facebook. The whole company understood for years that the goal was to get everyone in the world on Facebook.

Product Specs Run Like Experiments

After you’ve triaged your growth, my specific tactical advice is to run each task as an experiment. You don’t need a PhD — just treat it like a 4th grade science experiment. Write down what you think will happen — something measurable that you can look at after the experiment. This is often a specific metric you hope to improve.

It’s crucial to reflect back on why your hypothesis was right or wrong. Digging into this helps you learn about your product and customers and informs your future product roadmap. We’ll cover this idea more in our next post about growth.

I really like the framework that Brian Balfour has put together here. Check out his talk here about how to run this experimental progress.

Putting It All Together

This is the fourth post in a series about growth. Subscribe here to get the next post right in your inbox.

1-  Pick a Goal

2- Map your Product to your Goal

3- Triage by Cost, Benefit, and Risk

4- Aggressive Parallel Execution (hello there!)

5- Keep Score (coming soon)

We’re also putting together a class on growth which covers this whole process and more. This will launch in a few weeks, so subscribe to learn more.

A YC Company’s Public Product Roadmap

ozzie 2

Last week we wrote about how to create and triage your growth ideas. Read more about our process here. Now we want to follow up with a real example of a startup’s roadmap.

I didn’t want to use YesGraph directly here, because I wouldn’t want the underdogs at Google and Facebook to copy us. But VetPronto is different. 

I first met VetPronto’s founders through YC. We were batchmates in the W15 class. So I was delighted when Joe from VetPronto reached out saying they were up for running a growth triage and publishing it.

VetPronto lets veterinarians make house calls for your pets. Book online, and a vet comes to your house when it’s convenient for you. As a pet owner myself (that’s Ozzie in the pic above), I know this is awesome. It’s painful to schlep your pet to an office just to wait for 20 minutes just to get a single pill or shot.

VetPronto isn’t overly worried about competition because their main problem is customer awareness. When someone books for the first time, they love it and switch to using them again and again, but most pet owners don’t even know this is possible. They’d be delighted if a competitor spent VC dollars teaching the world. So now you can read all their ideas freely!

Plus, they’re going to give a discount to all the growth focused pet lovers out there. Mention “YesGraph” when you book to get $25 off. They only operate in the San Francisco Bay Area and Los Angeles for now.

We followed the same process I recommend in our post about triage. We came up with lots of ideas, categorized them, and then estimated their cost and impact. VetPronto does a lot of ground marketing, like door flyers, so they also added “trackability” as a dimension. Ideas came from walking through the user flow, their current marketing channels that work, and brainstorming new marketing ideas.

Each of these ideas was put into a spreadsheet. Here is a snapshot, click through for full resolution.

Screenshot 2015-12-17 16.45.31

VetPronto likes using Trello, so each idea had a Trello card with more details. Here are two example cards, again click through for full res.

Screenshot 2015-12-17 16.46.07 Screenshot 2015-12-17 16.45.53

Triaging your growth puts your company in a position to work things that actually move the needle.

I’ve done this kind of product roadmap planning many times now. There are different ways to get it done, but let’s review the core parts.

There is far more you could do than you have the resources to do — whether you’re 1 or 1000 people. So you must triage. Triage by potential cost, benefit, and risk. Cost means both money and your team. Benefit means what metric will move if it works. Risk is an estimate of how likely it is to work. Run experiments using science: make a hypothesis and try to prove it right or wrong.

If you’ve run a similar process, I want to hear about it. Leave a comment below or email me at

If you want to get future blog posts right to your inbox, subscribe here. Our next growth post will focus on how to organize your growth team to get as much done from your triaged list as possible.

And don’t forget to give VetPronto a try! They’ve been so generous with their transparency — Thanks to Joe and the whole VetPronto Team!

Growth Step #3: How To Triage Your Growth

So you’re trying to grow your app. You have lots of ideas. How should you triage?

We’ve written that Step #1 is picking a goal. Step #2 is building a map to understand how your product features and marketing can improve your goal. Then what do you do? This post is the next in our series about how to grow – subscribe to get all our growth posts here.


In short, come up with ideas and triage them by cost, benefit, and risk. It’s important to get the details right here so you’re running valuable experiments, so let’s dig in.

Crafting Ideas

My favorite nonfiction book is “Where Good Ideas Come From” by Steven Johnson. It’s a natural history of innovation — describing the environments where that produce good ideas. There are plenty of ideas in the book for how to generate good ideas. Here are few.

Gather information in a liquid network. This means talking to users and people at your company that understand your users and your product. What would they like to see change? You’re not going to work on everything you hear — so just gather the ideas freely.

It’s important to capture the why and not just the what. Often people jump to a specific solution of the problem when the real insight is describing the problem itself. The best way to get to the bottom of this is just asking why.

“Add Facebook for signup.”


“It would make filling out this registration form easier”


“Because you’re asking for a lot! This form is complicated.”

Study the adjacent possible. That means look to see what is possible by putting different parts of the world together. The airplane was the adjacent possible of the craftsmanship of bicycle mechanics and a light gasoline powered internal combustion engine. The simplest example of this for your app is taking an existing flow and trying to improve an element: a call to action, the copy, images, or the design. Or take an email campaign that worked for a past feature and apply it to a new feature.

Copy fearlessly but study first principles. An easy source of ideas is to copy tactics that others have tried. The problem is that what works for others might not work for you. Another problem is that you might be reading the distorted view of an outsider. A good example of bad copying is the way mobile apps bury a prompt to invite friends in a sub-menu — just like Uber does. Uber is a supply constrained marketplace and didn’t optimize the rider invite flow for ages — but dozens of apps didn’t consider that before copying them. Again try to copy the *why*. For example, Dropbox used referrals because the product quality was very high and most users came from word of mouth.

Dig into your data. Besides talking to users, there are plenty of data sources to understand what people do with your product. Sometimes you can find interesting behaviors. At Dropbox, we analyzed the file types and found that photos were popular and numerous. Talking to users showed managing photos is hard. This kind of understanding can help you immensely when you have far too many users to talk to personally.

Don’t just optimize what is there. Some of the greatest ideas are really different than what you currently do. For example, you can generate lots of ideas by walking through web user onboarding and thinking about how each step could be improved. But the best idea could be something totally outside that flow, like a mobile app that doesn’t exist yet.

Distribute across focus areas. Growth isn’t just about user acquisition. You should be concerned with retention and engagement and virality. For YesGraph, we define categories like “developer onboarding” and “ranking performance” and others. Base this on the map you’ve built to know what parts of your product impact your core goal. Making sure you’ve thought about your growth from different angles is a way to encourage lateral thinking and have better ideas.

Triage by Cost, Benefit, and Risk

You don’t need to get fancy about the tools you use here. Just use google docs or quip to make a spreadsheet full of ideas. Use a spreadsheet because you’ll be adding different dimensions, and a flat doc isn’t the best format for such side by side comparisons.

There are three categories.

Cost: how many resources will this take? This means the time your employees spend. It could also mean a dollar cost for, say, an ad campaign. People might have a category too: this might be front end heavy, that might be visual design heavy.

Benefit: if this works, what do we predict will happen? Having a hypothesis before you run a test is basic science, but very few people actually do it. Make an estimate of the impact of your work. This isn’t expected value, but conditional on success.

Risk: how likely is this to work? If you already have an analog, you can have higher confidence a test will work. If you’re working on something totally new, there is much higher risk. An example of a very high risk effort is forking off a dedicated app from your main app. An example of a very low risk effort is testing the copy on a button.

Screenshot 2015-12-11 09.13.11


Estimating the cost is probably the hardest part here because engineers are notoriously bad at figuring out how long something will take. The solution is to write enough detail about an idea so that each part is understood. Break down problems into component parts.

Spreadsheets are good for comparisons, but basic docs are better for more depth about a specific idea. So I usually have a doc full of stub specs. Eventually the stubs get their own doc for an even more product spec.

Balance Incremental With Potentially Explosive

80% of your tasks should be incremental, like running an AB test on an important form in your funnel. 20% of your time should be adding whole new, though risky experiments.

Incremental improvements matter over time. The reason is that if you’re working on the right things then the results are compounding. As we’ve said before, there is no silver bullet to solving your growth. You need to dig in and get to work.

Big risky, efforts can pay off, but being higher risk means that you are risking your company’s growth if you bet excessively on them.

The good news is often you can lower the risk by performing a small test. For example, adding a referral program has a lot of moving parts and takes some work to get right. It turns out you can validate the idea before digging into the hard parts. For example, you can literally add a single email asking users to invite others to see how your userbase would respond to a real program. Read this post for more details on referral tests.

What This All Actually Looks Like

I want to give an example of what this looks like, but a realistic view would require sharing too much of YesGraph’s internal roadmap. I love helping our community grow, but that is a bit too much transparency.

So let’s try something else. If someone wants our help in helping them walk through this process, get in touch: We can help you figure out the possible ideas and triage them. The caveat is that I’ll share your growth roadmap publicly.

We’ll see if we get any takers! What I can do is show what our internal docs look like – literally those pixelated images below.

I have one more thing I want to share here, but we’re not quite ready yet. If you want to see a more detailed breakdown of this process, subscribe to get future posts here.

Screenshot 2015-12-10 16.22.46

Screenshot 2015-12-10 16.23.59

Simulating YC

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.


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

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!

Why We’re Ditching Traditional Coding Interviews

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.


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 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.

The Valuation Boost Needed to Justify YC Will Surprise You

My startup YesGraph just went through the Y Combinator Winter 2015 batch. (YesGraph helps your app grow. Check it out). I get asked all the time by folks that haven’t been through YC whether it was worth it. Many people that don’t understand fundraising and dilution enough to even calculate this. So let’s walk through the numbers.

Most people think: ok, they take 7%, so you need to be 7% more valuable to justify the investment. Maybe if you understand fractions, you know you need to be 1/(1-7%) = 7.5% more valuable to make it up. This is completely wrong math.

To match the dilution from their investment, you need to have a far higher valuation of your next round. Let’s walk through an example.

Company A doesn’t go through YC, but eventually raises $1M on a pre-money valuation of $6M. They will end up giving up  $1M / ($1M + $6M) in dilution, or 14.2%.

Company B does go through YC. So that means 7% dilution. Then let’s say that the company raises that $1M seed. What does the valuation need to be to hit 14.2% dilution total?

7.5% higher would mean around $6.5M.

Actually it needs to be $11.7M pre to reach the same dilution. That is a 96% higher.

Here is a table to illustrate why, and here is a link to the source spreadsheet. In short, to target the same total dilution, you need to give up less in the seed round.

Screenshot 2015-04-22 11.30.08

But this math is also wrong!

This assumes only one round. If YC makes your startup more valuable for your Seed plus Series A and Series B, then you can amortize the dilution across multiple rounds.

This gives a hint about why all this math is wrong. Sure, you have multiple rounds, but what is your real goal? You want your startup to win. You want it to be a breakaway success that makes a lasting impact in the world.

If you do, you are rewarded handsomely. This is why VCs have power law returns. The breakaway successes are worth 100X those that fail.

So how do we calculate value on a long enough time horizon, like 5 or 10 years? It turns out it is binary: did you win or not?

That valuation? That is really based only on the likelihood of winning. A $6M or $12M valuation is really just saying there is a 0.6% or 1.2% chance of being worth $1 Billion.

That changes the calculus. You might ask, are we 7% more likely to win? This is only a single shot, and not some statistical exercise with expected values over thousands of trials. So you could also round the question to: are we more likely to win?

I think the answer is unambiguously yes. This is a great rubric for thinking about your company generally. Are we more likely to win with this hire? Will this new product push make us win? Will this new investor help us win?

To be clear, the wrong choices for those questions can easily be a resounding, “No!”

There are negative hires. There are investors that suck. You make wrong product decisions all the time.

But the YC advice, the cred that it gives you, and, yes, the boost in your fundraising efforts, all make it a YES.


This was actually my second time through YC. I also went through in W08, and a lot has changed since then. If you want to get the next post about what changed since, subscribe here. And if you want your company to grow faster, go signup for YesGraph.


Growth Step #2: Build a Map


This is the second post in a series about how to grow. Click here to subscribe to new posts.

The first step to driving growth is picking a goal. Then you need to understand your product to know which areas might drive growth. It’s about finding your growth levers. You should refine your understanding until you have a clear sense of how any change might affect your metrics.

Guided By Actual User Experience

To start, put yourself in the shoes of a user. What is the very first thing they experience? They might land on your home page. They might get a message from a friend about your product. They might have seen your company covered in the press. Start there, and expand.

List all the places where your product touches the user. Include every page on your site and parts of your mobile app. It is also email, push notifications, SMS, and other messaging channels. Some pages are about communicating what the product does during onboarding, others are part of the product experience.

You can go deeper by making it stateful. Where is the user in their lifecycle, and how does that flavor the experience. Often you have multiple goals for a single page, and representing those constituents is really important. While conversion on a landing page might be direct, most experiences after signup and onboarding have diverse targets. Over time, you’ll build up a better understanding of what specific actions cause a user to activate and be retained. You can then prioritize those features.

Map To Your Goals

Break down your product to understand how each part influences your goal. You can dive down to a microscopic precision here, but many people don’t even get the satellite view.

Let’s walk through an example. Your goal is more active users. That isn’t directly actionable, so what are the components? You have new signups, retained users, churned users, and resurrected users. Every single active user or previously active user belongs to one of those categories.

Now go further. Where do your signups come from? Some from direct visits to your home page, some from invites from current users. Understanding signup source is the first step to improving signups. The same is true for the other categories: how do resurrected users come back?

Back to signups, again go further. Through what channels are invites sent? What are the conversion rates by channel? What is the message? Is that email subject good enough to open the message? Is the body of the email enough to make the invitee click? Does customizing the landing page improve conversion?

Finally you have something actionable. You can run a test on the email subject and body to see how it affects clicks, and then invite conversion, and then signups, and then active users. You’ve broken down a part of your product from an abstract goal to something actionable.

Think of it like an expanding tree of detail. Here is one pass, but you want to expand on everything:

Screenshot 2015-04-17 09.36.30

Now do this for everything, not just from the goals down but from the user experience up.


Include Uncharted Territory

The main challenge with this approach is that you focus on what is already there, but there is more to the story. You need to get creative and consider uncharted territory, things which you could be doing but aren’t. In the example above, you might be running a test on your initial invite. Are you sending a reminder? Do you reflect the status to the sender, asking them ping their friend directly? Do you use email when SMS might be more appropriate for your product? A good understanding of your product’s surface area should consider what isn’t there as much as what is.

Interestingly, when designers come up with possible implementations, they often have very different approaches. Too many times, I’ve seen these designs considered, filtered to pick one, and later on the product team is not sure what else to try. You already had variants, now just use them.

Too Much To Explore

It should be obvious once you break down your product that there is far more to improve upon than you can possibly do. If you’re running out of ideas, it means that you haven’t thought deeply enough about what you have and what it could be. The challenge becomes deciding on what to work on next. That is the topic of Step 3 in this series.

Why You Should Stay Humble When Criticizing Other Products

Screenshot 2015-02-06 09.19.05

It’s easy to complain. People love it. It’s cathartic, and a small part of you probably thinks you’re helping make the world a better place.

When you have a bad product experience, there is a natural tendency to gripe about the design choices. The tone you take here is telling. Making products is really hard, but problems are often dismissed as having obvious solutions.

This came up in a recent interview we did with Samuel Hulick of You can check out the podcast below.

At UserOnboard, Samuel critiques the onboarding experiences of popular products. In our interview, Samuel insisted that he tries to avoid saying something is right or wrong.

The reason? He’s not on the inside. He doesn’t know internal conversion rates and what really affects the user experience.

For example, he was looking at an app that asked new users to invite friends before getting deep into the app. Normally, this is a bad idea. It is (for most apps) the wrong time to be social. That caveat “for most apps” turns out to be important because in this case, it was wrong. After saying it was weird, the product designers got in touch and said “We hate it too! But it really helps users get engaged and retained”.

In this case, engagement and retention was improved by adding an invite flow. Go figure

For me, I’ve seen product design internals at Facebook and Dropbox. I’d often read stories from outsiders guessing about something internal. The stories were very frequently wrong. And it only takes a few such examples before you wonder if every story you hear about is wrong, from an outsider.

This annihilates trust. So if you want to keep credibility and maybe learn something new, keep an open and humble mind when critiquing products.

Check out this and the rest of our interview below. Subscribe to get future YesGraph posts here.

Samuel Hulick Will Save You (and Your Users)

At YesGraph, we’re all about growth. We’re obsessed. We talk to so many companies about growth that we think we can help in lots of ways.

Our new growth product can help, but there is a lot more to talk about too. So we’re blogging about metrics and growth. And now we’ll start interviewing growth experts and startup founders building the future.

Introducing YesGraph Office Hours

We’re really excited to start publishing some of our interviews. This first episode dives deep into user onboarding with Samuel Hulick. He runs the amazing site – you definitely need to check out his product teardowns. We also talk about his new product, available at

Help us Launch This Podcast

We have a few episodes recorded, and need to finish up editing. We’re actually not in iTunes yet. We’ve been told that to best launch a podcast, you want a few episodes queued up. You also want friends to leave positive reviews to make your iTunes launch go as well as possible.

So if you like this episodes, subscribe to get new blog posts and episodes in your inbox.

The plan is to get the community to subscribe and review on iTunes after a few episodes are available. If you have any other tips of launching a podcast, let me know in the comments or email me (

Another way to help is to spread this post. Things you can do:

  1. Tweet about it
  2. Share with Facebook
  3. Vote up the story on Hacker News
  4. Like the story on Quibb
  5. Vote up the story on
  6. Vote up the story on

I’m new to this, and the best way to get better is to get feedback. Do I talk too fast? Too many “ums”? Should I have asked our audience for questions before the interview?

Add a comment or email me with anything and everything: