The Founder's Guide to Developer-led Growth

As an API-first company, our singular focus is helping developers build more faster, and over the years, we have learned a lot about how to serve this particular audience.

We recently compiled all of these learnings, tactics, and pitfalls into a presentation for SaaStr. If you prefer watching instead of reading, here is the full video.

Why should you build for developers?

In the past several years, a tremendous number of companies have built specifically for developers and used this as a way to get into these new markets, displace incumbents, and disrupt the competition.

This trend also doesn't seem to be slowing down. According to a Gartner survey, the number of organizations that plan to adopt APIs is growing at a rapid pace.

• 98% of organizations use/plan to use internal APIs (88% in 2019)
• 94% of organizations use/plan to use public APIs (52% in 2019)
• 90% of organizations use/plan to use partner APIs (68% in 2019)
• 80% of organizations provide/plan to provide publicly exposed APIs (46% in 2019)

Another important aspect is that developers used to influence but not authorize technology purchases. That's no longer the case.

"58% of developers indicated they have budget authority, not merely budget influence."

‍

A study from Evans Data (2018) showed that developers have buying authority and the freedom to swipe a credit card which could turn into a six-figure contract down the line.

The rise of Developer-Led Growth

You probably heard of product-led growth (PLG), where user acquisition, activation, and retention are all driven primarily by the product itself. Developer-led growth (DLG) is similar in many ways, but there are some fundamental differences in motion and strategy.

In DLG, the "try before you buy" becomes "build before you buy." You need to give developers the right tools and access to build something as simple as a `hello world` to start your relationship with them.

Pricing and billing are also different. Developers hate opaque pricing; if you have a pricing page that says "contact us," developers will just close the tab and leave. There's a fine line between value delivered up-front vs. post-paywall features, and it's crucial to offer some kind of usage-based or consumption-based model that allows for quick expansion.

Marketing to developers

Creating a brand that resonates with developers is extremely difficult. Developers are highly skeptical and obsessed with precision. Traditional marketers can easily fall into the trap of vanity-driven tactics to increase the numbers that make them look good: GitHub stars, page views, and number of badges scanned at a conference. These are all metrics that can be well-intentioned, but they’re more useful in combination with others. Individually, these metrics can be manipulated and harmful because they value breadth over depth and superficial engagement over serious interest.

Don't try to hide your real motives

A developer’s job is to build software workflows. If you're building a form, they’ll look at each field and wonder why it’s needed. They will reverse engineer your marketing funnel and avoid potential traps.

Avoid lead magnets

A popular tactic from marketers is the idea of putting whitepapers and other long-form resources behind a sign-up form. The only way to access these pieces of content is by sharing personal info.

Developers know that and will ignore all of your attempts to "convert" them. They are not going to register for your special webinar. They will use a disposable email address to download your e-book. They will do everything to avoid becoming a "qualified lead."

A helpful guide or an interactive tool will always gain more trust from developers when it's not gated.

Meet developers where they are

Some developers like reading blog posts or books. Some prefer watching screencasts or presentations. Others just want to skip the documentation and jump to the source code. Depending on the context, that same developer might want to approach a professional project differently than a personal one. Therefore, it's a good idea to explore multiple formats and let them choose what's best for them.

When it comes to distribution, you should focus your efforts on channels that are authentic to developers, such as Hacker News, Dev.to, and Stack Overflow.

In fact, any activity that doesn't translate to the expected behavior of a fellow developer will probably be seen as inauthentic and fail. For example, going to a conference and exchanging business cards is the best way to not never hear from a developer again. Instead, following them on Twitter is way more effective.

Trust on word of mouth growth

Developers are famously loyal. Once a small base of the right developers loves and evangelizes your product, you’re in a terrific position to grow.

Prove yourself as a trusted resource by having highly technical content. Demonstrate that you really know what you're doing and they will reward you with their attention.

At the end of the day, the best marketing channel strategy is having a truly great product.

Supporting developers

When it comes to communicating and supporting developers, it's important to use a tool they are already familiar with.

Today it's pretty common for companies to use Slack, Microsoft Teams, Discord, or some kind of collaboration tool. So instead of forcing developers to go through a more traditional support flow through tickets that take forever to be answered. Or, before adopting a cutting-edge AI-driven chatbot that delivers inaccurate responses and makes it harder to find the answers you're looking for, you should try to use something like Slack.

This goes back to the previous point of meeting developers where they are. Instead of adding friction, it's better to find solutions that are already embedded in their day-to-day.

Close the feedback loop

Developers give amazing feedback, so it's crucial that you not only find creative ways to capture it, but also address them as quickly as possible and communicate once their feedback has been incorporated. The worst thing that can happen is when you take time from out of your day to write a piece of feedback for someone and never hear back.

At WorkOS, we have feedback buttons located on the top bar of our Documentation and Dashboard. We try to remove all friction possible when it comes to sharing ideas or surfacing issues. If a user is authenticated, we record their email address and follow up with them after their feedback has been addressed. If a user is not authenticated, we still let them share feedback. These messages are sent to a shared channel where the entire company can see them. Visibility is an extremely important piece of this puzzle.

Final thoughts

Whether you're thinking about adding an API to your existing product or launching a new developer-first startup, we would love to chat and share everything we've learned. See you next time.