Engage and convert by putting developers in the driver’s seat

“Marketers have a growing need to understand what is the best way to attract and engage with these customers.” - Connie Tai, CMO at Instruqt

My name is Roland Walters, I'm Head of Technical Marketing at Isovalent, which is a surveillance company specialized in Kubernetes Data Plane network security and observability.

In addition to my technical background, I also have experience as a sales engineer.

Here’s what I'm going to talk about:

Let’s go ahead and dive in.👇

The challenge of marketing to developers

The best way for people to experience the true value of your software is by doing. Developers are increasingly important in making decisions on software purchases, but it's challenging to market to them. Why's that?

Traditional marketing isn’t the way to go

The main thing about developers is they are tech-heavy. They prefer to have an actual understanding of the technology they're about to purchase or use, so you can’t just give them a few words and sentences and say, “well, this is nice, please buy it”.

Developers often have a negative attitude towards typical sales methods, such as presentations, marketing videos, and advertisements. A lot of developers actually run ad-blockers on their systems, so you can't even reach them with ads. It's hard to reach them with traditional methods.

At the same time, they're very critical about data and numbers. If you show them a study about how what you’re offering them is five times faster than your competitors' product, developers might take you up on this data and do a proof-of-concept to have hands-on experience of that increase.

Marketing to developers is hard, but it gets harder in a hybrid world

There’s a new normal, making it even more difficult to market to developers.

Before the pandemic hit, we had conferences, workshops, meetups, and meetings, so you were in a place with people and could read the room to see if they were buying in.

At the same time, you could walk up to them and start talking to them. Now, we’re moving to a hybrid world and finding ways to connect and market in a remote way and through remote sessions is hard.

However, there's one small advantage here. In the past, we had customers who couldn't be reached at all. For example, I was working with governmental customers who didn’t have internet access for security reasons.

This changed, coming into a more hybrid world; everyone now is allowed to go on the internet with browsers and have remote sessions.

developer working remotely on his computer

Remote sessions are still challenging in themselves. The biggest challenge is webinar fatigue. There are too many webinars out there and, because of this, people lose attention quickly. It's not only the sales webinars, but also the internal conference calls.

Some companies are planning to introduce ‘conference-free or call-free’ days, which would be one day where you’re not allowed to have any web calls.

As marketeers, we have the additional challenge to make sessions interesting while at the same time not being able to see what's going on because the developers turn off the camera.

I can talk for 15 minutes and have no idea if anyone's listening, if they’re even there or what their reaction is, because usually there's only very few people interacting or asking questions.

Again, when you have developers in the room, it gets even harder because they're not keen to look at slides or talk to salespeople or marketing people at all.

What should we be doing as developer marketers?

Give up traditional selling!

Let's stop selling. Don't do webinars anymore. The setup of one too many webinars, where you have a lot of developers on the other side and just hope they're listening to you, is not an efficient usage of your time as a marketer or a salesperson.

More importantly, it's not an efficient use of the developer’s time. They want to be appreciated, so we should stop this approach because there’s no interaction there. No interaction means you lose. What we need is a constant interaction and engagement during our sessions.

Get developers engaged

You need to tell a story and make the developers live that story. You need to guide them through the steps of discovery and achievement, a little bit like gamification.

Your content should take developers through the story in a fun and engaging way and, as a side effect, they’ll go through your product and see its great features.

On the other side, you also need to package it the right way. As mentioned earlier, one too many webinars is not the right packaging. What you need is something developers like to consume (and they don’t like to consume a presentation about a product and the pricing).

What they like to consume is something about features and certain use cases.

Essentially, your content needs to be structured and packaged in the right way and be consumable upon request. Developers are very busy people with a lot on their plate, so your content should be available to them with just the click of a button and consumable when they have the time.

Interaction and engagement in this format means one thing: hands off. It means exploring the actual code and seeing the actual programme. Seeing is believing.

Different approaches from my own experience

How-to Guides

My journey started with how-tos. I've written a lot of how-tos mostly on my blog posts, but also for profit companies, which is an extension to the documentation.

This works; you tell people what you do and you can even do it in a story format. But first and foremost, this requires a lot of doing from the customer side, before they even start with your product, installing VMs, and so on. Some people can't do this on their company laptops and they don't want to invest this time.

