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 feel really lucky to work in VC. Working in service to entrepreneurs has been my only real job, a literal life’s work so far, and one that continues to expand and challenge me as I get older. 

I would not have this privilege without the mentors who trained me. The partners at USV and Spark Capital gave me the opportunity to be a fly on the wall as I watched them work. I shadowed these partners across pitches, board meetings, LP fundraising, and our weekly internal team meetings. From this viewpoint, I got to cherry pick the traits of these investors I admire most. It felt more like an apprenticeship than a job.

I can say “I feel grateful,” but actions are louder, so I strive to pay this education forward. Fred Wilson wrote a great post about this process back in 2010: the prior generation of VC teaching the next. I’ve played a small part in training 8 junior investment team members over the years, some of whom are wildly more successful now than I’ll ever be. I always want this to be a significant part of my job in the future. It’s a real joy to try to share what I’ve learned and watch the next generation build upon those kernels and carry them forward.

Spero Ventures is hiring for a new Analyst or Associate. We put up a job description and to apply you have to fill out this form. 

Some part of this job will be below your pay grade. I spent many late nights at USV cleaning up empty pizza boxes and folding up chairs after events. I quite literally, and happily, emptied wastebaskets, because at a small VC firm, there is never a job too small, and there’s no place to hide. Some parts of this job will be well above your pay grade. Cold emailing your idols from a reasonable VC email address tends to give you completely unjustified access to the greatest minds of our generation, and they will whiteboard with you for hours on their subject matter specialty.

VC isn’t for everyone. Rob Go wrote a good summary back in 2011 of the downsides of the job. You need to be comfortable working with little feedback in undefined directions. Self-starters and self-directed learning are essential traits. But for the right personality fit, it’s a dream job. I can’t wait to meet and help shape the next generation of investors.

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.

I recently finished reading This Is How They Tell Me The World Ends by Nicole Perlroth. I don’t typically read non-fiction. I find that great fiction is often more “real” than most non-fiction in its ability to illuminate truths about ourselves. But, I love non-fiction when it’s (A) well-researched yet concise in analysis, and (B) reveals all the sub-stories that you feel in your gut are happening, but aren’t being captured. This book shines on both fronts.

When I first learned aboutStuxnet, I was astounded at the scale of coordination among multiple countries’ security agencies. I didn’t think this level of cooperation between governments was possible while simultaneously maintaining secrecy. I voraciously tried to consume as much content about the cyberattack as I could, but I always felt like the documented information was too thin for such a coordinated effort involved seven different zero-day exploits. I wanted to read a book that went deeper. This is (in part) that book. 

But Stuxnet is just one stop on a tour of decades of escalation in scope, sophistication, and consequences of cyberattacks. Perlroth does an excellent job of giving the reader the feeling of being an insider, hanging out at the after-parties of BlackHat and DEFCON, overhearing hackers on all sides of this fight speak with each other with as much candor as a diligent reporter can get access to.

The most memorable lesson from the book is the indefensible position US security agencies took for decades regarding their knowledge of security vulnerabilities of popular software. The US naively assumed only they would be savvy enough to exploit little-known zero day vulnerabilities in things like Microsoft Window, Apple’s Safari browser, or Cisco routers, and instead of working with vendors to patch known bugs, they hoarded them for years on end for the purpose of signal intelligence. This led to many years of global tech users being openly vulnerable to security exploits directly due to US security agencies’ inaction, and it was these same exploits that were often used by international governments and ransomware mercenaries to spy on and attack whomever they chose to target, which was often US corporations and US citizen employees of those companies. The US governments attempts at security through obscurity and secrecy (always a terrible idea by contrast to security by design) backfired predictably and terribly. And it continues today.

The climax of the book is the swelling brinksmanship that the US, Russia, Iran, and China have created in infiltrating each others’ digital systems (military, civilian, corporate, and most terrifyingly, power infrastructure systems). Any given one of the hacks described in this book made modest headlines at the time they happened (often in stories broken by Perlroth herself), but the real success of the book is seeing how these hacks are connected and often in an escalating response to each other, and how the actual people soliciting or selling exploits react as they see the consequences of their actions over time. 

If you want a survey of global cyberattacks over the past 2 decades, this is your book. 5/5 stars.

Creating value in one place, capturing it in another

 

