Developer-led Sales for Startups

Hey folks, my name is Matt Makai. I serve the Developer Network at Twilio. I'm also part of the Extended Team at Ubiquity Ventures.

I often meet startup founders who ask me "how can my company do what Twilio does with developers?"

I respond by asking, "what do see Twilio doing and want to replicate for developers who interact with your business?"

That's when they usually tell me about their "the dev-led sales dream".

Their dream is that software developers go to tech events, like hackathons, conferences and meetups. While at an event, developers see a new API or technical product that looks interesting.

Immediately those developers implement the API in their own projects.

Boom, success!

You make more money as the company that the developer works for uses increasing amounts of your product. Take that money, reinvest in the business to grow and improve your product.

Rinse and repeat until the IPO and beyond.

There are examples of this developer-led marketing and sales success story across many early-stage and mid-stage companies. For example, Rollbar and Datadog are doing well by focusing on developer adoption with great technical content for their monitoring and analytics tools.

Postman recently raised $50 million in a Series B round of venture capital to expand their API testing developer tools. Postman was founded in large part because the original tool was virally adopted by developers building APIs and microservices.

DigitalOcean's extensive community-written tutorials have endeared them to developers and has allowed them to compete in a world where providing cloud infrastructure pits you against AWS, Google and Microsoft.

Citus Data's developer-focused database content and PostgreSQL offerings led them to a successful exit via Microsofta acquisition.

Then you have the massive success stories of developer-focused companies, such as publicly-traded Okta Pluralsight, Slack and Twilio. Still-private Stripe recently raised more venture capital money at a $22 billion valuation which is more than those four public companies.

Amazon Web Services (AWS), while not independent of its mega cap parent company, arguably is by far the leader in cloud computing infrastructure due to its initial and continuing focus on grassroots developer product adoption.

But how does that startup dream match the reality of the work and skills required to execute on the vision?

You, as the founder, should serve as the chief evangelist for your product during the early stages of your company. That role never stops regardless of how large and successful you become.

But your time is split in a hundred different ways so eventually you need to hire someone with a nuanced understanding of how to appropriately market your company to developers. Hiring the wrong person for the job is going to be the equivalent of adding a net negative producing programmer to your development team at a critical stage of growth. A poor result could sink your entire company.

The right person for the job likely has a combination of significant heads-down software development experience, humility, patience, strong writing and solid speaking abilities.

That combination of skills is exceedingly rare, which according to supply and demand dictates a large compensation premium over a programmy-only skill set. If you've done any recruiting for top notch developer relations folks, you may have already discovered this issue which is prohibitive for startup companies trying to compete with better-capitalized firms.

We've done a bunch of talking already about the developer-led sales dream for startups, but what exactly is developer-led sales?

Developer-led sales mean that developers are your primary customers. The goal is to have developers see the value in your product, sign up, start using it and spend some amount of money that is relevant to your business. This approach typically works best with a usage-based model where development is cheap or free then costs scale with the consumption of your product.

For example, Twilio's SMS API is free to get started with during development. Then for testing and production text messages can be sent and received for .00075 US dollars each. A developer can sign up with their credit card to test that your product actually does what you say it can do, then scale up as their application goes to production.

Developer-led sales stands in contrast to the typical business model where a business development representative (often shortened to "BDR") prospects for potential customers, outbound emails and calls those prospects, then hands off to a more senior sales representative to work on closing a deal that is large enough to justify the time invested in the sales cycle.

In this traditional model, your startup sells directly to stakeholders who control a relatively large budget and are authorized to spend that money. Developers usually do not have significant budget to spend but can often spend a small amount on a credit card and expense it without an issue. That's why dev-led sales is possible as an alternative sales model.

We should also confirm what developer-led sales is not. It's not sales engineering, where your technical folks support a traditional top-down large sales deal.

Developer-led sales is also not developer-only sales. Other stakeholders remain important. When your product is successfully implemented then you still have to ensure non-developer stakeholders are part of your sales process.

