Get into the developer mindset

My name is Liz Moy, I’m an Enterprise Developer Evangelist at Twilio, which is a cloud communications and customer engagement company.

I come from a marketing background and ended up going to a coding bootcamp, then worked as a software engineer for several years before transitioning into developer relations.

In this article, I’ll talk about how to get into the developer mindset, something that's helped me so much throughout my career to better communicate with developers.

Here are our main talking points:

Questions to get into the mindset
Framework for developer touchpoints
Tactics to find answers

Let’s dive in. 🧠

🚫 Don’t assume 🚫

Don't make assumptions.

Even as somebody who was a full-time software engineer and a full-time developer, I still find myself making assumptions about the type of documentation developers want to see or a particular programming language they probably want to hear about.

I'm in dangerous territory, if that starts to happen.

We should always be not only listening to the community, but also looking at the data that's coming in, and use that to decide how we want to craft a message and things developers can use.

The 5 ‘W’ questions that’ll get you into the developer mindset

#1 Who?

The first question is who. In the context of the developer community, we want to think about not only who they are as individuals, but the types of things they might like or the types of messages they might respond well to.

There are now a lot of people who use technology and code to do their jobs who might not always have the title of developer, such as business analysts and product managers who know how to make things with code or are using a low code tool.

#2 What?

‘What’ is all about what developers need to be successful and how we can create experiences and messages that resonate with what they need.

#3 When?

Think of 'when' from the perspective of when in the life cycle a developer is going to use your product.

For some developers, it might be that their manager approached them about finding a new database solution. For others, it could be that they just want to build a fun app using an API they've been curious about.

They're all valid experiences for someone to be approaching and trying out your technology, but having different forms of content and ideas of when they're going to be coming into that journey can be really useful to you.

#4 Where?

I think about 'where' from two different standpoints:

Geographically (regionally, the physical where) and what restrictions might exist.
Where in someone's programming or development journey, because the types of content you're gonna have for a beginner or someone experienced are going to be quite different. It's empowering to be able to segment that out and approach them in a way that makes sense for them and also not turn someone off by either giving them something they're not interested in, or that feels a little bit too out of their depth.

#5 Why?

The ‘why’ is the most important, because if we don't know why we're doing something, it's easy to lose sight of the entire purpose of it. From a marketing standpoint, we want to think about why developers are using the product.

It could be something that's very business oriented and about saving lots of money, but it could also be about giving people time back with their families and with their friends by switching over or automating this process.

Being able to tap into that emotional why can be a great tool to have in your toolbox.

Framework for developer touchpoints

With frameworks to consider, as you're thinking about how you want to structure your developer marketing strategy, there's outbound and inbound strategy.

⬆️ Outbound: research, evangelism and sales

Outbound strategy is around research. This could be research you conduct yourself or research you find elsewhere about what the developer community is focusing on (i.e., what the trends are, technologies or programming languages developers are using most frequently in the upcoming year at the current time).

There's also evangelism, which I definitely think of as an outbound motion because it’s going out into the developer communities (whether that’s going to a conference or a meetup, or even into a customer company or a potential customer company) to meet developers where they are and tell them more about your product and enable them to get started with it.

Sales is also an outbound motion, because sales has such a direct line into customers (if your organization is at a certain scale). It can be an area your teams can rely on to get an idea of what developers need and what they're doing.

⬇️ Inbound: advocacy, content and community

Inbound strategy is outside factors and data coming into you. We can think of advocacy, content and community as examples of inbound strategy.

Advocacy and evangelism are sometimes very interchangeable. You're taking all of the feedback and insight from the developer community, and you're bringing that back into the organization. Then, you're advocating for those developers by asking for a better command line interface, or more documentation around a particular product.

Content, which is huge, is also part of the inbound strategy. Whether it's a podcast, a blog, or videos, content strategy is essential.

The last piece of inbound is community. Community can be a place where developers can connect with each other. It can be a community you host yourselves or something you tap into.

Giving developers a place where they can share their feedback and can use this feedback for your own insights is an incredibly powerful notion.

Tactics to find answers

Let’s dive a bit more into the actual tactics you can use from each of the 5 ‘W’ questions you're going through as you’re thinking about how you want to connect with these developers.