The most basic idea of business is:

  1. Make something worth buying.
  2. Sell it.
  3. Repeat.

So, I walk into Jason’s Hat Shop, find an awesome hat that fits my head, and pay Jason for the hat on my way out the door. Jason is using his hat-making skills to create value for me, capture that value from me, and then reinvest the cash to create more value, in the form of more hats. 

But many companies don’t capture value in such a straightforward way. Some time ago, I noticed that a number of companies appear to execute step (1) without executing step (2). They make something valuable, but then they give it away for free. Or so it seems.

For example, in 2013, Apple started giving away its operating system. It’s still giving away MacOS and all upgrades, while Microsoft is still charging for every version of Windows. What’s going on here? Isn’t Apple missing out on the chance to sell something that’s worth buying? 

For Apple, the value capture is happening elsewhere in the business: the hardware sales. If you try to download your free MacOS and you’re not running on shiny Apple hardware…good luck. Apple is still paying its developers for MacOS, but it’s not monetizing MacOS directly; it’s monetizing the Apple ecosystem as a whole. That’s a strategic decision. 

—-

Once you see this pattern in one place, you start seeing it in other places. Some companies appear to create value that they don’t capture directly.

When I was noodling around with this idea, I asked Twitter: 

 

As I kept thinking about this and looked at the responses, I realized that my question wasn’t that simple. There aren’t clean value-in, value-out answers. Companies have many parts, and you see all kinds of lumpiness in value creation and capture. What’s really happening is that value is being created by some parts of the company and captured in others. 

 

GitHub 

This was one of the most common answers in the Twitter thread above, and it’s a product of Microsoft. However, before becoming a Microsoft business line, GitHub was a successful, profitable, independent company for years (and profitable before it ever took its first VC dollar). GitHub creates more value than it directly captures with its public and generous freemium model: Using it has always been free if you (the customer) are willing to make your work open to the public to see. This does not compel you to publish under an open-source license, but if you’re willing to make your repo public, the product costs nothing. (Under Microsoft’s management, this free usage expanded to cover private repos with limited functionality as well.) This is kind of a double value creation: GitHub gives away usage of its service for free to support more open software development. Particularly when GitHub was a new, independent company, it was in GitHub’s best interest to do so because it solidified GitHub as the defacto standard place to host code, but it created more value than it immediately captured by offering a clean, well-lit place for all code to live and others to benefit.

However, the value capture was ingenious. As more publicly hosted code called GitHub home, it naturally became the primary web presence for developers. This is a very savvy position relative to other version-control software; the developer profile page combined with free tools generated a strong network effect. More developers wanted their code to collect attention (stars, forks, etc.) on GitHub because it increased their influence and the value of their public profile.

The value capture in post-acquisition life is even more clever. Microsoft has long wanted to own developer relationships (“Developers! Developers! Developers!”), and expanding the freemium model beyond just public usage to include limited private usage further cemented its lead as the best place to host code online. Microsoft can use this strong developer relationship to create tie-ins to other products such as VSCode—or, more important, Azure—to help it compete in the insanely ferocious cloud computing race against AWS. Azure is the fastest-growing revenue driver in Microsoft today, and any value the company can give away in other layers of its product offerings that can amplify the success of Azure is highly strategic.

 

Xerox (PARC) 

This response in the Twitter thread is a fun one, though nonobvious. Xerox employs roughly 24K people and generated $7BN in revenue in 2020, according to Wikipedia, and while that sounds like a lot of economic activity it captured for itself, the inventions it funded at the Palo Alto Research Center (PARC) were the essential inspirations and even exact inventions that generated multiple trillions in enterprise value for the likes of Apple and Microsoft. Members of PARC invented Ethernet, the modern PC graphical user interface, and the mouse. In this case, value created by Xerox at PARC was later captured by other companies.

The intended purpose of PARC was to find new products for Xerox to sell, and to discover how technology could help differentiate Xerox’s existing products. The company invented the future but couldn’t squint hard enough to see the commercial opportunity. This was not an altruistic gift of value creation; it’s a sad case of mismanagement in value capture that allowed Steve Jobs and Bill Gates to reap the rewards. 

Gates’s famous quote in conversation with Jobs on the subject is too good not to mention: “I think it’s more like we both had this rich neighbor named Xerox, and I broke into his house to steal the TV set and found out that you [Jobs] had already stolen it.”

