The science behind feedback gathering from developers

Okay, so science is maybe not the first word that comes to mind when we think of marketing. Good marketers are known for creativity, curiosity, and caring for consumer needs. But it certainly is something we think of when we think of developers.

In past DevMar articles, we’ve discussed the importance of marketers getting into that headspace of a developer. That’s our ultimate goal, to bridge the gap between the marketer and the developer so that we can effectively speak the same – or at least a similar– language.

And since we’re still not going to be getting that computer science degree anytime soon, we need our evangelists and allies on the dev side.

That's why in this article, we’re going to look at the soft science of feedback benefits, whereas in the latter half, we’re going to look at the harder science of gathering and actioning feedback.💪

Main talking points

Why gather feedback?

When we think of science, we tend to think of something very technical and uncompromising. Funnily enough, this is a pretty accurate description for the dev persona. With product messaging, they like hard Cs: concise, concrete, condensed information that tells them what a product or feature does immediately.

On the other hand, when we think of marketers, it’s probably softer Cs that come to mind: creativity, compassion, care for the needs of the consumer. So, when we’re thinking about feedback as a science, it might be better to refer to the science of psychology

Like marketing, psychology is an ever-changing discipline that evolves in line with the needs of society. When it comes to marketing to devs, we’re still figuring it out. And that’s ok!

In an article in Psychology Today, Dr Gwendoline Seidman emphasizes the well-established psychological principle that people tend to respond better to people that speak like them. Not just that…

“The less information we have about a person, the more actual similarity affects liking. In studies where people just read about a stranger and don't actually meet them, finding out they have a lot in common with the stranger greatly boosts liking.”

So, let’s extend this to the role of developer marketers. Picture the scene. A busy software developer gets an email in their inbox from someone they’ve never met, and they have no knowledge of. Annoying, right? Especially when this particular dev has a busy workload and deadlines to meet.

But let’s take it a step further, this person that they’ve never met is speaking a language they actively dislike: the language of marketing.

How this translates to marketing

If we want to extend this principle to the world of marketing, and how it’s looking in the modern world. In a report from Business Insider last year, McDonald’s Chief Marketing Officer, Morgan Flatley said this about marketing to younger people:

"How they engage with media is different… They're very reliant on social media. They’re very reliant on friends”

Why is this so crucial when dealing with developers? Well, because, the vast majority of the time, when dealing with developers, you’re going to be dealing with younger people.

And creating a sense of familiarity is even more crucial than with other Gen Zers. For devs, marketing speak is the polar opposite of familiarity, of an interaction with a friend. In other words, this is not someone who wants to help you. This is someone who wants to use you.

Your written messaging, like speech, has a cadence and tone that either compels or repels. And when messaging about a new feature, or requesting feedback from an existing developer customer, it helps to keep the developer phrasebook handy. Concise, concrete, condensed.

Developers like simplicity, they are problem-solvers. They also like purpose-driven information.

Of course, as marketers, this is something we would hope to emulate ourselves as best we can over time. But since we want results now, what better way than to capture the voice of the developer through feedback?

So, now that we’ve established the why, let’s look at some specific benefits of feedback in the developer marketer community.

The benefit of feedback: defining the user’s needs

Ironically, the qualities that divide a marketer from a developer are the qualities that will enable a marketer to get into the head of a developer. In other words, good marketers are good psychologists. They use soft skills, such as empathy and curiosity, to try to understand the needs of the user.

So, Marketing 101 time! A simple concise message works because it clearly states the use case of the product immediately. But you can’t establish a clear use case unless you understand what the needs of the user are. And you can’t gain insight into someone's needs without feedback.

If you can gather even one or two pain points, it might make all the difference when putting your messaging together.

Let’s look at two specific pain points and explore how gathering feedback could address them.

1.Devs are often overwhelmed by the speed at which their industry moves

As a result, they often worry that they’re falling behind with modern tech and they don’t have time to adjust to new tech.

Solution: Put in a line about how user-friendly your project management software is, how quick it is to install, how there’s a step by step tutorial on installation. The thing about devs is, they like to try before they buy, so if you’re offering a quick tutorial based on that feedback, a developer is much more likely to engage with you

And here’ one that I found myself from a dev community online:

2. Devs are often overwhelmed by a crazy workload.

As a result, they have a hard time keeping track of their work and their deadlines

Solution: Well, the first one is maybe to be mindful that devs might not be likely to respond well to bombardment of emails. Here’s another neat little nugget about developers: They hate spam. Even on a good day, a developer is likely to ignore all non-essential emails.

Just looking online and understanding just how busy they are can make you more sensitive to that in your first contact. Maybe even a line about how your software will allow busy devs to keep track of their workflow, for example, could make them more likely to respond.

This level of attention to the needs of a user again links in to a basic psychological principle that you really don’t have to be Sigmund Freud to understand:

