Gregory De Jans Details How TomTom’s Developer Engagement Strategy Helped it Pivot to a B2B Company

Gregory De Jans, TomTomGregory De Jans, TomTom

In today’s business climate, the need for companies to be agile, innovative and able to scale is greater than ever. These needs are driven by an increasing demand for connected experiences and APIs are key enablers. But before an organization can reap the benefits of APIs, it must set up an API strategy.

Developing an API strategy can be broken down into four stages: establishing your business strategy, aligning your organization and culture, installing the technology needed to support the strategy and engaging with your ecosystem. This series of articles examines the fourth stage.

All successful API providers make it a priority to actively engage with their developer communities. Doing so helps build vibrant ecosystems of developers and partners who, in turn, can extend the reach and success of those API strategies. ProgrammableWeb has spoken to a number of providers about their best practices for engaging with developers. This article will focus on TomTom, a provider of location technology services. We spoke with TomTom’s head of Developer Portal Gregory De Jans.

TomTom was long known as a company that built navigation devices for use in cars. But in the last several years, the company made the switch to a software provider focused more on the B2B market. With that shift, TomTom reinvented its marketing and engagement efforts to take aim at developers instead of consumers in the general public. De Jans discussed how his team was able to not only change its strategy, but also overcome the stigma that developers cannot be marketed to. He talks about how the tactics that work for a consumer audience don’t necessarily work for a developer audience and points out that conversion metrics need to change, even if the end results may be similar.

Offering robust forms of support is one of the best ways to ensure great engagement with your developer audience and De Jans outlined some strategies. Over the years TomTom has learned that any support they offer needs to be backed up by its professionals. For example, forums should be monitored by experts instead of relying on the community alone, for example. 

TomTom also recognized how different audiences that come to learn about its products may have different priorities. De Jans explained that TomTom made the choice to feature SDKs as equal to its APIs due to the different developer personas that visit the portal. In recognizing its audiences’ different needs, TomTom has come to realize that it isn’t important to worry about whether to serve each with different web channels. Instead, it should focus on the user journey while making sure that the right content is served to the right developer at the right time.

To find out more about how TomTom approaches developer engagement, read the transcript of the interview below.This interview has been edited for clarity and length.

ProgrammableWeb: Yeah, Gregory. If you wanted to start, I'd love to hear just a little bit about you and maybe a little bit of your background and what you're doing at TomTom, and little bit about TomTom, for those who have not heard about...

Gregory De Jans: Okay, let's start with a bit of my background. I started working for TomTom in 2010. That's already 11 years ago, and I was mainly active for, let's say the first five to six years in supporting our larger customers, B2B customers in Europe, but also on the West coast. Specifically I have been involved in everything related to our API products. During that time, I was working with customers like Uber, Microsoft, who were using our technology and who wanted to learn more about APIs because it was quite a new product for TomTom. Then, after learning more about the APIs, eventually there was an opportunity to manage the developer relations team.

I had been closely involved with everything which relates to APIs. I was also in the sales and marketing organization, so that was kind of a natural next step for me to take. So, I managed the developer relations team. That included work on the developer portal that we now have at TomTom, our developer support activities to support our community, and our development engagement campaigns. Of course, we would work closely with our marketing department to execute those. To this day I am still fulfilling that role. I have been active in that role for about four years now. To give you a bit of background on TomTom. I think, of course, everyone knows TomTom from the early days when we had these very nice usable DMV or navigation devices as we called them.

I think oftentimes when you ask people if they know TomTom, they still remember those devices. Of course the world's moved on, and I think TomTom also moved on. Instead of being that hardware company that people know us for, we have transitioned over the past few years. That transition started around 2015 to move to being more of a software company. Of course, that not only meant a transition from hardware to software, but it also meant a transition from offline to online-first thinking. That requires a bit of a change in mindset as well, not only for the people who are selling the products, but also the people who are creating the products. You're moving from, let's say a navigation device, where all the technology was actually inside to an online world where you're offering services to B2B partners, who of course use all that technology and that knowledge that you have built up over the past more than 28 years.

