Made by
Made by
Map with toy car
Gregory De Jans
As standalone sat nav devices disappear from stores, what becomes of the company whose name has been virtually synonymous with them?
TomTom has been a leading provider of GPS for more than 20 years, with more than 80 million navigation devices sold worldwide.
But the company is also enjoying an API revolution with its location and traffic data used by Apple, Uber and Microsoft. Alongside these tech industry giants, TomTom’s customers now include individual developers and smaller start-ups, following the release of their first self-service APIs.
Moving from a pure enterprise-sales model to also enabling developer-led self-service has been a shift of strategy two or three years in the making. And, according to Gregory de Jans, TomTom’s Head of Developer Relations. this is not just about opening a handful of token endpoints. Instead, they’re providing self-service access to pretty much everything they have to offer including online mapping and routing, geocoding, travel times, and live traffic information aggregated from 550 million people providing real-time road data.
So, what prompted TomTom to target developers directly?
TomTom’s journey towards self-service APIs reflects that of many other established data providers. While enterprise sales teams have been great for bringing on-board large accounts, the process was overly top heavy for individual developers.
Previously, it would work like this: a developer would sign-up, play around with an API and then need to speak to someone in sales if they wanted to use that API commercially. Across multiple industries –– travel, finance, telecoms –– the same situation has provided room for newer operators to step in. Rather than allow that to happen, the team at TomTom chose to create their own public developer portal and self-service.
“Developers can sign up and get a daily 2,500 credit package free of charge straight away. Then we have credit packages that people can buy online with their credit card, starting as small as $25,” Gregory said in a call with me recently.
“The time to market for people who want to use our APIs becomes really short, because they can develop and then immediately have access to it.”
This self-service system required a fundamental shift in thinking: the developer was now the customer.
Because, as Gregory points out, “If developers don’t like the APIs, you will not sell any APIs.”
TomTom worked internally to “create an awareness that developers are crucial to an API’s commercial success, they need easy access to products and services, the right tools, the right documentation and the right support.”
“We are still working on our developer portal to make sure that we integrate all kinds of new tools and features to create that excellent developer experience,” Gregory added.
“I think now TomTom is in a place where we realize that it’s not only product managers and executives who are important to influence but also developers have a very important role in deciding what APIs they will use.”
Is there some friction involved in this change? Gregory acknowledges this can be a difficult area and it took some time to get right at TomTom.
“Of course, you always have people who understand what developer relations is about, and then you have people that you need to work with a bit to make sure that they understand that developers are such an important stakeholder,” he reflects.
“I think it took some time to convince the management that we had to invest a lot in developers and make sure that we have the right go-to market approach to talk to them and to get their feedback. Now we have a lot of people on board.”
Today at TomTom they have a two-pronged strategy that will be familiar to many developer relations professionals: enterprise sales managers continue to court the large accounts and the developer relations programme targets developers directly.
Of course, apps that start out small often grow and at TomTom they have a process to introduce account managers where that happens.
As TomTom prepared to go live with their developer portal, Gregory said they learned a number of key lessons, both about how to build developer-targeted products and also how to market them.
Creating documentation and support tools needs to be done as a team – developer relations, back-end engineers, API and SDK developers must work together to provide a coherent experience.
“It’s important, I think, that you work with developers to make sure that you have the right documentation and that it’s not a completely different team who is making the documentation and tools available for your APIs. Our APIs were engineering driven, so it was valuable to involve those engineers who actually created the products in creating the documentation.”
On the marketing side, they’ve paid particular attention to metrics and understanding the developer journey.
“We’ve actually started a project in TomTom,” Gregory said, “together with people from other departments to make sure that we can aggregate all the data that we need into one big database, and that we have a visualization layer on top of that. So, we’re aggregating, for example, data from our analytics system for our websites, our analytics system for our API management system and also our invoicing departments.”
Bringing all that data together helps to show the ROI of their various developer-targeted activities.
Creating a good developer experience is crucial, says Gregory.
“Developer relations for us is about closing the bridge between the outside world and the inside world. So, we involve our internal developers when we go to conferences. Just recently, for example, we participated in the hackathon at San Francisco Developer Week. It’s great because our engineers get immediate feedback, ‘Okay, we like this, or this should perhaps be a bit better documented.’”
Having that free flow of communication between internal and external developers has, Gregory says, resulted in a better developer experience.
“You need to gather feedback, you need to make sure that you understand what developers like, what they want. And the best way to discover that is not by sitting behind your PC and writing some emails to developers but actually to get out there.”