Tag: VC

A busted term sheet is an emotional gut-punch. 

You’ve spent the last 3 months of your life getting organized around fundraising. You built a comprehensive data room. You did dozens of coffee conversations, leading to a bunch of first meetings, followed by deep due diligence with a handful of folks. You opened up your customers, exec team, and closest contacts to reference checks. You did your research and found the ideal fit VC. You negotiated (ideally multiple) termsheets. And when you signed the termsheet, you, your Board, and the team breathed a sigh of relief knowing that you’re basically done with fundraising for the next 18 months and can go back to building your business. 

And then, the deal falls through (!!)… Time starts to dilate as you rapidly think of the consequences. Am I going to run out of money? Can I go back to that other firm I almost chose instead? Do I have to start the process all over? Do I have any recourse? What will my team, customers, and investors think?

Two of the *best* performing companies I have worked with (one a decade+ ago and one within the last 4 years) both had busted Series A term sheets. I almost feel bad for the VCs that abandoned these deals… they missed out on incredible growth opportunities for ultimately myopic reasons. In general the reasons a term sheet might bust vary:

  • Sometimes a term sheet falls apart because of the macro environment. I saw a lot of companies left at the altar in the aftermath of the GFC in late ‘08 and during the pandemic in ‘20. 
  • Other times it’s an issue endemic to the company. Maybe the company just got sued by a much larger competitor or a patent troll. Maybe the company had a big quarterly financial miss. Maybe the team had infighting and fractured in the 30 days before the term sheet closed. Maybe there’s a PR disaster at the exact wrong time.
  • And, sometimes it’s an issue with the VC. That new fund they said was in the bag turned out to be less certain than they thought. Or the sponsor leading the deal lost internal support suddenly. I once saw a VC sign a term sheet, only to then leave the firm before the deal closed, which of course killed the deal.

OK, your term sheet just fell apart. What do you do next? Start with notifying your Board and any senior execs that met with the VCs. Clear, transparent, and immediate communication is essential in tough times. After that is done, well, it depends on the situation. I’ll spare you a full flowchart, however consider the following:

  • Do you have less than 5 months of runway? If so, try asking the existing investors in the business for some financial support to ensure you don’t have to accept desperate alternatives from a position of weakness. For example, a strong internal investor syndicate might support a *good* company by providing a convertible note or SAFE with the following terms:
    • An amount of capital to provide 3-6 months of additional runway.
    • Don’t try to put a price on this investment at this time because it will affect the prices of any future term sheets. A priced debt note or SAFE will act as a ceiling on near-term term sheets.
    • Instead, provide the capital on an uncapped convertible basis with time-staged conversions.
    • If the investment converts in 0-3 months, it could do so at a 0-15% discount to the next round. 
    • If the investment is outstanding longer than 3 months, investors should be compensated for this risk by either converting into the last round price or by applying a more significant discount into the next round.
    • (NOTE: Not all companies are otherwise doing well! so, not all companies merit this approach)
  • Did you receive other term sheets at the offer stage that you turned down? If so, GREAT. Go back to these investors with candor about the situation. I’d err on the side of sharing more, not less. For example, share the terms of the deal you accepted. Share the full tick-tock story of how and why the term sheet broke. The more you share, the more you will engender trust with your 2nd or 3rd choice offer and hopefully that trust will help them want to honor their prior offer.
  • Do you have outstanding venture debt? This is where your VCs’ relationship with your bankers will matter. Approach your banker with full transparency about the situation. Try to extend the interest-only period of the loan. If your debt has covenants, you might be at-risk of tripping those covenants. While that sounds scary, it’s also very common, and good banks know how to handle these situations fairly (and bad, mercenary banks will show their true colors here). They will never waive or change covenants, but they will allow you to continue to operate with a tripped covenant as long as you maintain solid communication and make progress on remediating the issue.
  • If you have no other offers and sufficient capital to continue without doing an equity round now, it might be worth simply returning to the business without your new round. The gross profit you generate in the coming months can be your non-dilutive source of capital to continue to invest in the business. Go heads down and hit a new milestone with your existing capital. Then consider restarting your fundraising process from a position of strength and reset conversations in 6-9 months.
  • Last, but most important: self care. As a founder you are the emotional engine for your business. If you’re feeling down and beat-up, it will show up in your team, sales conversations, product execution, and recruiting. Take time off if possible once the initial storm clouds start to dissipate and do the things for yourself to rechange, so you can return to the business with full enthusiasm.

