How to live, breathe and think like a developer

So, you know how to talk like a developer? That's great! But in this article, we’re going to take it even further. Where's the gap between talking about something and really living it? Or in other words, how can you walk that walk as well as talk that talk?

Not sure?

Well, that’s why we’re going to expand our breadth of knowledge beyond just basic developer characteristics. We’re going to look at the various developer personas within the developer marketer world and how we can really target our products towards them.

But wait. Feel your developer-speak has gotten rusty? Don’t worry! Before we dig into the real meat of this article, we’re going to have a quick crash course on effective dev messaging.

Main talking points include:

A quick warm up: the basic commonalities between devs

Okay, so to warm up, we want to get to that dev mindset right off the bat, which means getting to that integral information straight away. Let’s go!

Devs are problem solvers. Products must present a solution.
Cut out the frills. Avoid marketer-speak at all costs. Instead, focus on hard benefits.
Is your product ‘shiny, awesome, sexy?’ No one cares. What is it and what does it do?
Devs trust devs. Your aim is for them to be influencers for your product.
Be honest. Do you want their help collecting testimonials? Tell them that.
Devs are doers. They want to try before they buy.

👆 See that? Precise, condensed, economical. No, I’m not being lazy. I’m in that developer mindset, remember? And devs are anything but lazy. The point is, devs like short form condensed information that’s purpose-driven and transparent. Before we go deeper into the nitty gritty, these are the nuts and bolts that can lead us in the right direction.

So, now that we’ve snapped into that dev mindset, let’s go deeper.

To be or not to B2B

That is the…never mind. 😳 As much as it might be tempting to pledge your undying devotion to customers in a glorious sonnet, the truth is, Shakespeare ain’t gonna help you in this situation. What is one of the main pain points of B2B marketing? That's right. The purchase cycle can take an eternity.

In fact, according to Forrester, the average buyer needs to consume about 11.4 pieces of content before making a buying decision. Also, according to Gartner, 75% of B2B purchases involve people from a wide variety of roles, teams, and locations.

This is the primary reason for the delay. In B2B sales, there’s rarely one person responsible for the buying decision. And so we need to ensure that we really do our research on the specific user and buyer personas we’re appealing to. Difficult right?

B2B for software developers

Now, imagine being faced with the same task, only now there are more potential gatekeepers. Not just that, but many of the personas demand at least a basic knowledge of technical specifications involved in the industry. Not scary enough for you? Many of these potential buyers/users have an active aversion to marketing. 😱

The good news is that the solution is pretty much the same as you would find in GTM strategy: Identify and establish your personas. You’re just going to have to do a little more graft to identify them this time around.

Identifying your personas

When tapping into your persona headspace, it can be tempting to think of your users as homogenous beings. But unfortunately for us, weird and exotic though they might seem to the average marketer, devs are not Pokemon. They're not a sub-species of mythical creature you can capture once you know they're identical attributes.

In other words, there are specific personas with the developer community. Yes, there are basic commonalities between them. But let's imagine we’ve traveled to the foreign land of developer island for a second.

Sure, being able to talk about the weather might get you a smile and a nod (or, in the real world case of a dev, an actual acknowledgment to your email.) But the conversation is going to be pretty shallow unless you can address their specific day-to-day functions.

So let’s outline some of the specific developer roles you might encounter:

The software architect

They’re going to have a big-picture perspective on your software. They're very ‘macro-minded,’ meaning they’re going to be looking at how even the slightest changes impact your organizational architecture as a whole. They’re going to be involved in the technical standards that apply to software, as well as the coding standards.

Okay, so here’s a critical term to put in your developer phrasebook: technical debt. Basically, the software architect wants to reduce this as much as possible. In a nutshell: they want to know that your product is going to create really great functionality in the short term, without needing costly re-working of a product in order to accommodate them.

The development manager

This role is closer to the front lines. They're actively supervising the functionalities that the programmers are coding.

Here, your messaging is going to apply more to basic functionality, since the development manager only wants to know that everything is going to run smoothly within the framework that the software architect has handed down.

Appealing to the pain points of both of these personas could be the difference between securing the buy-in and not securing it, since both could potentially be a part of the ‘buying team.’

Josh Aberant, CMO at SparkPost, has this to say about appealing to dev pain point:

“When you can identify product development stakeholders like this going in, and what their hot-button concerns or pain points may be, you’re a lot closer to success than if you’re focusing on just the “developer” you imagine your widget will absolutely, positively sing to. Because within any given organization, that presumed developer archetype may not actually even exist.”

In other words, when appealing to dev pain points, don’t be generic. Yes, devs are looking for short-form information, but that doesn’t mean they’re looking for limited information. It just needs to be highly specific and purpose-driven.

Notice someone missing from this section. You got it. It’s…

The programmer

These are the guys actively involved in the coding, and they're probably going to have the most intensive interaction with your software on a day-to-day basis. Now, they’re unlikely to be involved in the buying decision. Does that mean you shouldn’t reach out to them? No.

As the ones with their noses to the ground having the most engagement with your product, programmers are going to be the best evangelists for your products. The software architect may have larger macro concerns, and the non-developer buyer may be more concerned with the overall revenue.

But all of this is going to look pretty shaky if the foundations of the organization are unstable. If those closest to the ground are leaving in droves because the software doesn’t meet their day-to-day job requirements.

They're over worked, they’re behind on their deadlines, well, you know how the story goes….

Beware the gatekeepers: Separating user persona from buyer persona