I think it's important that, for the people who don't know what TomTom is, we're still that same company who's building great location technology but instead of exposing that for our own consumer devices, we're now exposing that through our partners who are then integrating our services. So we are kind of a B2B company. The nice thing that we see is that actually there's more people using TomTom technology today than there were for example, five years ago, but it's just not that visible anymore. For example, if you're using the Uber app on your iPhone, there's all TomTom location technology inside. But not as many people still recognize the brand because it's not that consumer brand than it was before.

PW: Okay. Let's talk about developer engagement, because one of the things you mentioned was you made a move from hardware to software and from offline to online. As you guys made that switch, how did the strategy for engaging developers have to change during that time period?

De Jans: Yeah, I think it not only had to change, it had to be completely reinvented. We were not used to talking towards developers, to marketing towards developers, to sell towards developers. I think it's a completely different skillset, and it's a completely different world if you're selling marketing to developers. You often hear it doesn't work if you market to developers, or it doesn't work if you want to sell something to a developer, but we learned that's actually not true. It's just a different way of marketing to developers and a different way of selling to developers.

I think something you really need to be aware of is that you're talking to a completely different audience and that audience comes with different tactics, different ways on how to approach them and how to engage with them. What works, or what used to work for a consumer audience, does not necessarily work for a developer audience. We had to build up a team with the right skill set, with the right knowledge, the right backgrounds, in order to support those developers, and to convince those developers to actually use our products. That is something I think we kind of understood pretty early in the process and what also made us successful.

PW: You said that there's a conception that you can't market to developers, but in fact you can. How do you do that? Even if it's top of the waves, what are some of the ways that one would actually go about marketing to a developer audience?

De Jans: Yeah. I think there's multiple options there to target through a developer audience. The traditional digital marketing executives are working with developers, but we do see differences. For example, if you're investing in Google advertisements on Google search, what you see is that developers are not really tempted to click on an advertisement, but it does stick in their minds. What happens is, they see the advertisements, they won't click on it, but perhaps the next day or two days later, they will try to find it themselves. Something that they have seen through some kind of a visual advertisement, for example. The conversion metrics that you had from, for example a consumer audience, are not necessarily the same as those conversion metrics for a developer audience, but you do see that they have an influence and that they worked, these kinds of advertisements. It's just that developers are not tempted to click right away on these advertisements. I think that's an interesting story worth sharing, that traditional marketing engagements might not have the same kind of conversion metrics, but in the end it might have the same results and you're able to reach your audience. 

Something else of course is you need to go where your developer audience is. We tried different channels. We tried LinkedIn, we tried Twitter, we tried Facebook. What we learned was that the channel that works best depends on the audience, of course. If you have, for example, a great B2B product, which is very consumer oriented or gaming oriented, then it might work if you do campaigns on Facebook. If you do these kinds of marketing activities for something like a maps API, we learned that Facebook is probably not the ideal way for us, and that there are other social media platforms, which are better for us in terms of engagement. So that's another thing. With social media, some platforms work better than others. 

Then the last part is there's also a lot of developers which are engaging and are trying to find support. Then of course you need to think, "Okay, do we make use of the existing support platforms like Stack Overflow and all the other platforms that you already have,” where people are actually trying to find an answer, or does it make more sense to build your own support group, for example, where you have a dedicated forum that helps developers find answers about your product?

We also did a couple of surveys and research to find out what will work best for us. It's not necessarily a given that this would also work for other companies, but by talking to our audience, we found out that they appreciate posts that have our own developers working to help them compared to sending them, for example, to Stack Overflow, where they kind of lose their way and they don't exactly know what tag that they should add to their questions.

So one important requirement that they had was, it needs to be backed up by TomTom professionals. If you only allow the community to exchange, then we might as well go to Stack Overflow. But if you're setting something up which is supported by TomTom professionals, then this would be a great added value for us. We see also in the engagement metrics that people really like the support that they get through the forum, that there are a lot of engagements happening there, and even developers who help them, who help each other out. But in most cases, I think they appreciate it if a TomTom expert can help them with answering the questions.