That’s the general playbook. Obviously your situation will vary. I’m happy to be a sounding board to any founders dealing with this situation, assuming that Spero Ventures is not a fit for the investment round in question. Feel free to slide into my DMs.

I’m fascinated by API-First companies and the way in which they take complex, messy problems and cleanly abstract them for their customers. This type of business has been popular in the tech industry for the past 15+ years. But to me, it still feels early and underutilized. Spero Ventures is excited about backing the next generation of founders that use an API-First distribution model to tackle worthy problems in our 3 core areas of focus: Wellbeing, Sustainability, and Learning/Work/Play. 

To ensure we’re speaking the same language: I think of a company as “API-First” if the service offered is comprehensively accessible via a read-and-write API. API-First does not mean “API Only”; instead it means that the API will always be a first-class citizen and is the primary means of interaction with the service offered.

What’s so exciting about API-First companies?

Companies that prioritize API as the primary means of interaction have exciting characteristics that companies in the same market with the same job-to-be-done lack. Here are some them:

Clean encapsulation

API-First companies offer a clean encapsulation of a problem. A well-written API exposes only the objects that an end consumer needs to worry about and abstracts away the middle layer of details—the ones  programmers would need to juggle if they built the service on their own. Encapsulation helps developers by removing them from the implementation details and nuances of a complex request. Companies that choose to offer a service without an API can often suffer from leaky abstractions in which the complexity of the service offered gets exposed as the UI becomes complicated or over-designed. Designers of successful APIs pride themselves on clean encapsulation.

Emergent use cases 

Another aspect of a well-written API is reusability in different contexts, which leads to highly emergent use cases. A poorly written API has methods that are very specific and prescriptive to a single use case. By contrast, a well-written API is often described as composable: it’s written flexibly such that it’s modular (can be used well in unknown contexts that are compatible with its documented inputs and outputs) and stateless (produces consistent behavior regardless of how the API was used previously).

For example, Twilio didn’t launch a highly specific SMS API with the sole intention that it be used only for multi-factor authentication (MFA) purposes. MFA was only one of many explosive use cases that drove a lot of growth. Instead, Twilio made a highly generic SMS API that enabled a wide variety of emergent uses, such as:

  • enable mobile users to send money (venmo)
  • group chat with friends (GroupMe)
  • ping their carshare driver (Uber)
  • …and, yes, of course, sign into services via MFA.

All of these examples are actual early Twilio SMS customers. A single API led to varied, emergent use cases that were not explicit design goals at the outset. Emergent use cases are surprising and exciting, particularly to a VC who’s seeking uncapped upside when making an investment. A known, definable, boxed-in market for a product doesn’t leave enough room to wonder “What If?…” But when an API is generic enough to be a building block, a developer LEGO, it can get incorporated into all kinds of masterworks of future architecture that the original creator couldn’t imagine a priori.

Permissionless innovation

A characteristic of the internet that made it so unique compared to all other media before it is permissionless innovation. You don’t need an FCC license for radio spectrum or land-use rights to lay telegraph wire to broadcast your message. You can self-host anything you want to make, point to it with an IP address, and be instantly accessible to half the globe. Being accessible doesn’t guarantee an audience will show up, but the network is open for your usage without a gatekeeper deeming your idea worthy before you build your thing. 

Well-constructed API-First companies rhyme with their internet origins in this way. Flickr is not an API-First company, but it’s an iconic example of the start of the API-fueled Web 2.0 mashup culture, and its API was an exciting part of that beginning. Caterina Fake (co-founder of Flickr) wrote in 2006 about Biz Dev 2.0. (The original post is lost to digital rot, but Archive.org to the rescue) From Caterina:

