Adam Kalsey

This is the blog of Adam Kalsey. Unusual depth and complexity. Rich, full body with a hint of nutty earthiness.

Software Engineering

Developer Experience Principle 5: Easy to Trust

9 Oct 2020

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

Your OKR Cascade is Breaking Your Strategy
Aug 1: Most companies cascade OKRs down their org chart thinking it creates alignment. Instead, it fragments strategy and marginalizes supporting teams. Here's what works better than the waterfall approach.
Your Prioritization Problem Is a Strategy Problem
Jul 23: Most teams struggle with prioritization because they're trying to optimize for everything at once. The real problem isn't having too many options—it's not having a clear strategy to choose between them. Without strategy, every decision feels equally important. With strategy, most decisions become obvious.
Behind schedule
Jul 21: Your team is 6 weeks late and still missing features. The solution isn't working harder—it's accepting that your deadlines were fake all along. Ship what you have. Cut ruthlessly. Stop letting "one more day" turn into one more month.
VC’s Future Lies In Building Winners
Jun 21: AI and megafunds are about to kill the traditional venture model, forcing smaller VCs to stop hunting for hidden gems and start rolling up their sleeves to fix broken companies instead.
Should individual people have OKRs?
May 14: A good OKR describes and measures an outcome, but it can be challenging to create an outcome-focused OKR for an individual.
10 OKR traps and how to avoid them
May 8: I’ve helped lots of teams implement OKRs or fix a broken OKR process. Here are the 10 most common problems I see, and what to do instead.
AI is Smart, But Wisdom Requires Judgement
May 3: AI can process data at lightning speed, but wisdom comes from human judgment—picking the best imperfect option when facts alone don’t point the way.
Decoding Product Leadership Titles
Mar 18: Not all product leadership titles mean what they sound like. ‘Head of Product’ can mean anything from a senior PM to a true VP. Here’s how to tell the difference.

Older...

What I'm Reading