top of page

7 Point Developer Onboarding Review


Onboarding? That sounds painful! Actually it’s an 'insider' name for the process of getting a developer up and running with your API or other tool. It’s the post-awareness phase, in which the developer is exploring the API, getting started with it, learning about it, and then potentially going live and into production with it.


It’s a crucial part of a developer’s journey with your API, and it’s a phase where you could potentially lose the most developers from your program if you don’t get it right. The good news is that you can heavily influence the outcome by minimizing the hurdles, obstacles, and friction a developer runs into when they’re getting started.


Below, we’ve outlined the seven most crucial elements for the onboarding process, so let’s see what works and what doesn’t.


1. First Impression – Make it easy for the right developer to get your message and take action.

We’ve discussed the need to understand your target developer segments and to make your APIs and program a good fit for them. Your onboarding process should make use of this, and be built with an understanding of who your developers are, and the timing and context around their needs. There are three key questions your API program and portal should immediately be able to answer for developers:

  • Who is this API for?

  • What does this API do?

  • What’s in it for them?

The key to this is having a solid developer-focused value proposition that explains what your product does and why it’s so great. Pusher and SendGrid do a great job of this on their sites.


2. Product Messaging – Focus on the “What’s in it for me?”

Your product messaging should expand on your first impression/value proposition and answer more questions for developers. And remember, the developer decision making unit (DMU) is both technical and business focused – so your portal needs to address this from all sides that a developer may question:

  • Why does this API deserve my/my team's time?

  • Why is it better than other solutions?

  • Why would I use this API?

  • Where’s our win?

Nexmo provides good examples of this for each of their products.


3. Examples and Case Studies – Show who uses your technology, what they do, and how they benefit.

The most persuasive piece of support for your API is endorsement from another developer. Good case studies and examples provide this, and help illustrate your understanding and establish credibility. They also provide valuable context to developers, so they can better understand how your API works and the value it provides. Being able to show this, rather than just say it, is immensely helpful.


Twilio does an excellent job of showing who uses its APIs, as well as providing use case examples for its services.


4. Registration – Keep the requirements light and the process quick

Registration processes are a huge obstacle in the onboarding process, and this seemingly small step can act as the most significant barrier for developers in your API program. This is typically based on ignorance of a fundamental truth for developers: being able to use an API or other tool is a necessary part of the learning and decision-making process.


Keep your registration requirements as minimal as possible – the less you ask for upfront, the better. If you need to get more information later (for instance, before a developer goes live), ask for it then. And beware of introducing unnecessary speed bumps like email verification or, in the worst case, manual approval of developers by your team. Only use these when they are truly, absolutely, necessary.


Stripe has a great example of a good registration process. All it asks for upfront is an email address and a password – but even better, it lets developers skip registration and begin evaluation without creating an account.


5. Getting Started – Get your developers up and running quickly by minimizing your TTFHW!

Time to first hello world (TTFHW) is a key metric you may not be familiar with. This is the actual time, in minutes, that it takes for a developer to start using your API through to when they can see some results – usually a 'Hello World' message. Do you know how long your API’s TTFHW is? You can even brag about it, like Samsung Artik does on their site.


You can help developers get up and running quickly (and minimize TTFHW) in several ways:

  • Provide SDKs and libraries in the most relevant languages/platforms.

  • Use API explorers, consoles, and other tools on your site so developers can see how your API works.

  • Provide bulletproof example code.

  • Compile a great quick start guide, like the one Firebase has.

6. Docs and Support – Good documentation is essential, and it’s a part of the developer’s decision-making process

Documentation is all too often an afterthought for API programs, but it’s a key resource for developers, and also is an important part of your developer marketing! Documentation provides context and shapes perceptions for developers. Some key areas to focus on in your documentation and support are:

  • Get your content correct, make it easy to use, and keep it up to date.

  • Don’t put stuff in DOCs or PDFs (yes, this still happens…), just use HTML – you want your content to be highly searchable!

  • Don’t hide it behind logins or other walls.

  • Remember to provide code samples and demos.

  • Don’t rely solely on your own site and community. Figure out where else your developers live, like Stack Overflow and GitHub, and make sure you’re there, too.

7. Libraries and SDKs – Light the path by creating add-ons and tools that are right for your developers.

Again, knowing your developers is key here, so you can make sure you’re creating libraries that match the languages and platforms they want to use. Also, it’s very helpful to link to outside libraries and open-source projects. This helps to extend your support via your community, and also helps create currency with developers!


For examples, see how Stripe and Twilio both provide official libraries and support community-made libraries.

コメント


コメント機能がオフになっています。
bottom of page