Fred [Wilson] contacted me about a small startup that wanted an introduction, but I said we (that is, Flickr) probably didn’t have the space on our schedules to engage with them in any meaningful way, but that they should feel free to apply for a Commercial API key and build something off the API. “BizDev 2.0” I call it. Nifty concept, sez Fred.

This is a key moment in internet history to me. It morphed the spirit of permissionless innovation that the web fostered into scalable business strategy. Don’t do a heavy-handed, top-down sale to a new customer for your service before you know if the customer is viable. Instead, offer an API-as-a-service with a simple enough sign-up flow that developers can help themselves, and then, once you see what gets built by potential customers bottoms-up, you can identify high-quality customers to target for deeper relationships.

Time-to-value & pace of innovation

Permissionless innovation often implies self-serve access to API keys, so developers tend to initially adopt API-first companies’ services without talking to anyone first, internally or externally. This leads to the next positive characteristic: API-First services often deliver faster time-to-value (TTV) for customers. There’s no need to deal with prolonged contract negotiations or a technical audit before experimenting with an API. Just grab the API and the docs, open a console, and build a proof of concept quickly to see if the API fits as a solution to the developer’s job-to-be-done. When Stripe launched, it was famous for having a dozen lines of code on its homepage that when copy/pasted into a console would trigger your first payment transaction. Compared to prior payment processor solutions developer experience (the best of this lowly lot was Authorize.net), this is an insanely fast time-to-value.

The speed benefit isn’t limited to just customers. Every enterprise software company has a layer of abstraction between its frontend and backend services. API-First companies benefit from faster pace of innovation because offering a developer an API saves time in frontend development and design. 

I don’t mean to be light about the difficulty of building a great API. New problems emerge instead, such as building in more robust error handling or rate-limiting, writing clear documentation with strong code examples, writing wrapper libraries for different languages and frameworks, cultivating a good community on github and stackoverflow (these are some of the niceties of a new, fast-growing discipline: Developer Experience (DX)). That said, API-First companies often have a culture of shipping often, and they prioritize engineering culture in a way that their more traditional enterprise non-API comparables lack, and this leads to a better pace of innovation. 

Grassroots adoption

Traditional enterprise software is often sold into companies top-down from the CIO/CTO/VP Eng for technical service offerings. Almost no one (except maybe Compliance/Legal) benefits from this top-down approach. Executives buying technical solutions aren’t close enough to the implementation details of the service needed to know if the product is a good enough fit to the job-to-be-done. Startups that are trying to convince enterprise executives to buy their software strictly top-down often struggle with credibility and need to partner with expensive valued-added-resellers or consultants. By contrast, the bottom-up adoption enabled by self-serve API-First companies makes everyone’s life easier. Developers can try solutions without waiting for a lengthy procurement. Enterprise executives can confidently expand the purchase of software they already know is providing value. API-First startups can focus their top-down sales efforts primarily on customers that are incredibly warm leads because they can see the organic usage of their sales prospects before the first call. This leads to the most common go-to-market strategy for API-First, a motion that starts on the ground where the development actually happens. That grassroots origin allows a thousand seedlings to sprout with a self-serve API key, and then a top-down sales approach can grow high-quality prospects into the next generation of oak trees.

Building around developers’ needs

API-First companies play into a ceaselessly growing macro-trend: the rise of developers. More people than ever hold the job title of “developer” of some sort today, and that number will continue to grow. We laugh at Steve Ballmer’s “Developers, Developers, Developers!” manic chant in hindsight, but Microsoft’s obsession with developers across 3 decades is why it’s one of the most valuable, enduring companies in the world. By building your software company in an API-First way, you hang a neon blinking sign on your homepage that announces you prioritize developers and their experience. More jobs than ever before are becoming some form of information work that can be automated by code, and building a company through this lens will help ensure that you’re on the right side of this trend.

While all of these characteristics above are great reasons why API-First companies are exciting, my favorite reason is all of the compounding growth loops that occur in well-built API-First companies. This next section will walk you through these compounding growth loops, loop by loop.

Compounding Growth Loops for API-First Companies

A common API-First company’s North Star metric is developer adoption, and the number of developers in an API-ecosystem tends to compound naturally in four growth loops that reinforce each other.

 

