Perhaps no other tool or framework went through as many revisions as The Developer Journey Map during the development of the book. It’s our most ambitious framework, as it seeks to document the end-to-end life cycle of a developer interacting with your DevRel program.

Consequently, in the book, there are six chapters totaling over 15,000 words dedicated to exploring The Developer Journey Map. This post can only scratch the surface of this topic, but will hopefully serve as a useful introduction to the concept.

What is The Developer Journey Map?

Stages, goals, questions, touchpoints.

Like a customer journey, The Developer Journey Map is a visualization that identifies the path a developer follows and experiences. As they move left to right across the stages, their level of interaction increases with your brand, team, and product. It’s one of the most valuable tools in DevRel in that it helps you to think holistically about the experience from the developers’ perspective while providing a very practical guide for you.

Your goal with the map is to progress your developer from left to right as quickly as possible to increase product adoption and revenue potential.

Those interactions, which we call developer touchpoints, are used to map the developer’s experience along the way - how they engage, what and who they engage with, how it makes them feel, and how they react. Organizing these touchpoints into a map helps you identify shortcomings or friction, which you can then optimize to create a better overall experience.

The Five Stages

Discover, Evaluate, Learn, Build, Scale

The fives stages of the map indicate significant changes in the developer’s intent and actions. They do not imply elapsed time.

For example, a developer may well complete the first three or four stages on the same day if they invest the time, and you have provided a friction-free experience. Conversely, the adoption cycle to become a user could take a year if you piqued a developer’s interest, but they haven’t yet found the right use case or project to build with your product. Also the type of developer product matters - for example an API typically has a faster journey time than an IOT hardware board.

Note that each stage has a stated goal for the developer. If the goal is achieved, the developer will move onto the next stage of adoption. Each goal has key questions that you need to answer for the developer to achieve the overall goal of the stage in question. The goals and associated questions may be different for your program. This is fine. What is critical is you have identified them, and can provide the answers necessary for the developer to progress.

As a DevRel leader, it’s your job to develop and optimize each of the “touchpoints,” ensuring you answer all of their questions and meet the goals for each stage of the journey.

Touchpoints

Owned and Earned

Owned touchpoints are the properties and content that your company owns and controls. You have complete control over what a touchpoint is, what it does, and how it contributes. Examples include your website, developer hub, documentation, your messaging on social media, your advertising, pricing information, code samples, support, etc.

External touchpoints are the opposite. You do not have direct control over them, however, they are key resources and channels to reach both your existing users and your potential future customers. Ensuring your brand and tools are visible, discussed, and supported on these properties is absolutely vital to ensure awareness grows, reputation is positive and adoption rises. Examples include developer focused media, industry analysts, 3rd party communities, external forums, etc.

On the Developer Journey Map above we included forty-two touchpoints for you to consider. We have also placed them in the spot where they are typically first encountered. Of course, touchpoints can be relevant in more than one stage of the journey. Don’t feel constrained by what these are or where they are situated in our example - do what is right for you. We encourage you to iterate on our example.

The Developer Journey Map is shared here under a CC:BY:SA license, so let us know what you think, and feel free to adapt it to keep improving its utility.

How To Find Out If Your Journey Is Working?

We recommend you use this Developer Journey Map at the initial creation of your program and periodically to audit the effectiveness of your journey with ongoing reviews and tests. The key is to remove all the friction from your journey.

Here are three ways to identify friction in both quantitative and qualitative ways to understand if your journey is working optimally:

Ask your community
Friction Logging / Friction Audits
Journey Data Evaluation and Measurement

Your Developer Journey Map is one of the most important documents you will create. It can be used to document and level set the understanding of your Developers’ interactions and their experience with every facet of your company. It also signposts the key external (or earned) places your customers and prospects spend time.

To learn more about The Developer Journey Map pick up a copy of Developer Relations - How to Build and Grow a Successful Developer Program, now available for pre-order via Apress & Amazon.

Pre-order the book

Developer Relations - The Book

The Developer Journey Map