Now, many times there's a crossover between the two. The software architect and the development manager are going to be involved in the buying decision, for example. And so in this instance, highly specific information is going to appeal to them, but wider organizational concerns are also relevant.

As discussed above, very often the performance of these specifications is inextricably linked to company efficiency, which has a direct impact on the bottom line.

What chief mistake are we always hearing about in software marketing? That’s right. Emphasizing features over outcomes. Now, with developers, there’s a neat little exception. Developers are highly intelligent folks who have interacted with many forms of software like yours.

And the thing is, they probably have a pretty good idea of what your product does on a broader scale. In this case, information about specific features is going to be pretty important to them because they’re going to want to know how your product is differentiated from the rest.

Striking a balance

So, we ditch all talk about overall outcomes, right?

Not so fast.

You need to bear in mind that not everyone involved in the buying decision is going to be technically oriented. For those holding the purse strings, they’re going to be pretty fixated on the benefit of your product on a ‘macro’ level.

If this is the first gatekeeper you’ve encountered in the purchase cycle, and you haven't convinced them that your product is going to solve the broader pain points of the organization, you’re going to fall at the first hurdle.

To put it simply, it’s probably best to strike a middle ground to focus your messaging towards both micro technical specifications and macro concerns.

Ankit Shah at Quickbase, has found success in focusing on those developer personas that are both involved in the overall business decisions and have some technical prowess. He refers to them as the ‘builders.’ A good example that we’ve identified in this article would be the software architect. Here’s what he has to say about the process.

‘We learned early on that we wanted to talk to those that are building a solution. So, our programs and campaigns are very much focused around talking to the builders and the administrators within the end user categories.”

Putting user intent into action

Now, we promised we were going to show you how to walk the walk as well as talk the talk, right? So, we’ve gathered this information on the developer persona, we’ve segmented the different job specs, we’ve separated user from buyer, now what do you do with this information?

Integrating your personas into the strategy

The first step, obviously, is to integrate all of this information into your strategy. Put these individual personas into your product portfolio or your product roadmap. Make sure this information is collated, updated, and kept in a place that’s accessible to all those involved in the sales cycle at any time.

Do you have detailed descriptions of the personas your team is likely to face? Maybe in this instance, since you’re dealing with highly specialized language, you could have a glossary of terms in which you could map specific keywords to certain personas.

Maybe you could map specific personas to different points in the buying cycle. Your team might need to be agile, and they may have to pivot to different terms at different points.

Within that, you could prioritize terms based on how likely they are to trigger a specific persona pain point. What are the hot button terms you can arm yourself with?

Workshops and training

You want to ensure that those on your frontline are armed to deal with whatever challenges might face them. And with developer marketing, this can be pretty nerve wracking. So, why not boost your team's confidence by allowing them to practice this terminology in a safer space?

Jayne Pooley, Director of global marketing at Keyloop, found great results doing this with her sales team.

“Up until that point sales were used to going in and selling to one type of buyer persona. And we were challenging them to speak to more people… Some of the training and the workshops that we did with them introduced personas. We introduced them to two new personas that they'd never come across before. So, they had confidence.”

To go back to the language learning analogy:

You learn your terms.
You practice your terms in a class environment.
You put those terms into action in the real world.
You learn from your mistakes and successes.

Events

Remember how we said that developers are doers. Another way of putting it is that they like to try before they buy. Organizing events is a great way to show that your product really can walk the walk.

It’s also a great way to create those first evangelists in your product. Devs like transparency, and knowing that your product is there for them to try is going to create a greater level of respect in what you’re doing. You’re not hiding behind empty spiel. Your product is open for trial.

It’s also a great way to get a first-hand account of user intent and pain points. These are busy people and they’re not always going to provide you with that valuable information and feedback over email or over a digital platform. Events allow you to observe devs in their natural habitat.

What better way to capture user intent than to see it first hand?

Marketing to a niche audience

What are the obvious drawbacks to appealing to a niche audience like software developers? Well, the most obvious is that they’re very community-focused. They trust only those that are in the know and anyone who’s not is suspect, especially when they come armed with marketing speak.

So, the obvious solution is that we become well-versed in the subject, but this is pretty labor-intensive and, although worthwhile, does require research and training.

The secret benefit

All this is true, but there's a silver lining to this that may not be obvious at first. Since Devs are very focused on their own niche, once you manage to hook them in, they’re going to be fantastic evangelists for your products.

They like to share solutions with other developers online, and once they start singing about your product, it’s going to seem far more credible to newbie customers than any marketing spiel you could put together.

An article in Digital Agency Network stresses the benefits of niche marketing in building believers in your product:

‘

The distinguishing benefit of niche marketing is audience relationships. The buyer (audience) and seller develop a personal relationship from scratch.”

Devs are like cats…sort of

Secondly, although it’s harder to learn the language, once you’ve got there this kind of marketing allows you to be highly targeted in how you market the use case. It’s much harder to position, for example, a new soft drink, which has a pretty generic appeal, than something that has a very specific purpose, right?

Finally, devs might not be like Pokemon, but they are a bit like cats. No, really. Although they may seem aloof at first, once you’ve cracked that hard exterior they tend to stick to a piece of software like glue. They show great loyalty and have a high potential to convert other developers.

Once you’ve established trust that’s based on your product providing a real solution to their problem, it’s going to be very hard for competitors to steal them away. 🙌

Psst.. Want to network with other developer marketers? Join our slack community!