We respond better when a person appears to be attentive to our needs. Now let’s extend that to marketing again: users respond better when the product speaks directly to their needs. Gathering feedback and insight sets a precedent for a healthy relationship. We’re sending the message that we care about customer needs, and we want to actively engage them in the product.

The benefit of feedback: it allows us to act

And, most importantly, it allows us to act on improving features. We need to walk the walk as well as talk the talk. But without a continuous feedback loop, we’re not keeping up to date with the evolving needs of the consumer.

In a world that moves at the kind of break-neck speed that tech does, it’s absolutely essential our feedback evolves with the software. Your messaging might really talk the talk, but does the product itself walk the walk?

Benefit of feedback: it creates authenticity

A developer’s dislike for this language goes deeper than this psychological principle. For marketers, we’re entering an age where consumer cynicism is at an all-time high. The latest Gustavson Brand trust study found that trust had declined in almost all brands.

“While trust in key institutions has been eroding significantly over the past few years, the average brand trust scores for all brands surveyed in 2020 are at an all-time low. And it’s making consumers more conscious about what they buy and from whom.”

Pretty scary stuff, eh? This lack of trust is linked to consumers being more cynical than ever before, and developers are even more cynical than your average consumer. So, what is the appeal of concise messaging? It seems authentic.

If you’re writing a piece of copy to a developer, your messaging needs to be as cast-iron authentic as a hard science. But nothing is going to make you sound more authentic than gathering some quality feedback.

Devs like authenticity

So, think of those first times spent in online dev communities as a kind of vacation. You’re not gonna come back with all the jargon, but you might pick up just a trace of an accent.

And that trace of an accent, especially if the message is brief, might be the difference between the dev ignoring you or clicking on that email, especially if referring to specific processes and software that the developer might use.

As someone who’s in the know, you’re more likely to offer them something they can use. Still, it doesn’t matter how authentic you train yourself to sound. Nothing is going to be a substitute for the testimonial of a dev themselves speaking about your product.

Our ultimate goal is to create a continuous feedback loop. Developers are community-focused. They trust those within their own community, and they thrive off interaction with those who are fluent in developer-ese.

As a result of this, a whole active community of heroes offering continuous feedback is an achievable outcome. Currently, marketing to developers is uncharted terrain. If we’re going to dip a toe into these murky waters, we’re going need all the heroes and allies from the dev community on our side.

So, without further delay, let’s send in the cavalry! 🏇

Create a developer experience index

I know what you're thinking, collecting feedback is so hard! I hear you! And for busy, distracted people like devs, it can be even harder.

Sure, you can send out survey monkeys via email, and these can provide quality insight, but as we’ve established, most devs are unlikely to respond to this. Luckily, we have some practical solutions that can really appeal to that dev sensibility.

The developer experience index is a system designed by the company TomTom. It’s a set of metrics designed to measure the developer experience. It’s split up into five stages, each one covering a different point in the user adoption journey for developers. Now, the great thing about this is that it’s all gathered in one dashboard.

Here's what Anna Borbotko, Product Marketing Manager at TomTom, had to say about it:

The DXI is just effortless for developers...it's also consistent. You can easily compile or compare data together.

It might seem like a silly problem, but sometimes you can simply have too much information.

And although it might be tempting to make your office look like some corporate stock image, ( you know the kind, with notice boards covered in multi-colored post its. We all high five each other over Chai Lattes.) the reality is, that feedback isn’t doing anything unless you can seek it out in one place, order it, and action it

So, let’s break down the five stages.

Discovery

You know the hardest step is always getting your foot in the door, right? And for the developer marketing, that door is pretty stiff! So, this is where your marketing team is gonna be doing a lot of heavy lifting! Devs are going to be asking, “Do I want to use this? Do I need this? Will it help me solve my problem?”

So, we’d better have a pretty solid use case to answer these questions. This is what we assess at this stage. Did the marketer accurately address your needs? Why not?

Onboarding

Okay, so we’re through the door, but now the dev is going to be asking, “what do I know now?” Again, for everyone at the back, devs are busy. So, you better have an answer quickly. At this stage in the index you’re assessing how well your org was able to quickly– and hopefully painlessly– get the customer adjusted to your software.

Documentation

We all know the story, you start with a company, and everyone’s all smiles, but as soon as they’ve got you through the door, they leave you to drown. This is really the sticky phase, where if you’re able to answer dev questions accurately, you’re going to have a much higher chance of keeping them.

It’s likely now, since the dev is going to be looking at how to implement this tech into their day to day work life, that they’re going to start unloading with the more tech questions. “How do I use APIs. How do I ensure that what I implement is implemented well?”

This is the chance for you to assess whether your marketing team, or your customer success people, or whoever it is you have working on this stage, has really done their research into this field.

Support