As the marketing person, you have no idea if this is actually used and if people are actually running through the test. Worst case scenario, after half a year, you run through this how-to again and realize the very first download link has been broken for half a year and no one ever told you.

How-to guides are the easiest but they're also the trickiest to pull off without any insight.

Creating a hand-sewn environment

The next step, and I did this a lot in the past, is where you start writing the entire thing yourself. You create a hand-sewn environment, where you can spin up labs for people whenever they need it. We’ve deployed environments in AWS.

This was working in a way, but we spent a lot of time just maintaining the entire thing. Features like progress tracking or feedback forms are things in which you have to put in more work and more maintenance, before you write the first line of product content.

At times, I was investing up to 50-60% of my time just dedicated to maintenance, and this wasn't a good use of my time.

I took this project over, joined it and then enlarged it. At some point, I was wondering who was paying for all these AWS machines. In the end, I reached this person who let me know I was consuming all this money.

Then, I realized, at that moment, that I had spent my marketing budget for the next 10 years and I had to write a very funny email that night to my manager saying we do have a problem.

So, it's not only about the maintenance of your code and the entire environment, it's also maintaining the resources, the money and the billing. In the end, you become a software vendor for hands-on lab environments, without even writing a single line of product content.

The winning approach

In the end, the best approach we found was to take a service, which has this already laid out, where we jump in and, right from the start, only write about our product.

All the feedback forms, progress tracking, how to set up the environment and billing, is left with people who do this as their daily job. Since they sell it to others, it's shared costs for us and, therefore, not that expensive.

Our most favorite lab is Cilium, which is the intro lab to the entire technology we have. It gives a little bit of introduction, but if you scroll down it goes into the actual challenges.

The challenges are the steps of discovery and achievement. Each challenge introduces a certain piece of the entire story, shows it to the developers or to the technical folks, gives them some tasks to do, and then they come to the next challenge.

The interesting piece here is also that, within each challenge, I can even see if they started it or if they stopped it, so I get a lot of insight.

There’s always a drop off within one challenge and, here, I see there's a lot of drop off at the very first challenge, so I might want to dig into this. This information is useful because it can help you identify bugs.

In the challenge itself, I have the data I provide to my technical people but I can also provide the actual technology. This is done in tabs. I define tabs people can work in and a tab is not only a command line interface, it can be a webpage or a program working there on the machines.

I can have many of these tips so I'm not bound to only one way of how these orders are consumed, but I can present a whole environment to my customers (developers).

Regarding the feedback, when you write a how-to, you’re getting no feedback, when you write the entire environment yourself, you can bring in feedback forms but it's pretty hard. Here, it's all embedded. I can even see how many people give feedback and on what level. I can't reach out to them, but at least I see.

As a technical person, I'd like to add one thing. If I'm done with something as a user/developer, when I want to go to the next challenge, I click on the ‘Check’ button which verifies that everything is working. If the developers, or the people consuming their marketing content, make a mistake, they can get help right away.

However… there are limits to this approach

I mentioned billing earlier, where, in the past, we suddenly had a huge bill. If you hand this out to developers, they can start it by themselves and they can consume it a lot.

Of course it costs money but using Instruqt helps me because it can define a lot of limits. For example, I can only send it to a certain developer and tell this developer they can only play it a couple of times, or it expires and so on. In this way, I'm protected but I have to keep an eye on it.

On the other hand, in terms of the marketing approach in general, there's a catch. When you follow this, you hand over the marketing purchase journey to the developers.

They're in the driver's seat. This is sometimes hard for salespeople because they’re used to driving it on their own and to be in control. With my sales past, I'd say this feeling of control was an illusion to begin with.

But nevertheless, this is something new for them and you’ve got to enable them in this.

Key takeaways

These are the three takeaways on how to reach and engage with developers successfully:

Don't sell, don't market, but educate and inspire developers.
Developers love hands-on product experience. Get them hands-on with the products.
Storytelling is essential; you have to give devs the context and they need to understand how they can best apply it in real-life situations.

Join our Slack channel to network with other developer marketers, check out job opportunities, and more.