How technical does your messaging need to be when marketing to developers?

It depends!

A common pitfall in developer marketing messaging is that the marketers spend a bunch of time trying to put things into terms they can understand as a non-developer. The trouble is, what works for you doesn't necessarily translate for them.

Focus on the problem that your product is solving for them, how they would describe it, and what resonates with them. 

That said, the messaging is often times going to veer away from classic organizational benefits: cost, ROI, competitive advantage... towards an individual's benefits at work: reduction in friction, increased personal productivity, being freed up to do more interesting work, etc.

Focus on the individual human, not the organization and the level of technicality should sort itself out. 

Also, don't be afraid to do deep dives into the technical to build your empathy and understanding. Any technical topic can be grokked with curiosity and dedication. Your product teams will appreciate you and you'll build trust with your developer community if you make this investment.

Your documentation needs to be extremely thorough (technical), and your resources need to leave no uncertainty in how or why to use new products and features, but your topline message doesn't necessarily need to be "technical"-- at least not how I think of the word, which is detailed and revealing-full-complexity. It just needs to be frank. Exactly what is the thing, and what can you do with it. Eliminate unecessary superlatives that developers often find dubious like "best" "fastest" "end-to-end" "complete solution" and describe it exactly how you would describe it to a developer within your own company. Developers don't buy silver bullets, they appreciate and celebrate a thing that does one thing very well.

When it comes to presentation materials or demos, I think a common misunderstanding is that developers don't care about the "why," and you should skip your up-front narrative. That's absolutely not true. You just need to tighten and tune that narrative to speak to that audience. What do they care most about? Maybe talk less about cost savings, retention, long-term business value... and more about time-savings, burnout, skill-sharperning, and individual career-value. You don't have to leave off the problem statement to be frank: "Widgets were time-consuming. Our product lets you develop without using widgets."

Developers want to know what something does and how it works. They want to jump in and try it out themselves. They want to see something new and get their hands on it. I’ve seen some persona work that says developers like to be the smartest person in the room and value content that stumps them. So you can say it does need to be technical, but it's not really about how technical the copy is and more around are you creating a message that caters to how the specific persona engages. If you lead with the story arc of market problem -> winners and losers -> product solves problem, that won't really tell a developer how to create something. Rather than look at it as how technical messaging needs to be for developers, I look at it as the core developer work isn't always early funnel. And early funnel content is more around the art of what's possible vs later funnel content is more around how to get something done. Marketing to developers tends to map closer to later funnel content. 

Good question. You should definitely have the technical stuff at the ready, and usually docs will be your best friend for that, as would "Getting Started" guides, video walkthrough, etc. 

But I tend to think of the technical stuff as the what and messaging as the how. 

Developers are people too :) You don't have to throw the technical goobledygook at them outright. Especially when you're trying to convince them of your value props. That's where good messaging comes in. Be as straightforward and human as you can be. They'll know where to find information on your ESB, CLI, App Script, API, SDK and will definitely expect that information to be there once they're ready to technically implement. But messaging should focus on getting them to mentally commit.

When our team launched Gmail Add-ons in 2017, we built a really cool way for people to add their third-party app in Gmail's now ubiquitous "third-rail". We had the Apps Script tutorials and SDK documentation for that, and they knew that Gmail was their ticket to a billion eyeballs. But here's how we "messaged" it.

Write once, run anywhere

With Gmail Add-ons, developers only build their integration once, and it runs natively in Gmail on web, Android and iOS right away. Users only install the Add-on once, too, and it shows up in Gmail across their devices. So instead of wasting time writing separate integrations for web and mobile, you can focus on bringing your app’s most powerful features right to your users when they need them most. Gmail Add-ons are built in Apps Script using a newly-designed "Card" system that lets you easily combine different UI components. Developers can create a snappy user experience that feels like it was natively built into Gmail. The result: integrations that are cross-platform from the get-go that save your team time.

Link: https://cloud.google.com/blog/products/application-development/bring-power-of-your-apps-into-gmail_9

Extremely. If you don't speak their language you will never be able to build credibility with them. Your messaging should also focus on education and explaining what your product does and how it does it instead of why your product is better. Developers tend to be skeptical of any such claims until they've verified for themselves, usually by playing around with the product. Your messaging also needs to be initimately familiar with their current worfklows, habits, and preferences so that you can highlight product capabilities that they might find missing today in other alternatives. 

I would say long form content messaging needs to be very technical towards developers and that is where developer evangelists are powerful at building brand trust and community. Short form messaging is the same as any other messaging: needs to understand the target audience and speak to their pain points, then give them the "so what" that your product can help them with. 

Agnostic of audience, a good product marketer will speak the common language of the audience they are serving. So when listening to the developer target audience via gong or chorus calls, you notice patterns in choice words/value props - it is necessary to weave those points into the overarching narrative. For example, at Crossbeam we are a data collaboration platform and have to navigate complexities in data sharing + information architecture before our customers can get value. We lightly cover the basics in a "how it works" step by step flow to help operations leaders understand data ingest + destinations so the end users can unlock value. TL;DR: conduct listening tours and apply common points of interest to the narrative to provide a consistent story that resonates.

The golden rule here is to make your messaging clear and actionable. A good template would be: 

Achieve  

by using our ,

which enables you to

See how does it in action.

Get started now

Think of the journey you want your developer to go on. You wouldn’t jump straight to the manual of a particular model if you just decided to purchase your own barbecue grill. Start simple and keep increasing the level of technical detail as your developer audience makes their way from a Google search to your documentation.