PW: That's interesting. You have that then on the developer portal, your internal tools, like your forum and questions like that?

De Jans: Yeah exactly. There are a couple of ways that we provide support. One is through the forum, but there are also developers who have perhaps more confidential information that they want to share or are working on a confidential project that they want to get information about. We still allow them to reach out to us directly so that they can get some personal interaction. 

What we see is if a developer has a question about how to integrate a specific feature on the iOS SDK, for example, then they are more likely to share that on a forum instead of sending a direct question to us. The advantage, of course, is that same question could help another developer as well. We encourage developers to share their questions on the forum, because from an engagement perspective, if other people have the same question it is helpful to be able to find the answers on the forum, instead of reaching out to us for every technical question that they have.

PW: Who in your team is providing that support that you've mentioned your customers really value?

De Jans: There are a couple of teams that are providing the actual support. If it's a purely technical question, then we have developers who are experts in integrating our SDKs and our APIs. The developer support is given by developers, and I think that's important that you allow developers to talk to developers because otherwise you will lose the connection with them and they will not feel they are understood. Then there are the more commercial related questions and a few questions about the terms and conditions or about our pricing model. For example, we might have people who don't necessarily want to pay with their credit card, but they're interested in signing a contract where they get the invoice, that type of situation is handed over to a sales team so that a sales representative is reaching out to them. If we were to allow the sales representative to also engage with developers to answer more technical questions, I'm sure that would not be very much appreciated by the developer community.

PW: So this is interesting because you’ve been talking about how you have the internal support on the portal. As we know, a great way to support developers who are new to your API is to offer SDKs. I actually covered the TomTom portal about a year ago. Something I highlighted were the SDKs and how you really treat SDKs as first-class citizens equal to the API. You don't always see that on a lot of developer sites. Can you speak to some of the choices that you made in the portals? Why have you chosen to feature SDKs on equal footing to the APIs? Talk about the portal a little bit. I'm very curious to hear about that.

De Jans: Yeah, of course. The portal has been quite a journey. In the beginning, I think the portal was just a way for people to understand how our products work. It was more like a gathering of all kinds of technical Documentation that we exposed, and of course we provided access to our APIs. The next step happened because we saw that people had a lot of interest in using our APIs commercially as part of their applications. What we found was that sending every developer to an account manager didn't really go well, and we didn't have enough account managers at that time to support all these questions. Then we started thinking about how to find a fully self-served way for people to evaluate our APIs, but also to commercially use our APIs.

I think this was in 2016, 2017. At that point we focused on making sure that we could provide a fully self-serve, automated way for people to get started with our APIs, without even having to contact a person at TomTom. The goal of course was to make it easier for people to get started, with our products. 

What we didn't really invest in before was building all kinds of awareness pages. Making sure that a non-developer, whether it was a CTO of a company, a product manager, really any product person could also understand how our products could benefit their use cases. We started adding product pages. We started adding use-case pages, industry pages so that people could relate to whether our APIs were fit for their use case or not. I think that's an important part in the awareness phase that you need to cover so that the non-developer audience understands what your products can do for them.

Then of course we have to think about our API documentation. Does it have the right structure? Does it contain all the rights components in order to serve the developers and can they find their way through the documentation? Although we are revamping it from time to time, we have made the choice that the SDKs are equally important to the APIs. That's because there are basically two types of developers. One type of developer is familiar with a specific technology and they look immediately for that technology. They want to know how to integrate that technology, for example, with the TomTom APIs, and that is true in SDK. If you are a JavaScript developer, then immediately you want to go to the JavaScript SDK. If you're an iOS developer, immediately you want to go to the iOS SDK.

Then there are the other types of developers who are more interested in the core functionality and they want to build something around the API that they can manage, that they can own. That is the developer, for example, who is more familiar with Python or with C/C++, and they are looking specifically for that API functionality. Those developers need access in a very fast and quick way, whether you're a JavaScript developer or whether you're a Python developer. That's why we decided to put the APIs and the SDKs on the same level, because they are serving different audiences. Those audiences will have a preference depending on the background and  programming experience that they have. But most often people know, before they even land on your portal, what technology they want to get access to and what technology they want to use.

