Need someone to lead product management at your software company? I create software for people that create software and I'm looking for my next opportunity. Check out my resume and get in touch.

Developer Experience Principle 4: Easy to Get Help

Freshness Warning
This blog post is over 3 years old. It's possible that the information you read below isn't current and the links no longer work.

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

Mastery doesn’t come from perfect planning (Dec 21)
In a ceramics class, one group focused on a single perfect dish, while another made many with no quality focus. The result? A lesson in the value of practice over perfection.
The Dark Side of Input Metrics (Nov 27)
Using input metrics in the wrong way can cause unexpected behaviors, stifled creativity, and micromanagement.
Reframe How You Think About Users of your Internal Platform (Nov 13)
Changing from "Customers" to "Partners" will give you a better perspective on internal product development.
Measuring Feature success (Oct 17)
You're building features to solve problems. If you don't know what success looks like, how did you decide on that feature at all?
How I use OKRs (Oct 13)
A description of how I use OKRs to guide a team, written so I can send to future teams.
Build the whole product (Oct 6)
Your code is only part of the product
Input metrics lead to outcomes (Sep 1)
An easy to understand example of using input metrics to track progress toward an outcome.
Lagging Outcomes (Aug 22)
Long-term things often end up off a team's goals because they can't see how to define measurable outcomes for them. Here's how to solve that.

Older...

What I'm Reading

Contact

Adam Kalsey

+1 916 600 2497

Resume

Public Key

© 1999-2024 Adam Kalsey.