Need someone to lead product or development at your software company? I lead product and engineering teams and I'm looking for my next opportunity. Check out my resume and get in touch.

Principles of Developer Experience: An Introduction

If you’re hoping to attract developers to build on your product, it’s not enough to simply release an API. Your product might be for developers that work at your company, partners that you hope to integrate more closely with, third parties that want to sell on your marketplace, or customers that are clamoring for a way to automate their businesses. In all cases, you’ll have more success if you think about your developer platform as a product.

Good products pay attention to the overall experience of their customers. They understand that a good User Experience is more than just what the product looks like and how it behaves. Think about Amazon. Their user experience doesn’t only cover what the product page looks like or how you checkout. Their massive product selection, free shipping options, easy return policy, putting product return kiosks in Kohl’s department stores, delivery lockers in apartment buildings... All of these things are part of the user experience. They all play a part in how and why you use Amazon. If you want your product to be successful, you need a great user experience beyond just your product design.

Developer products are no different. Developers are people too and they are attracted to a great experience just like any other person. If you want your developer product to be successful, you need a great developer experience beyond just your API design.

You’ve Got This

The experience matters a whole lot more to a developer product’s success than it does for many other products. Customers will often live with a poor experience because they don’t have much of an option. For example, if no one else makes a substitute for the product, you’ll be more inclined to suffer through a bad user experience. But developers tend to have a lot of options. If they can’t use your API, there may be some open source tools they can put together as a substitute. Or since they are developers, maybe they’ll just build it themselves.

For many developers, "I could build that" is the default thought. By targeting developers your primary competition is Do It Yourself. Most people aren’t going to go shopping for a dining room table with the idea that if they don’t find something they like, they’ll just build one. But that’s exactly now most developers evaluate APIs.

The way you create a quality developer experience is by putting their needs first. By understanding the developer, what problems they’re solving, how they go about their life, and how they react to adversity. You have things you need as a company providing the product. You need to make money, you need to secure your data, you need to build the pet feature of your biggest customer. But if you start from a position of what you need, you’ll fail. You cannot design a great developer experience without solving for the needs of the developers.

I’ve found there are six primary principles that you need to follow to create a fantastic developer experience. And just like User Experience isn’t about product design, Developer Experience isn’t about API design. A well-designed API is your minimum starting point. It’s the basic requirement you need before you even get started on Developer Experience because without a well-designed API, your product will fail.

There are lots of articles on the internet about how to create great APIs. This isn’t one of them. What I want you to do is intentionally craft the overall experience around the great API you’re already creating.

In addition to that great API, you’ll need to understand what else goes into the developer experience. You’ll need to understand what core guiding ideals should guide you in creating those.

Your developer product needs to be Easy to Understand. A developer that’s looking at your product wants to know what your product does. What is it good for and what it’s not good for. Can the developer look over what you’ve published in your documentation and marketing materials and understand what the product does, how to do it, and what the costs are going to be?

The product must be Easy to Use. How hard is it for a new developer to get up and running? Can they create and revoke access keys without your help? Are there code samples and SDKs in the programming languages the developer uses?

When a product makes it Easy to Build you’re enabling developer productivity beyond those first Hello World steps. You’re giving them tools to build and maintain robust applications. Tools for debugging or an SDK that evolves predictably. Developers will be more productive if your APIs and SDKs have intelligent defaults, syntactic niceties, and recipes for common tasks.

You need to make it Easy to Get Help when a developer is stuck or something goes wrong. The people providing support need to understand development so they can help debug. Put common error messages in your documentation to aid searchers. The faster you can unblock a stuck developer, the better their experience will be.

Developers must feel your product is Easy to Trust. Developers can be less tolerant of marketing over substance. If you say your product can do something, it needs to do it. Not sort of do it, not do it in the future, not do it if you get this partner add-on. Your communications need to be honest and straightforward. If they’re going to build part of their business on your product they need to believe that you’re going to do the right thing for them and their customers.

Finally, your product must be Easy to Maintain. If your documentation is hard to update and has the same information scattered everywhere, they’ll quickly fall out of date. If your SDKs each need a manual change in 25 places when you add a new API property, how likely is it that you’ll be able to provide more than one SDK? If it’s hard to get a new error message to show up in the debugger, you’ll ship the error before the debugger and confuse developers.

You can create a great developer experience for everything you build. Look at your product through the eyes of an outside developer. Make sure everything you build is something you’d want to use yourself. Make it easy for developers to be awesome.

Recently Written

Principles of Developer Experience: An Introduction (Sep 15)
You can create a great developer experience for everything you build. Introducing the six principles of developer experience.
The KPI that measures Product-Market Fit (Sep 9)
If you ask this question to a different small group of your users every week, you can measure trends over time to determine if you're moving toward product-market fit.
Don't use NPS to measure user happiness for enterprise software (Sep 7)
Measuring the satisfaction and enjoyment of end users is a key to unlocking product-led growth. Net Promoter Score is the wrong tool for this.
Ask One Question To Help You Reach Product-Market Fit (Sep 3)
Learn what adjacent problems you need to solve to become twice as valuable to your customers.
How to scale your product team from one product manager to an entire organization (Aug 25)
As your product management team scales, you'll have issues around redundancy, communication, and consistency. Here's now you might solve those.
Software engineering manager interview questions (Aug 6)
Here are some questions I like to use to get a sense of who an engineering manager is and how they work.
A framework for onboarding new employees (May 15)
There’s no single good way to onboard an employee that works for every role. Here's a framework for creating a process that you can adapt to each situation.
TV hosts as a guide for software managers (May 10)
Software managers can learn a lot from journalists or late night TV hosts and how they interview people.


What I'm Reading


Adam Kalsey

+1 916 600 2497


Public Key

© 1999-2020 Adam Kalsey.