This article derives from a presentation from the Developer Marketing Summit, from July 2021. Watch this presentation, and others, via our OnDemand service.

My name's Anna Borbotko, and I'm the Product Marketing Manager at TomTom.

I'm going to share our Mission Possible: the science behind gathering feedback from developers, specifically on such products as APIs and SDKs.

Truly understanding developers have, for some reason, always been a challenge, especially for those who come from business backgrounds.

In this article, I’ll focus on:

Developers vs average humans

Here’s another question for you: How different is a developer from an average human being? Let’s look at some of their core traits, then you can decide.

Firstly, developers love simplicity. They deal with complex algorithms in their jobs, and they love solving problems, but in normal life, they want everything to be as simple as possible.

Now, if you look at the average human, our brains are wired for simplicity, as shown in research by Daniel Kahneman, author of Thinking Fast, Thinking Slow.

Another major characteristic of developers is having a sense of purpose and wanting to know that whatever they do has an impact. The topic of purposeful living took off about seven years ago and is still a hot topic for many of us, including developers.

I remember when I was working for a startup that built software for the EdTech industry; we wanted to help overcome the shortage of teachers with technology.

During lunch breaks, developers would often share how recruiters from big companies and banks had approached them and offered to triple their current salaries, but no amount of money would make them switch if they didn't see the purpose behind the role.

The next item on my list is that developers really don't like spam. I don't need to tell you that most developers have ad blockers, but they also ignore cold marketing, cold sales emails, and almost everything that's not relevant to them. If you look at most non-developers, they’ll also get pretty annoyed by this kind of spam.

Lastly, developers like to test things before they buy, and the same applies to us. If we buy shoes, we try them on first. Or, if they were shipped to our house and didn't meet our expectations, we return them.

So, the question is are developers that different from us? My answer is no. We’re all human, after all, so how can we use that knowledge to gather feedback from developers? Let me walk you through it.

But first, some context

I'm a product marketing expert at TomTom, a location technology provider. The project I'm working on right now focuses on gathering feedback in B2D and B2B environments in a way that’s scalable and accessible to all relevant stakeholders.

TomTom has changed over the last few years. It has transformed from a personal navigation device company into a giant that now competes with the likes of Google.

TomTom now has a diverse product portfolio. Its products have a range of different use cases, and they fit differently in different markets. We’ve got APIs, SDKs, and even map data.

We in the PMM team are working on our messaging and positioning and go-to-market strategies, and for that, we need input from customers.

On the other side of the table, we have product managers who are constantly asking for feedback and using that information to improve our products or even build new ones. Both functions constantly require access to some information from customers, which can be a challenge.

In many organizations, you have a dedicated customer success team constantly working on feedback activities, and if you don't have that, a PMM will typically take over that role – that's the case at TomTom. We don't have a dedicated customer success team.

We also don't have a user-facing application because we work in a B2D and B2B environment, so we can't really go behind the scenes to monitor the behavior of our users. All we have is our sales teams, customer support, and developer portal.

Customer feedback is available all over the place. We have internal teams constantly collecting information.

We have external sources like social media and different analytical tools. I could go on. The problem is not that we’re disorganized; it’s just that there are so many different channels that it makes our feedback tricky to analyze.

If you work in a high-tech company, the chances are that the majority of your colleagues are developers.

That’s certainly the case at TomTom, so we decided to check what they would advise us to do if we wanted to collect feedback from developers. We also spoke to business teams and product managers to see what their feedback requirements would be.

We gleaned many insights from those conversations, but one thing I really would like to highlight – and it's not rocket science – is that asking for feedback is one thing, but if you ask for it, you have to act on it.

Of course, it depends on the quality and quantity of the feedback but, generally speaking, feedback means responsibility.

If nothing happens for a while in response to feedback, people don't see the point of sharing it with you anymore, and this makes gathering feedback even more complicated.

The three-step approach to developers’ insights

Based on what we learned from our conversations with developers and other stakeholders, we came up with a three-step approach to feedback-gathering activities at TomTom.

  1. The first thing you need is a developer experience index (DXI). This is a set of metrics that are measured and analyzed regularly.
  2. Secondly, you need to establish a conversation with developers through actions.
  3. Lastly, you need to build a learning community, and that can be internal, external, or both.

Step one: The developer experience index

Let's start with step number one – the developer experience index or DXI. We didn't take this from a big consultant’s report or a clever book – it’s purely a TomTom improvisation. We're still refining it at the moment, so we don't yet have all the insights about how well it works, but bear with me.

We’ve broken our DXI metrics down across the five stages of the developer journey.

First is the discovery stage, which is related to everything your marketing teams are working hard on. This is where you’re answering questions like do I want to use this? Do I need this? And will it help me solve my problem?

The next stage that a developer will probably go through is onboarding. This is when they’ve decided that your product will probably work for them and they need you to help them get started.

The third stage, which is crucial for developers, is documentation. That's the stage that answers questions like how do I use these APIs? How do I ensure that what I will implement in my product is implemented well? If I struggle, how can I get help? And that's where our fourth stage, support, plays a big role too.

Our final stage, assuming the developer sticks with your company, is loyalty. You want to measure their loyalty to your brand and products.

Across the different stages of the developer journey, we collect quantitative metrics, such as net promoter score, customer satisfaction score, and customer effort score.

However, those metrics mean nothing unless they're supported by qualitative information, such as developer comments. That's where sentiment analysis comes in handy.