What drives API adoption?
A product owner’s dive into the mind of junior developers.
As API product owners we aspire to build interfaces that are intuitive, powerful and follow the best guidelines, but when you’re caught up in your weekly sprints and blurred lines of code it’s easy to forget about your customers.
Decathlon developer’s platform goal is to empower energetic and ambitious entrepreneurs with tools to build better sporting experiences.
Over the last couple of weeks, I had the opportunity to introduce the students of Le Wagon Montreal to the nature of APIs, background jobs, mailing systems as well as help them through the realization of their final projects.
During the project weeks, I paid close attention to which APIs they chose, but most importantly why they chose them.
The moments we have to connect with our target audience are few and far between. Which is why this experience was so beneficial to our project and I thought I’d share the brief results of my research and experiences in this article.
*Keep in mind that this is a reflection geared for products aimed at teams with limited resources and reflects my experience of observing new developers.
The “I’m not sure what I’m doing; I hope it works / hail mary” scenario
When learning to code in a complex framework such as Ruby on Rails, you quickly realize how complex and how many dependencies are required to make everything work together.
You’re also not equipped to resolve/debug complex issues in code you haven’t written yourself. When such a problem arises the correct way of handling it is to ask help from your teacher or help from a more experienced developer, but you don’t always have access to such a resource.
This is where the copy and paste shines.
A great execution of this is the Twilio SMS API. In the quick start portion of the documentation: you pick your language and they provide you with a code snippet that can be read as almost plain english.
Even with little experience you can tell what this snippet is supposed to do. When the dev runs it and it works on the first try, Twilio wins. On the other hand, as someone that offers this you have to be careful. People will expect it to work on the first try. If it doesn’t, they will quickly dismiss your product and will rarely look further. They’ll move onto the next google search result or the next StackOverflow answer.
$$$ and why it’s important to start free
Countless is the amount of memes on the internet laughing at how reluctant developers are to pay for services. It’s never as relevant as for junior’s building their first project. The ambitions are always through the roof; they want the app to skyrocket in traffic as soon as it launches.
API billing is a black box for juniors: you start charging after 2000 api calls? OK, what does that mean. When am I going to hit that mark? What if I make a mistake in my code, call the api 200,000 over the course of the month. They usually can’t afford such a costly mistake.
In the past year and after I started teaching, google took a different direction. Even if usage is free up to a certain amount which is arguably quite generous, you now need a credit card linked to your account to use the maps api.
We have since seen a drastic change in the choice of mapping solutions by the students. The majority of students used to choose google maps, but now they choose mapbox . The reason is quite clear when you ask them: I looked up the options. This one required a credit card to test it, the other one didn’t.
F.O.M.O.
When our students choose an API for data, they often choose the one that’s the most established. The one that they think will have the most accurate and exhaustive data. The focus is on user experience here. If they come to your website for data: they better find what they are looking for.
A good example of this is places. Although there are other options in the places API sphere: foursquare, yelp. Google places always wins amongst students. The reason is simple enough, we personally use it everyday. We always find what we’re looking for and that’s why we trust google as a solution for our users.
If you are going to compete in the data API sphere, you need to find a way to reassure potential devs that by using your solution they won’t have to fear missing out on better data elsewhere. And if you are competing against Google: good luck!
I had a few more reflections, but I’ll leave you guys hanging until next time. Let me know if you like the format and feel free to reach out! We also have a few job openings at Decathlon if you’re looking for a new challenge!