Here's another way to think about a developer-led approach to product adoption and sales.

Before your product exists, no developers anywhere are using and paying for what you are offering, as represented by this dark world map.

A few risk-taking developers who have a problem you are solving "raise their hands" with code by using your product or service once you launch.

When you are successful, more and more developers use your products and serve as indicators that your product is solving a real problem. Those developers can be your first hook into larger deals with organizations where those developers work.

When should you consider a developer-led sales strategy instead of a tried-and-true traditional sales motion?

First, you need to be solving an actual problem that developers recognize is an issue for them that they themselves would not want to solve. Solving a meaty technical problem with an easy-to-use solution is a high bar that non-technical founders often take for granted when pitching their product.

Is the problem your product solves... actually a problem worth solving for developers? It must be if you want to be successful with a developer-led sales model.

Second, you need to be able to properly articulate the problem that you solve to developers. That is an unexpectedly large challenge if no one on the founding team of your tech startup is a developer themselves.

That link contains the slides and a loose transcript to another talk that provides some guidance around telling your product's story to developers.

Third, even at an early stage you should have some understanding of your own business model. The business model should include a working hypothesis for both the cost of customer acquisition (CAC) and lifetime value of a customer (LTV). Also, does the revenue derived from your customers match a standard distribution or a power law distribution?

What do CAC, LTV and standard vs. power law distribution have to do with a developer-led sales motion?

Ideally, your CAC will be significantly lower with a developer-led sales strategy versus a traditional sales motion. This is one reason established companies such as Okta acquire smaller firms such as Stormpath to create a different sales cycle based on usage from developers instead of trying to convince companies to sign large deals before the software has proven useful.

Note that I am making a lot of assumptions about your understanding of developer platforms. If what I am saying about CAC, LTV, usage-based models and related terms are unclear, you definitely need to read Bessemer's articles on 10 Laws of Cloud Computing and 8 Laws for Developer Platforms.

They are both incredibly helpful foundational resources for understanding how to build, market and sell software products for developers.

Finally, if you have a product that solves a real problem for developers, can explain it to them and have a working model of your CAC and LTV, then a massive bonus comes into play when you have a broad platform useful across many industries. Broad platforms that developers can use in creative ways can potentially create new use cases for company to sell.

For example, when Twilio started the SMS API, 2-factor authentication was rare. The ease of integrating the API to send unique codes to pre-qualified phone numbers to enhance security beyond a password became a new use case for the company to sell to customers. Developers came up with the use case and deserve the credit for figuring out what was valuable about an SMS API.

Most startup founders I talk to go straight into questions about the tactics that Twilio and other companies use for selling to developers. It's a bit of a "the cart before the horse" situation because you really need to have figured out what we talked about in the previous section as it applies to your business before you dig into the specific tactics you will use to engage developers.

Let's assume you have determined a developer-led sales motion fits well with your company strategy. Now we can dig into the myriad tactics you can apply to grow your sales funnel.

Most of these tactics are better described as "developer marketing" rather than sales. You are not going to be cold calling developers to pitch them your service. Please make sure you never do that.

Let's dig into several of the specific tactics that can work well to jump start developers adopting your product when it solves a problem that they have.

We'll start with a few online tactics then review in-person "offline" event-related activities like startup founders' dream hackathons.

By far your most important marketing asset is having stellar developer documentation. However, documentation rarely comes up in conversations as part of marketing and sales efforts. Why is that?

Historically, documentation has been a by-product of an actual product or service being offered. Docs are considered a necessary evil and cost center that needs to be minimized as a time suck for engineers to work on "real" problems. Sometimes writers with minimal or no development experience are hired to just get it done.

The "necessary evil" attitude makes sense in a world where documentation lives in a large paper binder that is mailed out after a purchase is complete. The quality has to be just enough that the customer doesn't complain about the complexity being so high their developers cannot eventually (after some long unpaid additional work nights and weekends) complete an implementation.

