March 19, 2021
Founder of Hoopy, the developer relations consultancy. Need help with your developer relations? Get in touch.
The old lie that developers hate marketing seems true because we usually only notice bad marketing.
Messaging is one area of developer marketing that is particularly tricky to get right. Messaging that misses the mark sticks out because it makes us aware that we are being “marketed” to. It pulls us out of a receptive state and puts us on high alert.
Good messaging, on the other hand, is simply a statement of truth. It reflects the person back to themselves. It recognises where they are, who they are, and what they need.
What makes developer messaging hard is that the where, who, and what rely on knowledge and experience that are unique to software developers. On top of that, most developer targeted products solve niche problems that not even all developers would recognise.
Perhaps the hardest thing is not knowing what you don’t know. Unknown unknowns, as someone once said.
That can lead to marketers creating messaging that, to them, seems to be right but to a developer might be anywhere from completely wrong to okay but framed in a way that doesn’t make sense or that focuses on something a developer wouldn’t care about.
Often, the result is messaging that falls into the uncanny valley. It has all the elements that should make it work but it provokes the wrong emotional response.
One analogy is that of image resolution. Imagine a picture of a butterfly sat on a flower. Reduce the resolution of the image enough and you’ll be left with something that has the right colours in the right places but none of the detail that matters. Go far enough and it ceases to be a picture of a butterfly on a flower.
Increase the resolution and, at some point, it becomes clear what the subjects of the image are. Stand far away enough or, if you’re like me, take off your glasses and you might think that’s as far as you need to go.
To a lepidopterist, or butterfly expert, the crucial detail they need might still be missing. It’s only when they see the image at its highest resolution that they can know the particular species of butterfly and so on.
Building a messaging framework without the full, in depth understanding of how the product fits into the developer’s life is a bit like working at low resolution. You can give an impression but the messaging will never truly hit home because it misses crucial detail.
Developer marketing and developer relations should not be for “technical” people only.
Many people have had and continue to have successful careers in DevRel and developer marketing without having a background as a professional developer or a CS degree. In fact, DevRel and dev marketing offer superb opportunities to people who might not think of themselves as “technical” but who have much else to bring.
However, to create messaging that resonates with developers requires a base line understanding of those people’s day to day work, their frustrations, needs, and culture. Let’s call it empathy, because that’s what it is.
If someone hasn’t done front end dev work, it will be harder for them to tell a credible story of what Next.js brings to a React developer, for example.
So, how do we bridge the empathy gap?
The tech industry sometimes skates close to the fetishisation of the ability to make software. While “learn to code” isn’t the answer to most questions, it has some merit when the question is how to create messaging that is more likely to resonate with developers.
Not every DevRel person or developer marketer needs to become a proficient developer. However, learning the basics of what it’s like to be hands-on with the product you’re promoting is really just good preparation. That can only do so much, though.
The key to developing empathy with your target developers is to speak to them. Whether it’s through one on one interviews, observed sessions, focus groups, or even surveys, you’ll gain real insights that will increase the resolution of your messaging.
The detail of how to create a developer messaging framework is, however, a story for another time.