1. The Developer Experience (DX) Loop: Developers who explore (and eventually thrive) with the API will build compounding resources online that are key to great DX. Years of developers using the API leads to questions and answers on StackOverflow or pull requests and wrapper libraries contributed openly on GitHub. A groundswell of organic activity emerges around a successful API where developers help each other get through issues they encountered in the past together because developers are more altruistic than typical enterprise purchasers. This organic pool of resources and support gets indexed by Google’s crawler. The next generation of developers that are looking to solve a relevant problem will discover the API via Google. This brings us back to the start of the loop and increases developer adoption of the API.

2. The Consumption-to-Paid-Acquisition Growth Loop: The most direct business model to make money from an API is to charge for its usage. This consumption-based business model means that an API’s cash flow grows as: (A) more developers integrate the API into more apps, and (B) as the developers’ apps grow, their API consumption grows. 

First, developers integrate the API into more new apps. Each new app built will grow in usage over time, which leads to more API consumption. So, each individual app increases its spend with the API over time. As the API accumulates more cash flow, the business has more cash available for marketing to acquire the next cohort of developers. This leads to more developer adoption and the loop is complete. 

Related to this loop is the concept of net-negative churn: A given cohort of API customers will be larger one year later, as long as the usage of the customers who churn during the year does not exceed the natural expansion of the remaining customers’ usage. API-First companies with net-negative churn compound in growth even if they fail to add new cohorts of customers (a magical characteristic unique to subscription-based business models). Not all API-First companies will have net-negative churn, but the best ones all do.

3. The “Keeping Up with the Joneses” Growth Loop: As the API gets integrated by developers into new products, the API is being integrated for a reason that is likely aligned with the app’s end-customers’ goals. Stated more directly: the API makes apps better. A company might use an API to add a new feature (like SMS-based interaction (Twilio) or a better checkout payment flow (Stripe)) that makes its product more compelling and competitive. That company’s competitors will eventually notice the change and (probably) follow suit. So, for the best APIs, integration by one competitor will lead to a Red Queen Race. One product thriving thanks to an API causes competitors to adopt that same API, which closes the loop and adds more developers into the API’s compounding loops.

4. Data Exhaust Growth Loop: Last, many APIs get better as they get used more, thanks to a data feedback loop. As more developers integrate the API into their apps, the data and metadata that gets generated by usage of the API helps guide future improvements to the API. For example, when ecommerce merchants accept credit cards, they’re liable for chargebacks and susceptible to fraudulent chargeback claims. It’s very frustrating for merchants who have to provide evidence to contest chargeback fraud, and often it is easier to simply write off the fraud as a loss than to fight back. As Stripe’s API grew more popular, they saw more data and metadata about chargebacks. This is the data exhaust from the usage of the API. Stripe then developed machine learning algorithms to reduce chargeback fraud and improve the Stripe API for future users. (Not every API will have a compelling data exhaust growth loop. For example, if an API generates stock quotes, that usage isn’t adding data that will affect the stock quotes in the future. But this loop does exist for many APIs).

These four loops combine and reinforce each other. So, let’s look at the full picture as a whole now that we have decomposed it into its 4 component parts.

This compounding advantage becomes an enduring moat over time, which is why Stripe and Twilio are so highly successful despite pixel-for-pixel copycat clones of both services launching repeatedly over the past decade.

These characteristics are (mostly) universally true for API-First companies and are significant advantages over non-API competitors that don’t focus on API-First distribution and developer experience. That said, not all API-First companies are created equal. Some will have stronger growth loops than others based on execution choices and general quality. 

From here, I want to explore some side-avenue characteristics of API-First companies that are less universally true, but, to me, even more interesting.

——-

Two archetypes of API-First services: Boxes and Platforms

API-First companies are exciting for the reasons I’ve discussed, but API-First companies can come in a variety of shapes, which can be exciting for their own reasons. Here I’ll explore two which differ materially: Boxes and Platforms. 

See this visualization first, and we’ll walk through a decomposition below.

