Marketing to Developers Done Right

“Everyone can jump into marketing” became a phrase that most people believe in. “Developers hate marketing” is another one. Without understanding the width of it or the depths of marketing, most developers assume it’s just a purely promotional activity that results in selling the product.

Well, let me tell you how things work when your marketing team is both skilled and empowered.

Marketers Explore the Market

And I don’t mean this in a manner that involves analyzing competitors in depth, and then copying their approach without understanding what they are doing and why they are doing it.

Marketers are there to understand who the users are, which pains they had before they started searching for a solution to those problems, and what that process looked like.

Let’s say you have a product that sells to developers. Here’s how marketers approach the market:

• Analyze who the users are.
• Analyze who is involved in the buying process and who has the most say.
• Talk to customer success, sales, get to understand which use cases work the best.
• Talk to customers to analyze how they found your tool.
• Dig deep into the developer processes and get to understand when does a need for a tool like yours arise. Pre-deployment, pre-users, pre-revenue, or only when they start scaling and bump into operational issues?

And then they create a map that showcases who the ideal end-users are, who they need to impress to get the green light, what they need to hear/see to even click on that “Sign up” button.

Marketers Unblock Potential Users

Content is the most effective way to get in front of developers. But that content has to be written by others who are exactly like them!

If you are a marketer, you won’t be able to write a blog post that developers will love and that will end up trending on Hacker News. Those folks appreciate other engineers who have some knowledge to share. They need to understand how their use case is similar to the use case of another engineer who solved a problem they are experiencing.

This is why all those big companies hire DevRels, to have a member of the team that can connect on a deep level with the end users, and who can give early feedback to the product team, or get inspired and create marketing materials for the marketing team.

However, you don’t always need to do that. It’s enough to reach out to someone like me, who can help you with finding the right writers for your use case. I’ve brought millions of developers to websites I’ve worked on. The key to my success was the fact that I’ve never tried to pretend to be one of them, I just understood what developers needed, and developed a system that helped me find other devs who could deliver the type of content I wanted to showcase.

Marketers Don’t Tell Lies

I have never ever claimed anything that wasn’t true. If you tell to a developer that your product can do something, and then they test it, see that it doesn’t work, and drop off, that’s it. You’re done.

Out of all the people you can work with, engineers have the highest of standards. And if they can’t trust you to do what you’ve showcased on your landing pages, they are gone. Even if the functionality at some point gets to the point that it’s useable, they have already churned and they won’t look back.

I have also worked with some sales people who haven’t had issues saying to the potential client that something can be done, even when they knew that the functionality won’t be ready yet. Those sales people have the highest churn, and you either need to train them or fire them. Those disappointed engineers will talk to other engineers and persuade them not to ever touch your tool.

Engineers talk to each others in closed Slack groups, or on public forums. One lousy review can bury your early-stage product. That’s why you shouldn’t overpromise and underdeliver to engineers. Your greed is the cause of their failure, and failures in engineering are not tolerated.

Marketers Showcase

Developers are a tough audience because they need to see things for themselves. In terms of content, this means that your documentation has to be spotless and up to date. If it’s not, you should reconsider your priorities.

Developers first need to give the tool a spin before they make a decision. They won’t care about your case study once they figure out that your tool only works in certain situations, or that your features aren’t properly documented.

Once they see that the tool works as intended, then they also look for other materials they can showcase to their team. This is where case studies come in, as they speak in the terms which stakeholders like.

Of course, every product is different, and metrics can’t be the same for all. Don’t just use the phrases “developer happiness” or “productivity”. Everyone claims that. Here’s where companies like Literally shine, as we easily jump into your dashboards and figure out which numbers are the best to use as an example.

Marketers Have a Soul

Deep down, we just want to help, unblock people within the team, and ensure our users truly understand when and how to use the tool we market.

If you don’t think that’s true, reach out to Literally and see for yourself.

‍