As a product owner, when plotting out the success of your product, you have a lot to consider.  Many of these facets are well discussed and opined – you’ve likely read plenty of articles that share a perspective on this subject.  However, there is an oft overlooked facet of your digital product that much of the existing writing fails to cover, an area that can be crucial to the adoption and ultimate success of your product: developer experience (DX).

Think for a moment about your digital product (tool, library, service, platform, whatever it may be)….does it have touchpoints used by developers?  If so, it has a developer experience of some sort!  Have you thought critically about that developer experience?  If not, you should. Unless you are the only provider in your space, chances are the developer experience will have a meaningful impact on the adoption and ultimate success of your product.

What is Developer Experience (DX)?

The field of user experience (UX) is interested in how easy or hard it is for someone to use a digital product (website, software), particularly in terms of how pleasant that experience is for them.  Generally speaking, a better user experience is desirable for reasons I will explore a bit later on.

Developer experience (DX, for short) is the subgenre, or extension, of UX, concerned specifically with the developer persona and their experience using developer-specific tools (libraries, platforms, services, API’s, SaaS products, etc. – which for brevity, moving forward, I’ll just refer to mostly as “tools”).

As a first example of developer experience, let’s consider a familiar player and tool provider in the technology space, Amazon Web Services (AWS).  The AWS platform contains a number of services, or tools, used by developers to accomplish various technical tasks. While building a digital product any developer who uses an AWS tool can be said to have had an “experience”.  This experience will encompass specific tasks such as:

• Creating an AWS account and logging in
• Installing and using the AWS CLI 
• Searching and reading official AWS documentation 
• Searching for tutorials and examples pertinent to their specific use case
• Writing code that utilizes AWS services and their APIs

The experience of the developer using AWS tools, and the holistic platform, will fall somewhere on the spectrum of bad to good.  The quality of the developers’ experience in accomplishing their tasks by using these tools to perform their intended purpose is the concern of DX.  

DX is of particular import with tools used primarily by developers, as with the AWS example above.  However, DX also extends to other, less obvious, systems and tools and this is why DX is more powerful than it may initially seem—its reach is wider than anticipated.  

Take a less obvious example of DX, Twitter.  The first thing that comes to mind when you think of Twitter is sending messages of 280 characters or less, which is indeed its primary purpose for its end users.  However, in addition to the tools that exist to send tweets, Twitter has an API (application programming interface), which is integrated prolifically into various other software applications.  These other applications are coded by developers, which means the developer must, at some point, interact with the Twitter API.  The Twitter API can then also be said to have a developer experience.

Keeping Twitter in mind, it should be easy to conjure countless other, less obvious, DX candidates.  Basically, if a digital tool, platform, or service includes an aspect used by developers, it has DX. Facebook, Instagram, smart home technology like Nest and Ring – all of these have APIs.  This vector will only continue to grow as we continue to digitize our lives, collect more data, and invent new types of services to work with that data (AI, ML, etc.). It is likely these systems and tools will expose data or functionality in one way or another.  If a developer has to build something to interact with one of these tools then DX exists and likely needs to be optimized.  

Why Developer Experience (DX) is important

DX is significant because it can affect the usage and adoption of your digital product.  The more elegant the tool is, the easier and faster it is to use, the more people (developers) will use it.  Additionally, an argument can be made for a second, more esoteric, value provided by good DX: building things of quality is important to the folks who do the building.  Doing good work is more inherently rewarding to the builders – but that’s a discussion for another day.

From the perspectives of a developer and product owner, tools with sound DX are powerful because they facilitate faster and easier work.  This advances a positive downstream effect for your product.  For example, when building some software, given the choice of two API’s to convert speech to text and the autonomy to make the selection, a developer will likely pick the option with better DX. The developer understands that superior DX typically leads to an easier and faster implementation path.  Consequently, this typically provides cost savings for whoever is footing the bill. Increased implementation speed also means delivering business value (features) to end users of the product more quickly. All wins for the product.

Here are some examples of how good DX enables faster development:

• Working with a tool that has well written, well organized documentation, makes it easier to learn and faster to find answers.
• Quality and consistent APIs speed development by reducing cognitive complexity.
• Having canonical examples of real world use cases that outline best practices, accelerate the learning curve and encourage quality code as adoption proliferates.  As an aside, countless times over the years I’ve seen some bad block of code show up on an official piece of documentation, leading to it propagating via copy/paste into production applications. This is a result of bad DX.
• Curated learning paths for developers new to the tool also speeds up onboarding, and again, encourages adoption as well as proper usage of your tool.
• Having a place where users can ask questions and get well informed answers helps to promote exploration and new use cases for your tool perhaps not even originally considered.

The inverse of all of this is true as well; bad DX adversely impacts developer speed and cost.  Poorly documented and disorganized APIs are familiar to most developers. When using a tool, maybe it’s nearly impossible to find a useful example or user guide, or an API is poorly documented and inconsistent.  These types of negative developer experiences extend implementation time and costs, and increase team frustration. They ultimately steer developers towards other, more elegant, options. In worst case scenarios the dissonance of the implementation process emerges in your end user application as disjointed UI or UX.

Developer Experience (DX) in a nutshell

Let’s go over what we’ve covered so far:  

• DX can be defined as a sub-genre of UX concerned with the developer persona and their experience using tools, services, libraries, or other developer-specific aspects of systems (any and all systems!)
• DX, like UX, can be said to be positive or negative depending on the ease of using a tool for its intended purpose
• Any tool, library, service, platform, etc., used by developers has a developer experience, including tools not specifically built for developers (like Twitter, Google Assistant, etc.)
• DX is important because of its relationship to usage and adoption – i.e. the easier a tool is to use to achieve its purpose, the faster people can use it to accomplish their work, and the more people are likely to use it for this purpose (adoption)

Developer Experience and your product

As our digital world continues to evolve into digital products that leverage an interconnected network of other digital services and products, the developer experience is, and will continue to be, a critical ingredient in the success of digital products.  Software architects and developers intuitively and empirically understand the negative impact poor DX has on implementation speed, cost (both near and long term), and the overall happiness of the implementation team.  Given choices in crowded marketplaces, these decision makers will gravitate towards tools that provide superior DX.

Now think about your digital product.  Does it have a facet used by developers? If so, it has DX, and chances are you should be thinking critically about that experience as an important component in the success of your product.