PW: You said that there are different audiences, some who want to interface with the API directly and others that want to interface via the SDK. Even within that SDK audience, they are segmented. What was the journey to deciding to serve these audiences in different ways?

De Jans: I think something that we started focusing on as of 2017, 2018, was doing a lot of user research. That was something we hadn't really done before, but we started realizing that there's no such thing as a single developer audience, right? You're targeting specific developers from specific verticals, in our case that was developers who are interested in fleet and logistics applications and on demand mobility applications, where we know that we have a good product fit for those use cases. We started building some personas and it's important when you're building the personas that you know who your audience is and who you can target. Then of course you need to define their user journey. Each persona that you have identified needs to have a user journey for how they will find the information that they need, how they will integrate the products, and user research really helps with that.

There are a lot of online tools, but also by setting up some face-to-face user research projects, we've learned a lot and we actually saw how developers were interacting with our portal. We saw how they would get lost at some moment in time and where they perceived some friction. I think it's important then that you start prioritizing the most important friction points to solve them and to make sure that you have a better user journey, that you have a better user flow. Then of course, all this feedback from the user research phase is taken into account by what you call a UX designer, but we call it the DX designer, right? Because it's developer experience, which is a bit different than User Experience.

Then the DX designer takes all that information into account to create new user flows that would help to remove some of these friction points. It's a continuous exercise that you need to do. You can’t solve all the friction points in one go, it's an iterative process and you need to handle these friction points one by one to make sure that you have a user journey where developers don't get lost and where they don't perceive any friction when they want to get started with your products.

PW: So at the point where you’ve rolled out your portal and you’re happy with the documentation, how do you measure if you are successfully engaging with your developer communities?

De Jans: From a developer engagement perspective, I think that there are a lot of KPIs and a lot of metrics that you have. One of my favorite ones is the time to first API call. That basically means if somebody registers on our developer portal, after how much time does he execute his first API call. Well, we've seen that we've come a long way there. At the beginning it was a couple of days at minimum. Sometimes we saw that people, especially when there wasn’t a self-serve process, had to sign some kind of an evaluation agreement. Then we had to manually provide them access to the guides.

Those were the early days, but of course now it's a matter of hours, sometimes even minutes for developers to register on the portal and a couple of minutes later have already made their first API call. I think that's an important metric to see how well you have defined your user journey, and how successful you are with your developer products and with your engagements, because the longer it takes for a developer to use your APIs, the more risk there is to lose them. I think that's one of my favorite metrics that I always try to strive for, to minimize the time to first API call.

PW: Absolutely. I hear that from other providers. That first touch experience that you give to developers is such an important front door. I want to take a step back because you talked about the awareness pages and how a product manager or a CTO may visit the portal and want to know about the product they are looking at and how it benefits their use case. I’ve heard both sides of the argument. On one hand you should have those pages to help non-developers understand the benefits of your API, on the other hand I’ve heard that the non-developer audience is so small that you have to optimize your portal for developers. Obviously different approaches can work for different companies so can you talk about how you guys landed on the decision to have product pages within your developer portal so that they could explain use cases? Because I think that's really an important thing.

De Jans: Yeah. I know that there's sometimes debate around whether you should have these awareness pages in your developer portal or whether you should have them on the corporate websites. I think what matters the most is that you have these awareness pages in some phase of your journey. So you could, for example, send all of your developers first to your corporate page or to your corporate website, and there the awareness pages are directly accessible to them. It could be that this is the right approach, but I don't necessarily think you need to think about it as, you have a corporate channel and then you have a developer channel. You need to think of it as a user journey for your personas. So if one of your personas is a product manager, then you need to make sure that wherever they land on, whether it's on the developer portal or whether it's on a corporate website, that they find the information they need and that's the awareness building content.

We have chosen to send both the product managers and also the developers to our environment. Of course, you also need to make sure that you have that awareness building content on that website. I think for other companies, if they decide to send every developer and every product person to their corporate websites, then you need to make sure that that awareness building content is on the corporate website. 

