Create An Amazing Onboarding Experience For Developers

James Christopher
8 min readOct 19, 2022
Coders working
Coders working from dawn to dusk

Onboarding developers can be a tricky affair since developers and technically fluent professionals are diverse in knowledge, experience, skills and geography. This presents the issue for enterprises to setup different onboarding touch points for the different developer personas.

Many marketing teams employ the standard playbook of throwing the kitchen sink at their audience hoping that at least one piece of collateral in their repository will land a qualified lead, even a commitment.

That “blanket the airwaves” approach adds noise and increases the cognitive load for potential buyers who have parse through a lot of information that can vary in style, tone and format. The overwhelming amount of information, generates a spawn of more questions like: Should they read the case study first? How useful is the use cases to my problem? How about jumping to the FAQ?

The avalanche of questions and the availability undermines the experience of the first point of contact by freezing the developer’s decision making process causing frustration and stress. This psychological phenomenon argued in the book, The Paradox of Choice, suggests reducing the number of options can mitigate the paralysis consumers face. The same condition holds true for marketing aimed at developers — abundance can handicap or kill rapport, interest and engagement.

But there is hope.

There is an asset that can serve as as a universal touch point to help onboard consumers and developers irrespective of type of persona. Its applicable to feature rich and highly configurable tech products or services.

First off, any journey requires a clear start and end point. Most buyers have an expected outcome on a proposition and any accompanying sequence of actions to reach that outcome. But in order to move from point A to point B, a person will need to find their bearings.

And to secure a bearing, and orient them towards the endpoint requires a map (or compass). In product marketing and sales, this is often takes the form of an evaluation map as the instrument for orientation for sales. But for users and developers, we’ll call it a onboarding map.

Don’t expect this map to have topological features and spatial, instead think of it as a schedule of courses in college. In this schedule, you’ll have your course prerequisites and then the main body of 100 to 200-level classes. Same thing for our onboarding map, but instead of chaining time slots we schedule a list of materials in a particular order. Unlike schedule regimen, the reader is not obligated to stay on the track. If they feel proficient to skip to advanced topics, they are free to more to advanced tracks.

More than a map, a structure for education

Besides the goal of way-finding for developers, we also shouldn’t forgo the opportunity to demonstrate the value of your offering at the same time building a level of rapport to the audience. It’s something worth investing time in.

The goal of guiding is important, but let’s not neglect three other important goals to strive for when developing a map.

  1. Elevating their skills and knowledge through education.
  2. Building a relationship from the journey
  3. Gaining insights from their interactions

In developer marketing and developer relations, selling directly is not the goal. The goal centers on building relationships and cultivating trust through the brand. The byproduct of this relationship may lead to a future sale and loyalty, but doesn’t guarantee it.

Laying down the onboarding tracks

Product marketers that work on positioning of software services and systems maybe familiar with an evaluation map designed to give a guided tour to prospects and help them make a decision. The tour can cover a product’s key features, differentiating capabilities, services, risks and pricing.

Similarly the onboarding map serves to smoothly guide the developer in understanding the purpose and use of your product. The tour leans heavily on educating the developer on the utilitarian factors of function, scale, and security.

The map itself can take any number of forms. It’s flexible and can be designed as a matrix, a series of webpages, a diagram or bulleted outline. I prefer to design maps that are more visual than textual.

Your offerings marketing assets can be equally complex which can result in elaborate intersecting paths, and a tangled mess, but remember that the key purpose is to give a clear direction of what assets they should read and review.

Start with the essentials and keep things simple.

The rudimentary track

The most basic map can be a simple sequence of assets that gradually builds on the topic. Consider this simple sequence:

A simple 3-stepper

Aligning specific collateral or resource to answer these core questions is a good way to start a beginner’s track. If applicable, you can add collateral that serves to answer “where?” and “when?” questions. We can always extend the track to ensure each component builds on the previous track.