Some API-First companies are Boxes (see left side of visualization above). They take messy, complex problems (like trying to get your application to communicate with the telephony and mobile SMS networks, in Twilio’s case) and then cleanly encapsulate it in a composable box (remember “composable” from our earlier vocab lesson?). Before Twilio existed, adding voice and SMS functionality to an app was a combination of agreements with various carriers, VoIP backhaul, Asterix servers, messy spaghetti code in multiple ‘70s era programming languages to communicate with carriers’ legacy systems, and network topography issues. After Twilio, it’s as simple as a couple API calls. Boxes are the truest representation of the titular LEGOs (or building blocks) of this post. Boxes tend to have obvious business models. They often sell a metered API, and developers pay in proportion to their usage. There are usually three parties in this equation: the vendors that the API encapsulates (for Twilio, the carrier networks), the first-party API (Twilio), and the developers that implement the API.

API-First companies can also be shaped like Platforms (see right side of visualization above). These differ from Boxes in that there is often a new party involved, a consumer of the Platform that isn’t the developer. Some obvious examples that fit this shape: Microsoft Windows, Salesforce/Force.com, and the iPhone. While these examples don’t look like API-First companies upon first blush, it would be an oversight to omit them from this framework because developer adoption is absolutely essential to their success, and without these developers they would quickly unravel (like RIM/Blackberry did). The Platform develops excellent, best-in-class APIs to allow developers access to the large audience the Platform has aggregated. Why is the audience there? Because they loved the experience that the prior cycle of developers built on top of the Platform, which made the Platform more attractive than alternatives. 

Platforms must overcome a cold start problem in order to grow. In the Platform genesis state, no apps exist yet, so the 1st party Platform owner will build the first couple apps, which are seen as inspirational reference designs for how great apps on the platform should work. The appeal of the 1st party reference apps helps recruit the first generation of users to the platform. (For example, Apple didn’t open up the iPhone to third-party developers until a year after the initial iPhone launch; in the beginning all apps were 1st party, and developer interest in building on the platform was at such a frenzy that they built jailbreak solutions and hacky, browser-based libraries to develop their own apps.) Once a platform has a healthy userbase, 3rd-party developers arrive and build 3rd-party apps using the Platform API in order to access the platform’s userbase. If these new apps are great, they’ll recruit even more new users that buy the platform and the userbase expands, which creates a reinforcing loop that recruits the next generation of developers to build more apps.

Platforms easily merit their own thesis document, and I don’t want to pull this article (deeper) into a digression. But it’s important to talk about Platforms in the context of API-First companies because (A) they recruit developers aggressively to develop for their Platform, (B) often Boxes aspire to become Platforms in the longer time horizon of their vision, and (C) Platforms’ developer recruitment efforts illuminate the reasons why a developer would choose to adopt a new API. I’ll explore developer motivations in the next section.

Developer Motivations to Adopt a New API

Regarding Developer motivations, why do developers choose a specific API? At the simplest level, it’s because it fulfills a developer’s job-to-be-done. While some of these jobs are niche or industry specific, many can be genericized into this framework. 

Developers want:

  • New functionality that’s hard to implement directly. This is the primary use case of an API like Nylas. Integrating customers’ calendars and emails is difficult to do directly if you want to cover all possible options like Microsoft O365, Exchange, Gmail, IMAP, etc… If you want to be able to access this type of data for your customer in both read and write functionality, it’s easier to just implement Nylas. APIs unlock new functionality that you can buy instead of building and maintaining it yourself.
  • Access to customers. Most relevant to Platforms, developers flock to APIs that will yield them new customers. Imagine a company that helps you with email deliverability. The functionality alone is good, but if it implements the Salesforce API and is discoverable in the Force.com ecosystem, then it’s suddenly instantly useful and discoverable to all the Salesforce users who care about communicating with their clients via email. If it’s a really great app, Salesforce might even actively promote it or co-sale your product because the developer implemented its API.
  • Access to a data asset. Data APIs are a straightforward use case. A developer wants to enable functionality in their app that requires data they don’t have. An API-First company can offer access to this data in a couple different business models: metered (pay-as-you-go) usage, freemium (pay once you hit a free usage cap), or premium access (pay a monthly fixed rate to access the data).
  • Money. Not all API-First companies are built on metered usage. Some APIs come with their business model baked-in, and therefore can pay developers to adopt it. Fred Wilson wrote a great example of this in regards to Indeed, a search engine for jobs, back in 2009:

