7 Steps to Successful Developer Onboarding

This is the fourth part of our series How To Build a Strong Developer Community. In part 3, we looked at how to make sure your developer program is measuring the right things and how to make effective use of your data.

Onboarding is the trendy term for getting someone up to speed in, for example, a new job. When it comes to developers, onboarding refers to getting people up and running with your API. It’s the post‐awareness phase, in which the developer is exploring the API, getting started with it, learning about it, and potentially going live and into production with it. It’s a crucial part of a developer’s journey with your API--and it’s the part of the process where you’ll lose the most developers from your program.

The good news is that you have a lot of control over whether developers do or don’t stick with your program. It’s all about minimizing the hurdles, obstacles and friction developers encounter when they’re getting started.

WIP has outlined the seven most crucial elements in the onboarding process, and provided some recommendations for what to do--and not to do--each step of the way.

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. 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 me?

Key to this is having a solid 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 both standpoints:

  • 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 acts as your API program’s best chance to screw things up with developers. 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 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. All it asks for upfront is an email and a password. But, even better, it lets developers skip registration and kick the tires without creating an account.

5. Getting Started: Get your developers up and running quickly. Minimize your TTFHW!

TTFHW is a key metric you may not be familiar with: Time To First Hello World. This is the actual time in minutes it takes for a developer to start using your API and be able to 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 SAMI do 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 part of the developer decision‐making process.

Documentation is all too often an afterthought for API programs, but it’s a key resource for developers. It is also 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 and make it easy to use.
  • Don’t put stuff in DOCs or PDFs (yes, this still happens); just use HTML--you want search to work!
  • Don’t hide it behind logins or other walls.
  • Remember 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 a big help here is to link to outside libraries and open‐source projects. This helps to extend your support via your community, but it also helps create currency with developers.

See how Stripe and Twilio both provide official libraries and support community‐made libraries as an example.

This is part of our series How To Build a Strong Developer Community. Part 5 will provide recommendations to review when considering which events to participate in.

Carlo Longino Carlo has more than a dozen years' experience in the mobile industry, beginning just after the turn of the century when he worked for Nokia at its headquarters in Finland and mobile data services were in their infancy. Before joining WIP in 2010, Carlo worked as a freelance consultant and writer while he completed an MBA; prior to that, he was Senior Analyst for Floor64, a Silicon Valley-based analyst firm, where he covered the mobile and fixed telecom industries. He also helped launch and spent five years running TheFeature.com, a thought leadership site owned by Nokia. Carlo is a well-known mobile blogger at MobHappy.com, and his writing has also been published in The Wall Street Journal, Business 2.0 magazine and on Dow Jones Newswires

Comments