Developer Experience Principle 5: Easy to Trust

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

Easy to Trust

Trust is paramount in any relationship between a company and its customers. For developers building their products on top of your APIs, it’s even more so. Your ability to deliver directly affects their product. To feel comfortable with your product, it must be Easy to Trust.

You start building this trust in your marketing. Every communication with the developer needs to be trustworthy and honest, and it starts with how you talk about your product. 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 they buy this add-on from a partner. It’s fine to communicate futures and possibilities, but make sure it’s clear what’s available right now.

Everything you communicate needs to be honest and straightforward. You need to be open and transparent with developers. A status page for your API is helpful to developers. You can build trust by showing not just the current state of the API, but historical statistics too. Developers will trust your API more if they can judge for themselves how stable your product is.

Developers need to trust that you’ll do the right thing for their users too. They need to trust you’ll protect their users' data. Believe you won’t put things in your error messages that they can’t show to customers. Know that you understand that their users are your users too.

A great example of this is OAuth permissions screens. An API often has end-users authorize your developer’s applications through your login system. The developer’s application is handing over a part of their user experience to you. How you present the login and permissions can have a giant effect on the conversion rate for your developer. Getting this wrong could scare their users away. When asking for permissions, using confusing or overly-broad names could lead people to abandon signup. Or worse, could lead to people giving permissions that they didn’t realize they’d given up.

A developer is 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.

More about the Six Principles of Developer Experience

Recently Written

The Trap of The Sales-Led Product (Dec 10)
It’s not a winning way to build a product company.
The Hidden Cost of Custom Customer Features (Dec 7)
One-off features will cost you more than you think and make your customers unhappy.
Domain expertise in Product Management (Nov 16)
When you're hiring software product managers, hire for product management skills. Looking for domain experts will reduce the pool of people you can hire and might just be worse for your product.
Strategy Means Saying No (Oct 27)
An oft-overlooked aspect of strategy is to define what you are not doing. There are lots of adjacent problems you can attack. Strategy means defining which ones you will ignore.
Understanding vision, strategy, and execution (Oct 24)
Vision is what you're trying to do. Strategy is broad strokes on how you'll get there. Execution is the tasks you complete to complete the strategy.
How to advance your Product Market Fit KPI (Oct 21)
Finding the gaps in your product that will unlock the next round of growth.
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.


What I'm Reading


Adam Kalsey

+1 916 600 2497


Public Key

© 1999-2021 Adam Kalsey.