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.

Developer Experience Principle 4: Easy to Get Help

Easy To Get Help

It should be Easy to Get Help when a developer is stuck or something goes wrong. Few companies release products without some way of getting help when needed. Developer products shouldn’t be either. In some ways, this is the most important principle of developer experience. Your customers will judge your API product by the quality of support they receive more than any other single factor.

Support doesn’t only involve helping when something goes wrong or breaks. For a developer product support also involves on-boarding. Getting the developer over the understanding hump to figure out what the product does. To understand how to make it do the things they need. Often developers will want to explain what they’re going to do and receive confirmation that the API can do this.

To provide this sort of support, you’ll need someone that can talk to developers in their language. Someone that can read the API calls and see what the developer intends to do. That might be you as the creator of the API. It might be a community of other developers. It might be a professional developer support staff.

When building a support team, you’ll need to think differently. Developer support is not the same as other types of product support. With most support, you can hire support people, train them on the product, and put them to work. Developer products need to reverse this. The people providing support need to understand development so they can help debug. It’s easier to train someone for support than it is to train them for development.

Another source of support is to crowd-source it from your community. For many products, if you give the tools and incentives to your developer customers they’ll help each other out. Stack Overflow has made an entire business from peer support of technical topics.

Whatever the support mechanism is, you need to make it clear to developers how they can get support, what sort of support you offer, and how long it will take to get help. "How long" is an under-appreciated nuance for those that have never been developers. With many technology products, it’s not uncommon for several days to elapse before getting a response to your support request. For developers, they’ll likely have moved on if the response takes several hours. A developer with a question is blocked. They can’t move forward without an answer. They’ll get themselves unstuck as fast as they can, even if that means moving to a different API.

You can make it easier for your developers to support themselves. Self-serve support options that developers answer their own questions will reduce the burden on your support staff while increasing developer satisfaction. Putting common error messages or log lines in your documentation allows developers to search for answers. A page of HTTP response codes and their causes for each API call will help a developer understand why they are getting the response they are.

Release notes or a changelog is a great mechanism for self-service support. A detailed, up-to-date changelog can show a developer when you fixed their issue or added the feature they have been waiting for. A less obvious benefit of quality release notes is that the developers can answer the perennial developer support question themselves: "My code stopped working. Did you change something or did I break something?"

A status page for the API also helps answer the "is it you or me" question. The status page needs to be clear and detailed. When API calls are failing, slow, or otherwise not working properly, list exactly which API calls have the problem. It can be scary to show all your problems. But being honest and over-communicating builds trust. A developer with a problem knows that if your status board is green, then the problem is on their end.

The faster you can unblock a stuck developer, the better their experience will be. It is such an effective tool that some companies consider developer support as part of their marketing budget.

Recently Written

Developer Relations as Developer Success (Oct 19)
Outreach, marketing, and developer evangelism are a part of Developer Relations. But the companies that are most successful with developers spend most of their time on something else.
Developer Experience Principle 6: Easy to Maintain (Oct 17)
Keeping your product Easy to Maintain will improve the lives of your team and your customers. It will help keep your docs up to date. Your SDKs and APIs will be released in sync. Your tooling and overall experience will shine.
Developer Experience Principle 5: Easy to Trust (Oct 9)
A developer building part of their business on your product needs to believe that you're going to do the right thing for them and their customers.
Developer Experience Principle 4: Easy to Get Help (Oct 8)
The faster you can unblock a stuck developer, the better their experience will be.
Developer Experience Principle 3: Easy to Build (Oct 5)
A product makes it Easy to Build by focusing on productivity for developers building real-world applications.
How to understand your product and your market (Sep 30)
A customer development question you can ask to find out who your product is best for and why they'll love it.
Developer Experience Principle 2: Easy to Use (Sep 28)
Making it Easy to Use means letting the developer do everything without involving you.
Developer Experience Principle 1: Easy to Understand (Sep 25)
To create a great developer experience, you must strive for a product that is Easy to Understand. Reduce the amount of thinking that someone needs to do. Make their first encounter with your product clear and easy.


What I'm Reading


Adam Kalsey

+1 916 600 2497


Public Key

© 1999-2020 Adam Kalsey.