When I worked in developer relations, I tried to spend time with the engineers who built our product, in addition to the ones who would use it. Once, one of the team responsible for our developer dashboard was lamenting that an external service would soon be discontinued. He would have to rewrite a core piece of our developer experience.
Enthusiastically, I shared about another service whose team I met at a conference. It could surely fill the place of the one he’d be ripping from our codebase.
“Not another service!” he whined. Mind you, we also provided a service for developers. But the pain of removing one API had him feeling burnt on any others.
That’s the level of skepticism we are all up against, which is why it’s important to evaluate your own site with that same scrutiny.
Developers come to your website and documentation with at least three questions:
- Can It Do What I Need?
- Do I Have Enough Control?
- Will It Be Maintained?
This post will help you understand the problems behind these questions. But you can’t begin to answer them if you don’t get past the first impression.
The Developer Sniff Test
Before looking at the documentation, a developer will give a quick “sniff test” of your site. Though they won’t know they’re doing it, they’ll examine the ABCs of your API.
These three high level areas help developers know whether to continue their evaluation:
- About page: who is behind the API and can I trust them?
- Blog posts: have they published recently and are the topics developer-relevant?
- Client libraries: do they have SDks and content oriented around multiple programming languages?
If substance is lacking from any of these three, you might have a developer deal breaker. No mention of a relevant background for the founders? The dev might as well write it themselves. Blog posts from months ago? That could be a sign you’ve stopped investing in your developer program. Don’t support popular languages? It might take too long to integrate.
These are just a selection of potential developer objections in the first few seconds of browsing your site. If you get past this gauntlet, you can move on to the truly hard questions.
Can It Do What I Need?
The first question developers want to know is if your tool is even an option for them. They’ll jump past your home page and other landing pages, unless they’re clearly developer-focused. As quickly as they can, they’ll find their way to the developer documentation (so make it easy to find).
Once there, they’ll be looking for something that tells the story of what’s possible. You can reiterate benefits here, but make sure they’re developer-focused, or else it might come across as marketing copy. A clear description of common use cases goes a long way here.
Plaid’s newest docs breaks its use cases down as a primary nav for all documentation. It takes it even farther by connecting use cases to products. You come to Plaid with a financial app problem and can quickly determine whether it has the solution.
Next, developers will look to confirm their use cases in the reference. They’ve been promised functionality before. They’ll use the reference to sanity check their concept. At this point, the right sample app or tutorial could propel them toward a real integration with your product.
Do I Have Enough Control?
Once you’ve proven you can solve a developer’s problem, they move on to deeper matters. When assessing the level of control, they’ll be looking at the build versus buy tradeoff. Is it worth outsourcing functionality to you?
For example, some use cases may be supported, but could be opinionated. Your off-the-shelf approach may work for some, but developers typically want customization options. They’ll be looking at your documentation to see how they can expand the typical usage.
Similarly, bolt-on integrations often leave rough edges for users. Product-minded developers—or perhaps technical product managers—will look for opportunities to integrate more deeply. If possible, they want to control their user experience.
Finally, for maximum control, developers like to see an open source option. If you’ve shown the benefit, many will choose your service version. Yet, open source is a positive sign for developers, especially when they ask the final question while evaluating your documentation.
Will It Be Maintained?
Regardless of whether you’re a startup, a large enterprise, or in-between, developers will question the risks of choosing your product. They’re weighing the cost savings today (in effort, stress, or dollars) to the likelihood they’ll need to switch under duress. Your job is to alleviate their concerns.
You can:
- Offer on premise solutions for enterprises with the highest concern (and budgets)
- Show longevity through recent fundraising or profitable status
- Provide a status page with a clear history of uptime
- Point to an open source option or alternative
- Point to the team’s experience solving related problems
- Build trust through authentic, authority-building content
Remember my “not another service” colleague. Your potential customers may be in the middle of removing your former competitor from their codebase. You need to convince them that they won’t have to do the same with you.
You can improve your chances with a developer audience by helping them solve technical problems. Show you know your stuff. Do this consistently over time and you’ll have a library of helpful content that shows you’re in for the long term.