Here’s a more developer-centric model:

A developer-centric onboarding track

As you can see, I avoid starting with the overused ‘Hello World’ example which is the de facto opening many software companies use as the starting point.

Instead, start with an overview that covers the high level features and summarizes key aspects of your solution. Then, show them how to setup and/or configure their environment. Refrain from using a ‘Hello World’ example to something more meaningful, relevant, and demonstrates the value of your product using a general use case. Next, follow up with example code snippets with explaining captions. You can boost that experience using an embedded inline code console and preview.

Finally, show them a step-by-step process to build a project from scratch including best practices and gotchas.

Don’t make it complicated. A simple taxonomy will do.

Maps can be organized by the standard skill level or personas. A three level setup of beginning, intermediate and advanced is typical for single product offerings.

The count of resources can vary, but optimally it should be designed into bite sized modules following the writing model known as The Rule of Three. Following that rule, each level can be partitioned into a three sets of three. In the diagram, each asset is represented by a circle, like so:

The Proverbial 3-Set Model

A more adaptive system, but requires more forethought, planning and development of your assets is the persona-based map. Just as each persona has different needs, goals, knowledge and skills, the tracks on the map should reflect these variations, along with the materials that are associated with the track.

In the same way, a three-set leveling model can be incorporated into the persona model, so we can create sets of three for each persona similar to the most basic model with a beginner, intermediate and advanced levels.

Persona-based Onboarding Model

The depth of the assets can vary, but keep the sequences short. The Three-level model with three assets being minimum amount per track. Five assets is average. Ten is great, but I think nine is a sweet spot because its divisible by 3, and matches the consistent pattern of three. There is no hard rules on how many, but the point of onboarding is striving for the minimum effective dose for the developers to get comfortable with your product or service at the first point of contact.

You might be wondering why not just round it to ten assets like Top 10 lists? It’s already familiar to many. But 10 items are expected to be consumed in one sitting or one session, whereas introducing a three piece set of three, will be perceived as more attainable and easy to follow.

Which assets to select?

The most important part constructing a map is curating the right assets, collateral and media (i.e. components) to place on each track. If your library of marketing or technical assets is extensive, it’s likely you already have something to use on the track. You’ll have to judge the relevance and level of the material to appropriately place it. Of course, if the asset doesn’t exist, you will have to create it to fill in the gaps.

As far as asset to use, video clips are attractive choice and can be substituted for text-based assets. But don’t lock yourself into one using type of media format. Despite its popularity in social media and an effective short-form teaching format for edtech platforms, developers may still prefer to read versus passively watching.

Give them that option by mixing into the component like this:

Mixing formats into components

Never too late to refresh and restructure

If your company has been around awhile, your team likely has a reservoir of assets to build out your map. This might make building a map easier or harder.

For teams that are disciplined and organized, those assets might already be appropriately tagged by levels or topic. That would make it easier to fill in the map, but not necessarily make the transitions from asset to asset smooth.

For startups, they may only have a scarcity of materials than their mature counterparts and that’s might be a blessing. This could be a great opportunity to start with a blank slate and being architecting a map with intention and careful design.

Onboarding maps are a useful tool that make the onboarding process for developers simple. You might be overwhelmed with learning a new product. These onboarding maps will quickly direct you step by step to how you can get the most out of your product.

Onboarding maps are a great way to introduce developers to your product. They provide context and focus for new developers, saving you from losing them before they even try your product.

With a coherent map, you have control over the content that they read, and the order of information they digest. This allows you to lower the barrier to entry while at the same time increasing rapport and engagement. The end result is a better experience for new developers. They’ll be more likely to stay engaged and want to learn more about your product.

--

--

James Christopher
James Christopher

Written by James Christopher

Pen-smithing ✍️ about risk and resilience. Cybersecurity by day, researcher at night, writing all the time. Follow me: 🦋 @jchrisa.bsky.social

No responses yet