Home » Developer Journey or Developer Empathy? Why does it matter

Marketing to Developers Developer Journey or Developer Empathy? Why does it matter

We marketers are overcome with the need to compartmentalize concepts into nifty two- to three-word phrases. We even do it with our jobs. The problem becomes untangling what we are actually trying to do when we throw the phrases around. Developer journey and developer empathy in particular are cut from the same cloth, and are aimed at solving the same issue.


Disclaimer: I am not a fan of the phrase developer empathy, but because I value being able to have continuity between conversations with developer relations pros, I use it. The phrase I prefer to use is developer journey. While one is an outside-in approach and the other is inside-out, they both are going after the same challenge. Connecting with developers when you are not in the room with them geeking out is hard! (Trying not to piss them off might be even harder.)

Key Differences

The developer journey is focused on the process a developer follows when implementing new technologies and frameworks. Whereas developer empathy is focused on understanding the developer’s pains first, in the developer journey, your portals, marketing, and content need to always be focused on getting the developer to the next step in their journey, adding as little friction as possible. Empathy focuses on making sure your persona definitions are dialed in, and that you can catch on to the nuances of being a day in and day out developer.

But how they are different is not what is important. What is important is what both are attempting to do.

Both make sure the following are true:

  • Developers won’t hit roadblocks.
  • You understand developers beyond what they do with your product.
  • You care about their use case, not just their implementation of your API.
  • You pay attention to the user experience of all the tools and content you provide.

As a developer relations professional, your goal is to make the developer’s experience with you and your API complete and seamless. Additionally, you need to understand that you have to operate and speak with developers in a manner they expect—which means speaking from a technical perspective. Be direct. Do not pander, and do not make big claims.

Strategize with Empathy, Implement with the Journey

The vagueness of developer empathy makes it hard to translate into an execution strategy. But at the same time, it’s the high-level foresight that makes sure any implementation has core tenets. The benefit of the developer journey is that implementation is clear—You just need to know where to start. If you are concerned about awareness, focus on the early stages of the journey. If you are focused on implementation success of existing users, focus on the latter parts. There are stages to follow, and each stage can be a micro-project in your overall implementation of quality developer relations content and portals.

So, drive your execution of each stage of the developer’s journey with developer empathy. For example, when you create content to support a developer who has no clue about your company, make sure the content uses technical (but friendly) non-API specific language. When you build a developer portal, make sure the information architecture is not frustrating.

Your developer portal, documentation, case studies, API samples, blog posts and assets should all fall into some stage of the developer journey, and should speak directly to developers. The only way to address the challenges associated with engaging with developers who are constantly bombarded by content is to make sure you implement your developer program tactically and tactfully—with a clear process that is driven by understanding. That is why the developer journey and developer empathy are key tools to make sure you are successful. The terms themselves are only a way to have the conversation.