Documentation is your evergreen always-to-date content, but there are additional formats such as blog post walkthroughs, example use cases and brand awareness tutorials related to hot topics that developers are currently interested in learning.

Alright, I am going to start talking about online social with the caveat that I personally think it's difficult if not impossible to pull off as a decent developer adoption tactic. It's usually done so poorly that it is better to not do social channels like Twitter, Facebook and your own Slack instance at all.

Video tutorials that teach how to use your product which you can post on YouTube and other sites are more difficult to create than straight text and code, but they can be well worth the effort. YouTube is currently the second largest search engine in the world (amazing how both number 1 and number 2 are the same company) and the video search results are also cross-posted in Google standard search.

The wide reach presents a strong acquisition model if you can create useful technical content.

Live coding on Twitch and YouTube are a nascent but promising teaching method.

Evergreen documentation, timely technical content, online social, asynchronous videos and streaming are the most common online developer adoption tactics. Next we'll look at some offline, in-person tactics.

Conferences split into a couple of categories: community-run and vendor-run. For example, WWDC is Apple's vendor-run developer conference. They run the show and control the messaging. PyCon US is the community-run Python developer conference. There are a ton of vendors there as sponsors but no one company controls what happens at the conference.

Conferences, especially community-run ones, work well for brand awareness. Vendor-run conferences can work well for brand awareness if your product augments an existing company's products and solves a problem for the developers who attend that event.

Non-developer conferences are great for sales lead generation. Think of badge scanning and prize raffles in exchange for hearing a product pitch. However, badge scanning and lead generation activities do not work very well because most developers are skeptical and just want to avoid overly pushy situations. Be considerate of your audience and respectful.

Generally, I find you can spend a ton of money on conference sponsorships without getting a ton of value out of them. If you want to be successful with this tactic you should figure out your secret developer marketing sauce on smaller, regional conferences then expand from there.

Tech meetups are good for brand awareness among primarily less experienced developers. While there are some niche, senior developer and tech lead-focused meetups, most of the content at these events is aimed at less experienced folks.

Professional hackathons have undergone a transition over the past several years. Broadly speaking there is less excitement among developers to spend a long sleep-deprived weekend working on a project with an unclear payoff. I could be projecting my own feelings on this one but it appears that the majority of developers in 2019 would prefer to work on their projects outside the pressure of an arbitrary forced deadline. Hackathons can be still useful for getting a focused product shipped in a weekend but there seems to be less excitement around them than a few years ago.

College hacakthons, like Hack MIT, MHacks and Hoo Hacks, on the other hand, are going stronger than ever. There are always new classes of students who are excited to code their ideas. However, you are playing the long game with college hackathons and assuming that a few years down the road a student who learned your APIs will pick it back up to solve a problem at work. For most early startups, college hackathons won't make a ton of sense unless you want to get quick immediate feedback from junior programmers about your product's developer experience.

That covers the most common online and offline developer marketing and sales tactics. Is that it?

No, there are many other tactics. However, the ones we just listed are the most likely to be successful based on the relatively small investment you can make as a startup.

There are an additional set of tactics that are essentially "magic" to you because they rely on an existing successful foundation to properly execute. Building a new foundation of developer awareness is dramatically different from expanding developer adoption among those are not early adoptors as well as doing a better job of serving developers who already use your service.

Let's wrap with a quick review of the important concepts presented in this talk.

There is a startup dream of developer-led sales which is an easy path from launching your service to developers, having them find out and start to use it, then becoming large paying customers.

The reality is clearly more difficult than the dream. You as the startup founder need to be the "chief developer evangelism officer" and it will be expensive when you aim to hire a seasoned developer relations employee.

We define developer-led sales as a different sales motion than a traditional sales outreach approach. Instead, you appropriately market to developers who need a solution to a problem they are facing, typically with great documentation, timely tutorials or another respectful tactic rather than cold calling or empty clickbait content.

That's all the prepared materials for today. Thank you very much. Again, my name is Matt Makai, I am a software developer at Twilio on the Developer Network and the creator of Full Stack Python (source code).