What product marketers need to know about engaging developer audiences

A little over a decade ago, I started to research developers because I realized traditional marketing strategies weren’t resonating with this particular audience and I wanted to understand how to best and most effectively communicate with them.

In this article, I’ll share:

Why product marketing for developers requires a completely different approach
What makes developers unique
Product marketing from a developer perspective
Go-to-market strategy

My name is Danni Scott-Duke and I'm delighted to share with you the futurist developer, what product marketers need to know about engaging developer audiences.

My background

I have a solid background in software and technical marketing with time spent as a product marketing manager. A little over a decade ago, I started to research developers because I wanted to understand how to best and most effectively communicate with them.

Because it was clear that our traditional strategies, tactics, and campaigns were not resonating with this particular audience. What I've learned I'll share with you in this article.

Product marketing for developers requires a completely different approach

Before crafting a developer strategy, you must understand that it requires a completely different approach. This is a unique audience and although you'll use all of the skills and tools you have in the product marketing core framework, the approach and the perspective will be different.

What makes developers unique?

Of course, developers are not a monolith like any other audience. But by and large, these are typical considerations you must have as you're crafting your strategy.

Averse to traditional marketing

I think one of the key takeaways here is the fact developers can be averse to traditional marketing. I don't want to say developers hate marketing but some of our typical tactics such as analyst reports, and long-form content like ebooks don't resonate with this audience.

From developer marketing to developer experience

Perhaps it makes sense to stop considering developer marketing and really look at it from the developer experience.

What you see is a breakdown of some of the traditional marketing strategies that marketers employ next to what the developer experience looks like.

Segmentation

From the point of segmentation, within traditional marketing, we tend to segment audiences based on industries, focus markets, and regions. However, for developers, this is different.

We can segment developer audiences by use cases, the programming languages they use, their role or function, as well as region.

Now the region has a unique nuance because although a developer may live in Brazil, for example, the work they're doing is for customers and clients in Singapore. When we talk about segmenting developers by role and function that means web developers have unique needs over mobile app developers just as an example.

Content

Looking at content, as I mentioned before, long-form content doesn't resonate with this audience. Instead, they prefer short-form text and video content and any content developed for developer audiences needs to be inspirational and educational.

What do I mean by that? Educational content consists of how your products can be used. Whereas inspirational gives them ideas of real-world use cases, and how they may employ your products to fit their needs.

When you develop content for other audiences, it can be aspirational and you can get much of your premium content. That doesn't work for developers, you want to focus on ungated content, such as blog articles. Whatever you produce needs to be focused on your technology and your products.

Thought leadership

Thought leadership for developers is mostly respected by internal developer evangelists and advocates because essentially, they are developers. They also look to other developers, influencers, and bloggers as opposed to industry analysts, or C-level executives.

The kinds of things that you would promote and use for decision-maker audiences don't work for developers, they want to hear from other developers. They also look to developer communities and forums for thought leadership, so they sort of feed off of each other and share information. That's how you can gain thought leadership among these audiences.

Really put your evangelists and your advocates out there to share their experiences, their knowledge, and to resonate and connect with other developers in your prospective customers.

Events

Now, when we talk about events, conferences and trade shows are a cornerstone of pretty much every marketing strategy. The difference with developers is their interactions in your booth are expected to be more technical in nature, as opposed to conversations with sales staff.

In addition, they look for the auxiliary hands-on experiences that come with many live events, such as hackathons and workshops.

As you're developing and creating content, or presentations for keynotes and workshops, make sure they're more on the technical side of content and really connect the dots between what you're offering and what attendees of those events have come to look for.

Sales

When it comes to sales for developers, simple and standard pricing and self-serve experiences. They want limited interactions with salespersons.

Product

When you talk about your products, typically when we describe our products to executives, we present high-level functions and features. Developers want to know what's under the hood, what makes it work, and what the technical competitive advantages are.

Driving developer activity

I assume that if you're looking to build a developer strategy, you're trying to drive developer activity. That activity comes in two forms, awareness, and interest, as well as acquisition and retention.

If you're looking to build a developer strategy, you're trying to drive developer activity. That activity comes in two forms, awareness, and interest, as well as acquisition and retention.

Awareness and interest are the tactics and strategies you use to drive developers to your website or to your developer portal. Acquisition and retention activity is what happens after your developers make it to your website.

Acquisition and retention

You want to acquire them. Whether that means signing up for your newsletter or to receive company information, or driving them to your developer portal to register for an account so they can experience your products.

Create a truly frictionless sign-up process

You want to make whatever signup process as frictionless as possible. Once they've signed up, you want to make it as intelligent and intuitive as possible for them to find what they've come to look for.

Whether that's API's, SDKs, documentation, whatever it is, you want to make sure developers have a good experience within your website or within your developer portal.

Prompt sign-ups through hands-on experiences

Of course, once you've acquired them, you want to make sure developers are active and keep them active. That means giving them hands-on experiences.

Make sure documentation and tutorials are on point