Just because devs like their information hard and concise, it doesn’t mean they’re immune to soft skills. Here, you’ll be assessing how attentive your people are being to the day to day implementation struggles with the dev. Does the dev feel like they’ve had someone to turn to when they’re struggling?

Loyalty

Have you managed to create a fully fledged evangelist? This is where you assess whether this whole process has made the dev a champion for your product.

This is the “how likely would you be to recommend..” step, and it might be the most crucial of all. We want to get to the stage where we don’t have to actively seek out feedback, it just flows in an effortless stream.

How does this data help?

So, for the benefit stage of this article, we looked at the softer science of feedback benefit, now we’re in more of a hard science territory. We’re looking at quantitative metrics such as, Net Promoter Score, customer satisfaction score, customer effort score.

But…

All of this means nothing without qualitative information. We’re looking at developer comments, and here having a sentiment analysis of those common trends is really handy. What are the specific pain points devs are experiencing when implementing this?

This process appeals to devs because it's really in sync with dev sensibilities. Tomtom built this in such a way that the feedback process was seamlessly built into the user’s day to day interaction with the software. This had a variety of benefits.

It’s effortless

A rating solicitation is triggered when the user engages with specific mechanics within the software. You’re not taking the dev out of their busy schedule, which is likely to build a better relationship, and you’re more likely to get a response.

TomTom also implements a dropdown text field, which is optional. This is your qualitative data. Devs value humbleness, which is why a hardline approach won’t work. You’re more likely to get them to go the extra mile for you if you show that you respect their time. Make the qualitative side optional.

It happens in real time

Developers can give this feedback as they’re actively building their products.

You know how it is, after a busy day, you forget all the little gripes along the way. This real time response allows a more comprehensive insight on developer pain points. They can react immediately and you can get more insights on the day-to-day struggles customers are having with your product.

It’s a pull rather than push approach

Users are not being forced to give you feedback. We’re not treating them like little kids that have to be pushed into doing something. Devs are highly intelligent folks and they expect to be treated that way. You’re showing that you trust them to voice their opinion in their own time.

But how do we collect this insight?

At TomTom these metrics were built into the developer portal. This is how the system is seamlessly integrated into the developer’s work day. Giving feedback isn’t a pain, it’s just part of the process

On this portal page, for example, devs can either give a thumbs up or thumbs down to indicate whether they’re being able to access the things they want. Again, these metrics are being collected in real time, so we’re getting a really accurate insight into the day to day struggle.

There’s also a drop down text field. Again, this is optional, but it’s appealing for devs since it allows them to be very specific about their issues. Devs, above all else, are specific people. They don’t like fluffy, filler talk.

Where does this information live?

It’s all about storing the feedback in a centralized location so that everybody can access it at any time. In this way, everybody is in alignment with what feedback needs to be actioned. You can't build roadmaps for future improvement unless everybody is in agreement on what the map should look like and what tools will be implemented, etc.

If you’re building a road but everyone has a different idea about what it should like, you’re road is gonna look a bit like this 👇

Some more practical tips from devs

In the past, organizations have tried and failed to engage with developers for a whole variety of reasons. The primary reason for this is that marketers have treated devs like your average consumer.

They’ve tried to coax devs to action with rewards and gift cards for example. But devs are generally unimpressed by this. So, how can we overcome this issue?

Well firstly you can spend some time in online communities, but an even better route is to ask your own in-house developers what would appeal to them. Here are some of the solutions that have been devised from this kind of feedback.

Single click emails

As well as integrating this system into their software, TomTom also implemented a single-click star rating response into their emails. Developers were able to give feedback in seconds and this became a really great source of quantitative data.

Imagine if devs are able to provide feedback in the short space of time that it takes for an email notification to appear and disappear on their screen. They don’t even have to click off the page that they’re working on to respond.

Mandatory fields are a no-go

Devs want you to be respectful of their time and their intelligence. Don’t patronize them with mandatory fields. An optional text field is far more respectful and humble. This is a quality that devs really appreciate.

Avoid marketing spiel in emails

We’ve talked already about avoiding marketing-speak in your messaging to devs. We’ve talked about embracing concision. It’s also important to be human. As we’ve already said, devs value authenticity. Be honest about the fact that you’re looking for their help in order to improve your product.

Be transparent.

The holy grail: A developer community!

Once you’ve got enough devs on your side, it's time to evangelize! This is when your developer community comes in. You can create this using external sources such as StackOverflow, Reddit and GitHub.

As we said devs are community-focused and they would much rather discuss their issues with other devs in a forum rather than through email. This just takes so much pressure off your team because your army of champions are addressing the concerns of other developers in a language they appreciate and understand.

They’re alleviating any concerns newbie devs are having about using your products. And, most importantly, newbie customers are seeing that there are devs out there that are already believers in your product.

This is ultimately how you will create trust in your brand. And this is truly the holy grail! 🏆

Psst.. Want to network with other developer marketers? Join our slack community!