You may have noticed a label attached to companies with technical products. The label suggests developers are an important part of their ‘go-to-market.’ Their product is likely a dev tool or a solution that requires a degree of integration to be useful. That label — “developer first” — is applied so broadly that it often means different things.
In fact, that’s why we’ve used the term “developer-focused” ourselves: You can’t focus on multiple audiences at once. If that’s what you’re doing, perhaps you’re elsewhere on the developer marketing continuum.
When companies use the developer-first label, it seems to come down to a few categories and definitions of “first”:
- First marketing audience?
- First users in a company?
- First, as in most important, audience?
We’ll cover each approach with examples from real companies. Hopefully, you’ll also see the lessons you can pull from others’ experiences. And you’ll determine the areas where you can truly put developers first.
Developers as Your First Marketing Audience
Sometimes, companies prioritize developers in the early stages of a product. Using this approach, they may identify a larger market but see developers as the starting point: They’ll focus on developer communities, courting builders to use their product.
These can be exciting times for developers who find the product. Finally, a tool built for their problems! However, as these products mature, their primary audience often shifts to that “large market” they’ve been eyeing the whole time.
One example is Contentful, which sure looked like a dev tool when it first came to market. Here’s an early version of the Contentful home page.
“All your content, one API” was a promise to a developer. In fact, Contentful helped create and popularize the idea of a headless content management system (CMS). Traditionally, content was stored in the same tool that displayed it, and developers had to grapple with these systems to get their work done. A headless CMS like Contentful made it possible to decouple content storage and delivery.
You can now find all sorts of “headless” tools, which are essentially APIs that let developers interact without needing a user interface. You can customize your frontend without trudging through clunky interactions in the acronym-laden worlds of digital asset management (DAM), customer relationship management (CRM), and more.
But while modularity might appeal to developers, these tools are often primarily used by other teams. And that’s why Contentful eventually broadened its audience.
Here’s a more recent screenshot of Contentful’s home page.
Not only have they moved beyond the developers, but the first thing Contentful wants you to see is that they cater to several other audiences. Marketers, designers, and content editors all share the stage with devs. And the hero messaging — and that entire home page — is not talking to developers.
Developers were Contentful’s first marketing audience, but Contentful was only briefly developer first.
It’s a natural progression for some companies, even those with a hearty developer focus. My experience at email infrastructure company SendGrid mirrors Contentful’s evolution. We frequently discussed whether SendGrid was a developer company that started with email… or an email company that started with developers. Though developers fueled SendGrid’s early success, solving email deliverability problems for marketers was what eventually ignited the company’s growth.
Now part of Twilio, SendGrid attempts to ride the fence between developers and marketers.
SendGrid still has a great developer story and a powerful API to its deliverability platform. But when you’re paid on volume, your audience is the one who will most increase that volume. For email, that’s marketers.
Indeed, its parent company Twilio — long looked up to as a developer-focused company — has made its own transition to broader audiences. Its suite of “communication APIs” solves problems for more than just developers, even if that’s where they started.
Twilio maintains a good reputation with developers. It includes documentation and other support that devs seek. If your company wants to do right by developers as you broaden your audience, Twilio is still one to look to for inspiration. But first, make sure you aren’t actually another type of “developer first.”
Developers as Your First Users in a Company
In another interpretation, “developer first” means developers are the entry point into organizations. These companies view developers as influential adopters who can introduce their products to larger teams. They create tools that individual developers can easily integrate, then aim for organic growth within that dev’s company.
Sometimes called “bottom-up” or “land and expand,” this strategy relies on developers to champion the product. Decisionmakers tend to find budget when there’s adoption across their teams. While developers remain important, they’re seen primarily as a bridge to the broader organization.
Take the incident response tool PagerDuty as an example.
This home page message is certainly not written for a developer. It’s typically leadership, maybe not even engineering leadership, who wants to “transform” anything other than data.
Yet, this operational resilience they seek requires that developers use PagerDuty or a similar product or process. Downtime happens, but the best teams quickly learn from it and harden their systems. Yes, individual developers care. At a minimum, they don’t want to wake up and babysit servers. Tools like PagerDuty benefit from usage by an entire team, which is what puts them in this category of developer first.
The opposite approach, often called “top-down,” assumes a product decision is made by leadership and dictated to developers. This makes a lot of sense when the product’s primary user is not the developer. In fact, most API programs and SaaS tools are what I call developer-enabled companies. Sales buys the CRM, for example, and developers implement it.
Top-down tends not to work well for the tools developers use every day. They want to have input or, ideally, use the tools they know will produce the best work. In many cases, they’ll outright refuse. For example, look at this passing comment from a dev on Reddit:
My employer’s IT department is the worst about approving things, so I’m changing jobs because of it.
PagerDuty and dev tools like it still have utility with a few users. For example, you might have an engineering team of five that’s responsible for its own DevOps. They might jointly agree to use a tool together.
Many dev tools are even useful to a single developer, which makes the developer-as-first-user pattern an even more successful approach. Convincing a single developer is easier than an entire team, let alone a company with a top-down approach. However, if there’s not much reason to go beyond “single-player mode,” it’s probably best to focus on a great experience rather than forcing some viral loop.
However, the most useful dev tools will naturally expand within an organization if you have the features to solve larger problems. For example, consider how the API dev tool Postman began as a Chrome extension to easily test API calls. It handled authentication and made the JSON returned from a request pretty.
Over time, it added collections of API requests, testing to make sure the result is as you expect, and accounts to sync your data between machines. While useful for individual developers, this deeper technical work is best shared with a team — and most developers are members of teams.
In this Developer Marketing Stories episode, former Postman marketing leader Kasey Byrne shared the vision that led to the tool’s expansion beyond a solo dev Chrome extension to the platform it is today:
The idea was a platform to program a bunch of tests or even small programs. You can use it to do all of your API work rather than a quick tool to find out whether the API works the way you expected.
Eventually, the Chrome extension was discontinued, and now Postman is available as a desktop app with cloud features. Sharing collections — a useful team feature — is functionality its users expect. Every day, individual developers discover the platform and find utility in it themselves before building alongside the rest of their team.
While developers are an important audience to Postman, its focus is primarily on team collaboration. That makes developers the first, albeit not the only, Postman users in a company. In some ways, these distinctions are related to the stage of a dev tool’s company. Yet, it’s possible to keep focus on developers even when you’re one of the largest developer brands in the world.
Developers as Your Most Important Audience
The third interpretation of “developer first” is perhaps the most literal. In this approach, developers aren’t just the initial audience or a stepping stone to other markets. They’re the primary users and the enduring focus of the product.
Companies with this mindset build tools specifically for developers, prioritizing their needs above all else. This isn’t about using developers to reach a different audience — it’s about serving developers as the main audience. These companies believe that by solving developers’ problems exceptionally well, they can build a sustainable business. It’s a long-term commitment to the developer community, not just a phase or a strategy.
Two months before filing for IPO (and entering the quiet period), Twilio founder Jeff Lawson published “Your strategy’s last message to developers:”
The problem with building or buying an API as a “strategy” is that strategies change, often rapidly. They shift with new leadership, they shift with corporate priorities, they shift with the breeze. When the latest boardroom talk is about APIs, you get an API strategy. And when attention turns to the next big thing (“Drones!” “Bitcoin!” “VR!”), you get a new “strategy.”
As far as I can tell, it was his last message as CEO of a private company.
Seemingly inspired by Venmo’s API closure, the post discussed why developers don’t trust the whims of API platforms.
Too many companies treat APIs (or developers themselves) as fleeting strategies rather than core business models. Many of us have seen this play out dozens of times: APIs shut down or drastically changed. Dev time wasted. Trust eroded.
Twilio is a very different company now. As mentioned earlier, it has been forced to broaden its audience, yet developers are still a fundamental part of the business, not just a temporary tactic.
Through growth and an acquisition by one of the largest technology companies, GitHub has kept its focus on developers.
The primary message on GitHub’s home page still speaks to developers. They want to build and ship software! Yes, it hints at features that go beyond a developer’s purview (“collaboration” is more likely a leadership concern), but the home page still has code. That’s very developer-centric.
GitHub is a developer tool, but it’s come a long way from simply hosting repositories for a growing open-source version control system. Even in its earliest days, GitHub knew it needed social features to help developers communicate about the code they’re committing. Over time, it’s layered a lot on top of those code repos: issues, pull requests, code reviews, and more. “Enterprise” plans have been part of GitHub for over a decade, but they’re a way to appease devs within the enterprise instead of a clear management strategy.
In 2018, Microsoft acquired GitHub for several billion dollars. How many stories with this plotline end poorly? Most of them. And yet, GitHub continues to be strong with its developer audience.
The GitHub/Microsoft story is not the only positive MegaCorp developer company acquisition. Heroku was still a fairly young product when Salesforce bought it in 2011. And though the cloud hosting platform has experienced some bumps with its dev audience (eliminating the free tier being a big one), they’ve maintained the focus on these builders.
The platform started with its sights on Ruby on Rails. As it expanded to many other languages and frameworks, these technology choices have remained on the home page. In other words, Heroku is not just a broad cloud platform — it’s a collection of very focused entry points to its cloud platform.
That’s not to say Heroku hasn’t attempted to expand its market and audience. The solutions page, for example, shows it wants to speak across an organization.
But a few things to notice here:
- These are still primarily technical audiences.
- Developers get the prime, upper-left spot.
To follow in the steps of GitHub and Heroku, it has to make sense for your product and company. But it’s not a foregone conclusion that developers must become less important over time. You can give them the upper-left treatment. And maybe you don’t need to move on to other audiences at all. At a minimum, decide where to put developers first and then ruthlessly maintain your focus on them where it matters.
You Succeed When You Put Developers First
Even if developers aren’t your only audience, there are still ways to prioritize their needs and experiences. By focusing on key areas that matter most to developers, you can create a more engaging and supportive environment. This approach not only benefits developers but can also drive success for your product and company.
Here are five practical ways to put developers first, regardless of your overall audience strategy:
- Show what’s for them. Steer developers toward a space where you can put them first. More than half of the top dev-focused companies have devs in global navigation.
- Share your open source. Developers value open-source contributions. Even if your product itself isn’t open source, make tools and examples available on GitHub.
- Inspire with use cases. Showcase real-world developer solutions. Don’t just tell them how to build — explain why to build.
- Keep robust documentation. As with use cases, great documentation goes beyond the basics. Include all the functionality and context to help developers self-serve.
- Help with the right humans. When developers are ready for help, they’ll ask. But they don’t want to have a long sales call with someone who can’t answer their questions.
While “developer first” may seem like a simple label, its implementation can vary widely, sometimes in ways that negatively impact the developer audience. You can’t control your business strategy, which is a response to the market that needs your technical product. You may need to include other audiences. However, you can choose the places where developers are the most important audience. In those situations, you can put them first.
While your overall strategy may evolve, maintaining a genuine commitment to developers in key areas can set your company apart. By implementing the strategies we’ve discussed — from creating developer-friendly spaces on your website to providing robust documentation and support — you can build lasting relationships with the developer community.
When you need a partner for your practice, reach out to EveryDeveloper to discuss how we can help. We have worked with developer audiences for companies of all sizes, stages, and definitions of “developer first.” We can save your team valuable time as you navigate a tricky audience.