Who?

The strategy I tie closest to ‘who’ is the research piece. I love sending out surveys before I host a hackathon or an event to find out what developers want to use (products or programming languages, for example).

We use NPS (Net Promoter Score) as a metric where we ask people on a scale of one to 10 how likely they would be to recommend this to a friend or colleague. On the other hand, qualitative feedback also has great insights. Surveys are a fast and easy way to get a pulse on the developer community.

Putting together a CRM of your developer community can be a useful tool. If you can gather data about your developers at meetups, conferences, or hackathons by contacting them after the fact, it can be a great opportunity to send out a survey paired with an incentive to get feedback from the community themselves on what it is that they want to see.

If you're in a startup or a small company without a fully fledged developer marketing organization or DevRel organization, find a developer or software engineer that knows your product really well and ask them for feedback; also use them as a soundboard for your marketing strategy.

Partnerships are also a strength so partner with the product team to bake a survey into the signup so, if somebody's signing up to try your product, try to get a little bit of information about them, just so that you'll have that on the back end to be able to use to your advantage.

What?

This is where most of the tactical things come into play. The most immediate tactics you want to start thinking about are documentation, because if someone doesn't know how to use your product and they can't do it easily, you're gonna lose them instantly.

Working with a docs or a DevRel team on documentation to figure out how you can cross promote and utilize it in other areas is going to be an immensely helpful step one.

You definitely want to have swag. If you have a quality product, whether it's a water bottle or a t-shirt, people remember that and it reflects well on the brand. Another thing you can pair that with is a free trial of the product.

A big tactic my team focuses on is hackathons for customer companies. It's a great opportunity for the developers at those companies to get their hands on the APIs, build out a prototype and actually see what it's like to try it out.

The main focus is making sure everything's ready for the day of the hackathon, they can log into the console, they've got credits, and there are helpers on hand to back them up and give them assistance.

Another way to find out what developers need is looking at the metrics, looking at the inbound of how they're coming in and what content they're consuming as they're coming to your product.

As much as developers want to see things directly about your product, they also have needs outside of just that. They want to hear about a new framework, a new technology or an integration between your technology and another technology so tapping into those types of ideas, and finding a way to highlight them, especially from a search perspective, can be a really great angle to go from.

When?

Everybody is coming at your product from a different angle and you may not always be able to determine the ‘when’.

However, this is a great time to tap into developer evangelists and also sales or solutions engineers in your organization because they’re the ones actually meeting the developers day in and day out, and seeing the use cases and the business challenges of what they're using your product for.

They'll have a wide variety of experiences to draw from, and can even show you some demos of the use cases they have to show off on a regular basis. Try to become friends with these people or even just set up a round table with them and just draw insights from what they're seeing.

Where?

There is so much insight into the ‘where’ but it can also be challenging sometimes. Nowadays, we have people that have been working in technology and coding for decades, and we have people that have just opened a code editor for the first time and are taking a step toward this new career.

Being intentional about how you're approaching developers on whether your initiative is geared more toward a coding newbie or an experienced software architect can be very effective.

Why?

‘Why’ is about listening and tapping into the community. This can look like attending a meetup and listening to the things developers are sharing, looking at the forums, seeing what's coming up and how people are mentioning your product, etc.

Consider developers who have feedback that might not be as positive, and think about maybe escalating up the chain. If your organization does have an advocacy group, and they're likely already doing that type of work, that's a really great way to partner with them, and to also make the developers feel heard and like you are paying attention to what they need.

💡 Key takeaways

We've gone over the who, the what, the when, the where, and the why of how you want to approach a developer.

There are outbound strategies that help you reach out to developers and these are the ones you use when you want to have an idea of what they're seeing in the developer community.

Then, for influencing what comes in, advocacy, content and community are where you're going to want to put your focus on. This helps you figure out what you can do internally to give developers what they're looking for and connect with them.

If you take the time to pay attention to what developers are doing, and act accordingly, you're going to have a marketing strategy that feels relevant to developers and are going to make them want to use your product.

Join our growing Slack community to connect with other like-minded pros like yourself or contribute your expertise to the Developer Marketing Alliance!