Folks on Twitter also answered “AT&T” specifically because of the innovations at Bell Labs. AT&T was so successful at value capture at one point that it was trust-busted, so I’m not sure I agree with its inclusion on a list of companies that create more value than they directly capture, but the argument for why it should be on this list directly follows this Xerox PARC example. Bell Labs’ more famous inventions include the transistor (!), the operating system UNIX, and the programming language C.

 

Roblox 

This was one of the less popular examples cited in the Twitter thread, but I love it. All video games offer one of the highest value-to-cost ratios if you consider time spent as a key metric to entertainment value. For the price of a movie ticket, you can buy a video game that will last you >10x the play time of a 100-minute movie and often stimulate you with riveting challenges that spur interesting decision-making. I chose to feature Roblox specifically because not only does it present this incredible value to its customers, but also it has become a platform. A generation of indie game developers embrace Roblox as the place to build and distribute new games because they want access to Roblox’s audience.

A platform is a great template for a company that does a successful job of creating more value than it captures directly or immediately. A thousand flowers of other developers blossom on Roblox and help keep content fresh. That has enabled Roblox to last a decade as a gaming title, in a world where video games rarely have retail shelf life past 9 months. Roblox strategically gives away great value (access to distribute to 150 million active users on the platform) in exchange for a healthy pipeline of evergreen content that competes for relevance in its marketplace. You could argue that Roblox isn’t giving away anything free because it charges a 30% take rate, or marketplace fee, to participate, but compare this distribution access to World of Warcraft or League of Legends, which offer zero opportunity for third-party distribution; all new value creation is first-party, and no audience access is shared. 30% seems like more than a fair shake in this light and, more important, is a win-win-win: Developers get incredible distribution, players get constant new content, and Roblox gets a decade-long staying power and the privileged position of owning a marketplace that sells Robux, an in-game currency with a gross margin of 99%, to power the platform.

 

Craigslist 

This is another fun example that fits easily on this list, but for a subtle reason. The previous examples made the list because of their valiant efforts in value creation. By contrast, Craigslist is easy to include because its effort to capture value is so low. Craigslist enables so much commerce in local markets and is an incredibly flexible tool to buy and sell almost anything with shockingly quick liquidity. But it only makes money on job listings in a small subset of cities. The company’s management says that this revenue model was put in place to make the service better: charging for job listings in a subset of cities increased the quality of the job listings and reduced spam because spam couldn’t afford to pay the listing-fee tax. This incredibly low ratio of value capture to value creation is due to an almost noncommercial operation of the business. Is the world better because of its noncommercial efforts and the resulting unbundling over the past decade of Craigslist into many vertical niches? I’ll leave that one as an exercise for the reader.

Despite Craigslist’s low effort to capture value, the generosity of giving away marketplace listings was critical in scorching the earth to hinder competition, whether deliberate or not. Companies have done a good job over the past decade of competing with Craigslist on specific verticals (e.g., AirBnb vs. Craiglist’s vacation rentals or Indeed vs. Cragslist’s white-collar job listings). But companies that have tried to compete on a broad horizontal level with all of Craigslist (online classified listings competitors) have been forced into a race to the bottom on pricing due to Craigslist’s aggressive, nonexistent listing price and transaction fee from day one. Currently, Facebook Marketplace is doing the best job of competing on this broad horizontal basis, but it’s still unclear if it will actually become a material revenue line or just another piece of value FB gives away for free to capture value elsewhere in their business (Ads). Either way, Craigslist’s generosity is a moat because no company can compete with Craigslist without sacrificing profit.

This table helps summarize the various value creation and capture for these services:

 

Bottom line:

Across these examples, value creation and capture is lumpy. It’s disproportionate in some parts of businesses in one direction (often deliberately, in reaction to competition), and this lumpiness can create large pockets of value, often for free. 

The point is, many businesses don’t follow the simple process I described at the start (make something worth buying → sell it → repeat). It’s possible to get much more creative—and strategic—about how you navigate that process. Startups shouldn’t be tied to the simple and obvious model when an unexpected, uneven mode of value creation and capture might become a strategic advantage that helps them win. 

I’m inspired to partner with the next generation of companies that do this. If you aspire to build one, I’d love to talk to you about it via andrew@spero.vc.