As always, make sure your documentation and your tutorials, code snippets, and anything else you offer are as up-to-date as possible. There's nothing worse for a developer's experience than for them to need help and to find out the tools they would typically use to get that help are out of date.

Go-to-market strategy

Let's go a little bit deeper into the typical go-to-market strategy as it relates to crafting it to fit developer audiences.

GTM: customers

Target audience

The term developer can be a bit of a misnomer because we tend to think of developers as people that just sit around writing code all day. That's not necessarily the case.

Developers are no longer just the ones that write code

Developers as a title can also include product managers, project managers, solution and systems architects, designers, and more. They all have the common background of understanding how software is built, how it works, and how it integrates within the tools they use, and how they can use software to solve the problems they have.

They may work in your target markets but are not defined by company or industry

Developers can work within and probably do work in the markets you're focused on, your target markets, but they're not defined by that company or industry. Keep in mind that developers typically switch jobs every 18 to 24 months, on average, not every developer but on average every 18 to 24 months they change jobs.

Developers are in high demand and you have to recognize that. Ideally, you want to speak to their needs so you become their solution provider of choice, regardless of what industry they're working in.

For example, a mobile app developer may work in transportation now. But in six months, when they change jobs, they'll be working in retail. They'll still be doing mobile app development work, which means some of the tools they've used in the past they'll want to employ in their new environment.

Consider segmenting by use case, programming language, function

Because of these job changes, developers can be segmented by use cases, programming languages, and functions. So JavaScript developers can be a segment depending on what your product offers.

Not at the Tail End anymore!

Something that's essential when thinking about crafting your developer strategy is to realize that developers are no longer at the end of the buying process. Hence, the term long-tail developers, which I really never use because it doesn't apply.

Developers play a more significant role now throughout the process of identifying and selecting technologies for their businesses.

Initiator

In the role of an initiator, developers seek tools and solutions in order to meet the needs of their given project, or product, or problem at the time.

User & influencer

They are also users and influencers when their upper management presents them with software to be tested and to determine whether or not that software or product is a good fit for their particular organization or environment.

Decision-maker

In many ways, developers can be decision-makers. A wise person once told me that developers may not always be able to say yes to a product, but they can definitely say no.

They can say no to products, solutions, tools that are cumbersome, difficult to use, or ones they've had a poor experience with in the past. You want to avoid that, by keeping in mind, this is more about the developer experience than it is about developer marketing.

GTM: value props

As you develop the value propositions, understand developers look for straightforward and straight-to-the-point content. Avoid fluff, jargon, and that which is abstract.

What does it do?

What does your product do?
What are the pain points it addresses?
What are the needs it will solve or the problems it will solve? And
What is the actuality? Don't speak in terms of future functions and features.
What does it do right now?

It also helps to provide real-world use cases.

How does it work?

I like to think of developers as a type of mechanic because they want to see not only what the product does, but how it works?

How does it interact?
What powers it? And
How will it impact and influence the other products that are used around it?

Who uses it?

Credibility is key

Establishing credibility goes a long way to acquiring and retaining developer audiences and developer users. In order to do that, credibility can be gathered by establishing use cases and demonstrating to other users of your products.

Those users don't always have to be from big companies. Like I said before, the community consists of evangelists as well as external influencers and other developers within the developer community.

Therefore, establishing users and use cases from those sources can go a long way to bringing about the credibility you need in order to gather more users for your products.

GTM: promotion channels

When I first started focusing on developer audiences, it was clear some of our traditional methods of engaging developers weren't working.

The things we would employ for C-level executives just didn't work for developers, again, such as analyst reports. I started to understand that developers have different needs, and they go to different locations and outlets for information, engagement, and for finding new solutions.

So while some of the traditional methods work, such as search engine optimization, and paid search, as I mentioned before, employing things like Pay Per Click campaigns and placed content need to be within publications that focus specifically on developers interests and needs, and some of those I've listed here.

Email

Email can work for developers. However, as I said before, it needs to be opt-in and non-intrusive, which means not too frequent. It also needs to be relevant and straightforward.

Making sure your direct email campaigns and direct email outreach have some sort of relevance to product information, what's going on within the developer community, as well as events and topical subjects will go a long way to retaining readership.

Communities

Another unique aspect of developer audiences and I've mentioned this before is the fact they have a community focus or a penchant for working and listening to their community peers.

So looking at some of the communities that are out there, such as GitHub and Slash Data, you want to make sure you have a presence within those channels.

Not necessarily from a strictly marketing perspective, and when I say that, that means giving your evangelists and technical experts the opportunity to engage with your prospective customers as well as existing customers through those community channels.

Social media

Social media is also big with developers in ways that might not necessarily work for upper-level decision-makers. Channels such as Reddit and Twitter have large developer communities, and many opportunities for you to not only interact with your prospective and existing users, but also for you to listen to what's going on within their world.

This will help you continuously craft content and messaging to fit what's going on with them and what their interests are.

GTM: positioning

Positioning for developers can be a little tricky. Understand that positioning is a marathon. It is definitely not a sprint and will continuously evolve over time due to the nature of your products, as well as the nature of the developer universe.

