How do you approach messaging for developer audiences vs non-developer b2b audiences?

No one likes being marketed at, but, when done well, we typically don't mind being marketed to. Generally speaking, we've found there's far more nuance to this dichotomy than simply drawing a line between audiences. I've also noticed many companies shift away from the divided messaging approach (i.e., dedicated landing pages for developers or non-developers) toward a single page that speaks to both features and values. Since we can't reasonably control 100% of who lands on a given piece of content or webpage, a rough set of guidelines for meeting the needs of both audiences might be to:

• Speak concisely to the differentiated features that solve particular needs
• Use customer examples and quantitative data to speak to the value this product brings to the business
• Avoid undifferentiated jargon that signals to either audience that they are being marketed to

Depending on where the asset would live, dialing up either the features or value can help address the needs of a particular audience. One of the most visible places that this blended messaging appears is online, but for technical resources, documentation, or other content that is segmented by persona more clearly, focusing on either value or features is often effective at getting heads nodding.  

One of my first jobs in tech marketing was promoting Amazon's software development kits (SDK) to developers. What I learned from everyone at Amazon is the power of using "plain English" when talking about anything.

If you look at Amazon's site, you'll notice they use very simple language to talk about everything from shoes (on the retail site) to highly complicated software tools (in Amazon Web Services). The idea, I think, is that everyone can benefit from the writer working really hard to understand a subject well enough that they can explain it in simple terms.

I, myself, don't always succeed at using "plain English" to describe my employer's products to people. Sometimes, I get pulled into hanging out with the Cool Jargon Kids. But I recommend always trying to use simple words and sentence structure if you can.

The best way to approach product marketing is to become intimately familiar with your personas.

Having said that - remember also that developers are human beings.

As such, when at work - they value (each prioritizing individually of course) the same things that everyone else does:

- success at your job/the task at hand - finding the right code for the right goal

- productivity and the ability to solve immediate issues as fast as possible - debugging easily; identifying points for improvement in your code

- quality of output - clean and efficient code

- collaboration - working smoothly with the rest of the team and other stakeholders

- learning and developing

- mentoring each other

Once you've created the messaging, the rest of the job is teaching your stakeholders how to deliver this messaging, which can be challenging if they've never targeted developers in the past. This would then require that said stakeholders also invest some time in ramping up their technical knowledge just enough so they can speak the speak when selling the relevant product/features and learning about other tidbits they would help them: understanding what social media is preferred by developers, understanding developer jokes, jargon, puns etc., knowing about conferences, knowing about Pi day (seriously) and other little things like that can also help recruit everyone in the organization towards the effort. 

I have done many messaging projects for both developer and non-developer audiences. The process is the same regardless of audience: understand the personas and their needs, develop a unique value proposition that meets those needs, create key messages. The differences come in the content of the messages and language used. 

It's true that developers are not at all tolerant of "fluffy" messaging. But neither are other buyers. You need to do enough research and deeply understand your buyer's needs (and your product!!!) so that your messages are credible, compelling, and relevant. Write and rewrite until your messagsing is crystal clear and test it with real developers.