You can also define a user journey that overlaps between multiple channels. Take your corporate website as one channel and your developer website as another channel. If you define your user journey, it can flow from one channel into the other. It might be because you have an awareness phase, you have a consideration phase where people consider to use your products. Then you have that use phase where people are actually using your product.

It might be that you say, "Okay, for the awareness phase and for the consideration phase, this channel is perfect for them." But then if they actually want to get started and use your products, then you might move them to a developer portal. I don't really see it like, "Should we put everything on the developer portal, or should we put everything on a different channel?" I always look at it from a user journey. If people, during their user journey, are served with the right content where they need it, then I think you will have a successful product and you’ll have a successful user experience. To me it matters less on where exactly you put it, as long as it makes sense for the user journey that you have defined for your audiences.

PW: I assume that your data backs up your thinking and shows that the user journeys are being more fully completed?

De Jans: There are all kinds of conversion metrics that can be used. I think we measured the conversion from a visitor to somebody who registers. Then from a registered developer to a developer who's actually using our products. We also measure the churn rate when they start using our products. And we can see that when we add these awareness pages that more people are registering on the portal. 

One project that we did last year was to optimize the registration flow. Now, we immediately give people an API Key. In the past we had our users register first and then they would go through another flow to create an API key. We now combine those two steps into one, and we’ve seen that the time to first API call was actually decreased by more than 40-50%. I think these conversion rates are really important to measure. Actually, before you start implementing a project, you should already know what you're trying to improve, and ideally by how much you want to improve it.

PW: Absolutely. Couple more questions here. We’ve chatted a lot about your developer portal, but I wonder if you’ve done other methods of external outreach to developers? Be that blog posts, events, webinars, hackathons, anything like that, that really works for you guys?

De Jans: Yeah, I think we've done them all, but some work better than the others. One of the things that TomTom is of course now focused on is to make people aware that we have transitioned from a B2C to B2B company. We saw that, specifically hackathons, were not ideal for that. From an awareness building perspective, a hackathon is not great because most of the time you’re reaching a specific audience, quite a limited audience. So for awareness building, it's not the best return on investment. However, in terms of getting early adopters feedback, a hackathon is a great event. What we saw is that when we had a new product that we wanted to launch into the market, before launching it we would offer it to  a hackathon community or hackathon event. That would give us great feedback for that specific new product.

We've done events as well, and of course we have all kinds of local events. We also have bigger events. We are mainly focusing on the bigger events, because we want to increase that awareness building. The more developers we can reach the better for us. I do think that's a bit strategy or company specific, I would say. In terms of events, I think we are pretty selective, and we are trying to target the major events in Europe and North America where the most of our target audiences are as well.

PW: Last question, if you are able to share, how many developers do you currently have in your community?

De Jans: I don't have these numbers in front of me but I want to give you some background on why I’m not focused on that number of developers anymore. In the past, of course we wanted to reach a certain community that you can build. I think the more, the better. But from a strategy perspective, we have decided that we don't want to focus on that mass market of developers anymore, what we really want to focus on is getting high quality leads into the developer portal. We do that by focusing on some vertical specific industries. Like I said, fleet and logistics, mobility on demand. Those are really important verticals for us.

We'd rather have 500 developers who are active in fleet and logistics, then let's say 500 developers who are using our products for free just for displaying a small map on their website, of course. I think that community building is important but in the end TomTom is of course, also a company that wants to generate revenue. We believe that we can generate the most revenue in fleet and logistics mobility on demand. I think it's more valuable for us to see and to understand where are developers coming from, that we're able to attract, than looking at the number per se.

I’d like to thank Gregory De Jans for taking the time to speak with me and share TomTom’s approach to developer engagement. This is part of a series of interviews with developer relations experts such as Raphael Assaraf at Aircall and Ryan Boyd at Databricks. Be sure to keep an eye out for future interviews coming soon.

Be sure to read the next Ecosystem Engagement article: Dave De La Pena Attributes Signable’s API Success to its White Glove Approach to Developers