Things change on a regular basis and you want to make sure your positioning and your messaging and everything you're doing to target developers evolve along with it.

Market fit

So as you're looking at positioning, consider the market fit. When I say that, I mean there's a really good chance your products will be used amongst other tools and solutions. So what's the position there?

How well will it integrate with those products within the different organizations you're targeting?
How well will your products augment the skill set of the developers you're targeting?
Or help them build new skills?

Then think in terms of technical application.

Where were your products used?
What will they be used to achieve? And
How do you communicate that in the best way possible for developers?

Again, don't speak in terms of abstract, consider the real practical applications.

Competitive analysis

I also want you to take a long look at what your competitors are doing. Don't shy away from what the differentiators are between what you offer and what your competitors offer, and be honest and upfront about that.

Even if your competitors offer, let's say, a better product, the experience for developers with your product could be better and that could be your huge advantage.

When we're talking about competitors, don't just consider the big ones. What we tend to see within corporate environments is they consider their competitors to be other large companies, as opposed to smaller startups, which they tend to ignore.

Those startups come out of nowhere, and they disrupt entire markets. Think of Uber and Bird scooters as an example. So as you're looking at positioning, and you're looking to craft your positioning, pay attention to the entire landscape, not just the landscape that seems most obvious.

GTM: distribution model

The distribution model for developers doesn't have to be complicated. For the most part, there are three basic ways to make sure developers have access to the products you offer.

Direct

The first is direct, pretty straightforward. This is when developers come to your developer portal, sign up and consume through your owned channel.

Make sure this is a great experience for them. Make sure that first of all, you're driving your traffic to your developer portal from your awareness and acquisition strategies. Once they're there, make sure there's alignment between the messaging in your awareness and acquisition strategies and what they see on the developer portal.

Make sure it's a good experience like I said, it should be well organized and intuitive. They should be able to search for what they're looking for. Again, ensure documentation is updated.

Self-serve is not just preferred, it’s expected

Ideally, developers want self-serve options. They like working in their own time in their own frame and self-serve gives them the opportunity to do that. Because the name of the game when it comes to software development is speedy, quick development, and faster time to market.

I mean, that's what agile software development practices are all about, and you want to make sure that you're in line with what their expectations are.

Market places

Market places for most software offerings and most developer offerings are essential because you want an ambient availability for developer acquisition.

What does that mean?

Be wherever your customers go to find solutions

Ambient is being wherever they are - marketplaces are where developers are. Consider AWS marketplaces, Azure, IBM, Red Hat, there are numerous marketplaces out there and they operate pretty much like a Target or a Walmart.

It's where developers go where they can find the APIs, SDKs, and other tools they're looking for. They're convenient and familiar. So when you place your products within the marketplace, let's say APIs within AWS, you want to maximize that channel as much as possible, as much detail as possible, make sure the documentation is updated.

If you can incorporate code snippets and tutorial videos, do as much as you can. Because again, this is where developers go to find the tools they need.

Another thing to keep in mind is that within some corporate environments, their developers must use marketplaces in order to purchase and incorporate new tools into their technology stack.

For example, there are developers that are required to use the IBM marketplace. You want to make sure that if you want those developers that your products are there within reach where they are required to go in order to get new tools and solutions.

Partners/resellers

Of course, there are partners and resellers so these are value-added resellers, ISVs, etc. In any case, regardless of what your partner or reseller model looks like, you want to enable them as much as possible to represent your products in the best way.

That means giving them proper technical training, all of the sales enablement tools and information they need, and ongoing support.

Keep documentation updated!

Again, documentation is key. So as you build your distribution model, there needs to be a regular cadence of documentation review, in order to make sure it's accurate, and developers are having the best experience they can.

GTM: price

Pricing for developers doesn't need to be complicated.

Free is key

In fact, you may want to begin with a freemium or trial model. This gives developers the opportunity to experience and interact with your products without any commitment.

Add-ons and services

Then from there give them optional upgrades that require payments such as additional usage or storage. As part of your strategy, you want to create a path to paying conversion model.

Simplified pricing structures

And once those developers convert to paying customers, keep the pricing structure simple, and very straightforward. These are just a few examples: per user, tiered, module, usage-based. Very simple and what developers have come to expect.

Check out your competitor’s pricing models

Be sure to check out your competitor’s pricing models. Whether it's cheaper pricing or pricing that's more straightforward and simple you can get a competitive edge just through your pricing alone to accompany your products, of course.

Make pricing readily available - remove the need to “contact us”

No matter what you do, work to remove the "Contact Us" requirement for developers. Again, they want to move at their own pace, and they want things to be easily accessible. When they have to contact anyone in order to find out the basics of what to expect for pricing that becomes a friction process and not something developers are really open to.

Again, developers want to operate as smoothly as possible and the need to contact someone just to find out how much your products cost, creates speed bumps that they're not really open to.

Offer simple and upfront pricing

In the last note on pricing, I'll also say that, if possible, make your pricing public or at least easy to find so developers know what to expect when it comes to purchasing your product offerings.

Thank you.