In the case of Indeed, they initially offered online publishers the ability to pay for a real time search API of online jobs. Not many took them up on that offer. But when they injected their sponsored jobs into the API and offered to share the revenue with publishers, the demand was huge.

This clever move won’t apply to all APIs, but if advertising is a viable business model for an API-First company, then Indeed’s strategy may well work. Embedding the advertising into the API output gets additional impressions for the ads, and then you can give developers a share of the revenue they help generate. Getting paid to use an API you find useful for other reasons as well is a win-win. However, as a corollary to this Money example, I can recall a time when 2nd tier platforms (like Microsoft’s attempt to make a smartphone) would pay developers to use their API because the additional apps were strategic to the platform. When Apple was advertising “There an app for that” Microsoft needed an answer, and tried to buy their way to developer adoption. They failed because the Windows Phone platform wasn’t good enough, so despite paying developers to adopt their API, the platform floundered. Money will always motivate developers, but that can’t be the only form of value; the API or Platform still needs to be useful to the developer.

  • Access to a network. Arguably this is a subset of the “access to a data asset” case, as a network can be represented as data about relationships between nodes and edges, but it’s an important enough use case to call out on its own. Developers want their app to be maximally useful for their users. The more “networked” their app is, the better. For example, for every SaaS B2B board I have sat on, nearly always the first app that the company builds once their API is complete is a connection to the Zapier API network. By implementing with Zapier, developers’ apps will have basic interconnectivity with thousands of other applications immediately. Granted, their customers will have to pay for access to Zapier to enable these integrations, but some of their customers might already be Zapier customers, and some new customers might discover them via the Zapier ecosystem. So, accessing a network can motivate a developer to implement an API for varied reasons.
  • Better developer experience compared to competitors. All the above characteristics don’t suppose that two API offerings are in competition with each other. As the API-First ecosystem deepens, various categories have multiple competitors. For example, when considering how to integrate SMS functionality into an app, a developer might choose Plivo instead of Twilio. Price is rarely the most important factor in this decision, and competition creates cost parity anyway. A huge motivating factor is developer experience. Which API has the best documentation? More developer adoption? More StackOverflow and GitHub engagement? Developer experience is an essential motivating force, especially when an API implementation is often a choice that a developer will have to live with for a long time.

The best of API-First companies understand these developer motivations and use them to drive growth.

Spero Ventures and Why We Care about API-First Companies

At Spero Ventures we invest in founders building the things that make life worth living. We’ve decomposed this high-level mission thematically in 3 core areas of focus: Wellbeing, Sustainability, and Learning/Work/Play. API-First companies fit our investment thesis both horizontally and vertically. Horizontally, API-First is a distribution strategy that can apply in any of our 3 focus areas. For example, an API-First company in the sustainability area of focus that helps developers integrate carbon usage data into their apps to help make their customers more aware of their carbon footprint. Vertically, API-First falls under Learning/Work/Play as a category of technology enablement that’s changing how work is done. As more of today’s jobs become some flavor of information worker or developer, API-First companies are on the right side of history, aligned with how work will evolve. I’ve served on the boards of three API-First companies (Nylas, Particle, and Quantopian) and helped source other investments focused on developers, such as StackOverflow. If you’re building an API-First company and want to chat, email me: andrew at Spero dot vc

Feedback from the entire portfolio of Spero Ventures is unanimous on one front: hiring great talent is more competitive today than it has ever been. This is a refrain I’ve heard annually for roughly a decade (2012 – 2022) in tech. Candidates for tech jobs have more options with more employers, and this competition for talent has led to higher offers and more flexibility. This is not surprising as software companies have increasingly permeated every industry and turned a broad number of historically different jobs into various versions of information processing.

Against this backdrop it’s worth exploring what can an employer do to try to be more competitive in the war for talent. There are some obvious answers to start with: 

  1. You can pay more for talent. My own opinion on compensation philosophy is employers should do research (procure a product like Carta Total Comp) to determine what is the competitive compensation for all roles (filled and unfilled) at their companies and strive to pay a market-to-above-market rate compared to companies of similar size (by # of employees, funding, or revenue). You cannot buy employees’ love; attempting to do so is the path to a mercenary company culture. But, attempting to pay below market compensation to save capital is increasingly futile. Paying market-rate compensation is a simple best practice and is table stakes in recruiting (necessary, but not sufficient), and it’s also an essential step towards establishing equal pay for equal work. In fast-moving startups market-rate compensation doesn’t always happen (mostly due to inattention), so it’s worth mentioning upfront. 
  2. Build your recruiting muscles in-house sooner. These muscles are a combination of human capital and software. A Head of Talent is a role I’m seeing more startups hire for sooner in their company life, and I’m supportive of that trend. Good recruiters will increase the top of the funnel in your efforts to source new talent, and, when done well, can help your company make a strong first impression on a candidate that might be passively considering new roles. But, recruiting is a high volume job inside of companies, and needs to be augmented with a software exoskeleton to scale outbound efforts beyond what an individual recruiter can do alone. Which leads me to:
  3. Prioritize best-in-class candidate experience. 

What is candidate experience? It’s every touch point that a job candidate has with a prospective employer, and while it’s a small portion of what a company does, it’s 100% of the company that a candidate sees and uses to make the very important decision of their next career move. From the very first outreach email through to the final offer letter, a candidate is evaluating a potential employer the same way that an employer is evaluating a candidate. It’s a two-way street, and savvy employers understand that making all their touch points with the candidate delightful is a highly-leveraged way to get more candidates excited about their roles and more accepted offers.

This is why I’m excited to announce our most recent investment at Spero Ventures: Guide. Guide is on a mission to improve the candidate experience in job searches and help employers win more candidates. Guide creates beautifully designed software that helps walk a candidate through every step of the hiring process with their customer, the employer. 

Common pitfalls that mire the candidate experience for most employers today include: failing to help candidates understand who they are interviewing with and when, failing to communicate what are all the stages of the interview process upfront and setting poor timeline expectations, not communicating where a candidate is in the process at any given time, and relying on a generic Careers page to sell the company culture instead of describing the exact team that the candidate would be joining. Any recruiting process is fallible and will naturally hit rough spots. Guide helps recruiting teams understand where their process has friction by soliciting timely feedback from candidates to help recruiting orgs iterate and make their processes tighter and more enjoyable. Guide helps companies create delight at every part of their recruiting process, so all parts of a candidate’s Guide are customizable to match corporate branding and create a unified feel.

Guide sits at a very interesting strategic position in the recruiting flow. There is a robust market for products that organize the employer’s view of the recruiting process. This is the Applicant Tracking Systems (ATS) market, of which companies like Lever and Greenhouse have generated good attention and customers in the market for fast-growing startups. Everything that happens in the ATS is about the job applicant: where they are in the process, who will they meet next, what needs to be sent to them and properly communicated, etc… but job candidates have never before had a view into the ATS besides the phone calls and emails that recruiters dribble out. Guide is the lens into the ATS that candidates can view from their prospective to answer their questions and help them prepare for the interview process in a clean, well-organized way.

I am delighted to be partnering with Troy Sultan and Austin Cooley, Guide’s Co-Founders. This is the second product that Troy, Austin, and their team have built specifically focused on software for recruiters. Their first product Resource.io was sold to Gem, and helped recruiters organize their outbound efforts at the top of the recruiting funnel. Guide is a perfect complement to the success of Resource/Gem’s approach: now that it’s easier than ever to reach candidates outbound, companies need Guide to make the best possible impression at every step of the funnel in recruiting candidates in order to stand out in the noise of recruiter communications. The challenge is no longer reaching candidates; it’s winning them.

I’m delighted to join Guide’s Board of Directors, and Spero is co-leading this financing with Meka Asonye at First Round. You can read more about the financing on Techcrunch. I love the mission of improving candidate experience so more candidates get more transparency in the recruiting process and end up in the right roles for them. Guide’s current customers love them because Guide candidates strongly prefer companies that drive their candidate experience process with Guide, and happier, more informed candidates lead to more wins.