Nowadays, more and more companies need to communicate with each other. In the digital world, it happens through APIs.
**Application Programming Interfaces (APIs)**, as the name suggests, are interfaces that allow communication between 2 or more systems, enabling companies to transmit data between different systems.
When you take a shot of your dog playing in the garden and share it on Instagram, there are several APIs working behind the scenes so that you can share this moment with the world.
The problem is that not all companies have well-documented and easy to implement APIs, leading to a terrible developer experience.
Some companies innovated in this field and are very successful just because they are developer-centric.
One of the best examples is [Stripe](https://stripe.com).
They completely changed the online payment industry, being the first company to offer one of the best developer experiences on the planet.
With this approach, developers from all over the world became Stripe's evangelists just because every aspect of their API is very easy to understand and integrate.
They also offer SDKs or libraries for the most popular programming languages, like Java, PHP and JavaScript, including working examples where developers can have their platform up and running in just a few minutes!
And best of all, it's all open-sourced and available on GitHub!
Tooling is also a big Stripe's advantage. With Stripe CLI, developers can run their API in the command line, covering the whole developer workflow in terms of API interactions.
Some years after Stripe's success, their competitors had to adapt themselves to this new world. Most times, they completely redesign their whole API architecture and developer experience.
But there are many companies that didn't follow this trend and still have old APIs, with mediocre documentation and tooling. Most of them have no tooling at all.
When working with APIs, developer workflow must be as smooth as possible. It starts with documentation that should not only provide all information about how to interact with the API but also quick start guides and working examples to get it up and running in just a few minutes.
That's important because developers need to understand and evaluate APIs in order to plan what they need to do on their end and also to provide estimations to their team or customers.
Most applications out there are B2B, meaning that the people that buy your software will probably not be the ones that will use it.
In terms of APIs, that'll be the developers. They might be part of the decision making of adopting your system or not. If you don't offer a great developer experience, they will hate you, they will make sure other developers know they hate you, and you are probably out of the game.
It's also important to mention that developers are the best evangelists for APIs. If you succeed on it, you'll have a legion of people talking about your API, publishing tutorials, videos, creating new tools, and so on, just because they are having fun using it.
By having great SDKs, if possible open-sourced ones and available on GitHub, your company will benefit from the social aspect of those networks. And you'll have hundreds or thousands of volunteers helping your company!
Another aspect of having a great API is that developers will probably create new things on top of your system, creating a big ecosystem around your product, which expands the possibilities to your business.
WordPress, JIRA, and Zendesk are outstanding examples of online tools succeeding just by having a big ecosystem around, with plugins and extensions available in their marketplaces.
If your company doesn't have an ecosystem around it, you're leaving lots of money on the table.
**Ok, Cadu, you've convinced me! How could we improve developer experience now?**
There are different ways your company could invest in developer experience. It may vary from company to company.
To make it easier, I've created a 4-step framework to help your team to add or improve a developer experience initiative in your company.
It's based on my experience working with and evaluating APIs.
**Quick tip:** you can use this framework to evaluate any problems!
## 1) Understanding your business goals
This is the most important step. Product Managers call it "the why".
Therefore, here you should clarify the high level objective of your company.
- Why has your company decided to add or improve developer experience?
- Why do you need more people using your API?
- What business goals are you trying to solve?
Let's say your business is a CRM SaaS application.
There is a demand from your customers to integrate your system with other tools like Analytics, Email Marketing, and LinkedIn.
Those integrations would also create an enormous advantage against your competitors once they don't have it yet.
Therefore, your business goal would be to provide more value to your customers by integrating into your system other tools they are already using.
It would also allow your company to charge more from the customers to use those integrations, so that you would increase your company's revenue.
Last, but not least, your company could partner with the other tools to attract their customers, which would increase your customer base and, your revenue.
So, in summary, your goals are:
- Provide more value to customers
- Increase customer base and retention
- Increase revenue
Another reason to understand your goals is that you could use those dimensions to keep track of business metrics (or KPIs) to help your company to reach them.
Developer experience affects the entire company, not only the IT department. So everyone should commit to this initiative.
## 2) Understanding the developers (a.k.a. user personas)
The second step is to understand who are developers that are already using (or will use) your APIs.
Your goal is to empathize with them. I.e., put in the developers' shoes.
Here are some questions you would ask:
- What are the programming languages they are using?
- What type of APIs do they use or are familiar with?
- What tools do they use in their workflow?
- How do they interact with APIs?
Let's say you've interviewed 1000 developers and the top 3 languages are JavaScript, PHP, and Java.
You've identified that most of them use Postman to test and build API integrations.
You've also identified that the third-party tools your customers are already using also want to integrate into your system because their customers are also asking for it.
## 3) Understanding developers' problems
The thirst step is to understand the problems and challenges developers face using APIs.
You should explore usage of APIs at the highest level, but you can also ask for struggles they have using your own APIs, if that's the case.
These are some questions that you would ask:
- What problems are they trying to solve?
- How are they solving those problems now?
- How do they evaluate APIs?
- How do they authenticate to APIs?
Let's say that after interviewing those JavaScript developers, you've discovered the following 3 issues:
- Poorly documentation
- No SDK/library available for their programming language
- How to get an API up and running quickly
You would pick only one of them to narrow down your solution.
Considering that you've already identified in the second step that JavaScript is the most popular language, you would probably pick the second problem to solve.
Once you would create a new JavaScript SDK, you would also need to write (or update) your existing documentation, and also provide information on how to get it up and running.
So you would kill three birds with one stone! (Pun intended!)
## 4) Think about 3 solutions
The last step is to come up with solutions and evaluate the pros and the cons of them.
I'd recommend 3 types of solutions:
- **Super safe:** a basic solution that will cover all developers' need
- **Aggressive:** an innovative solution that will cover not only the basic needs but also create the so-called WOW effect on developers
- **Disruptive:** a moonshot idea that would change your industry. This one might not be feasible, but it's a good way to explore your team's creativity at the deepest level
Finishing our example, these would be your 3 options:
- Super safe solution: open source SDK for JavaScript + code examples + quick start guide + publish your API documentation as a Postman Collection
- Aggressive solution: Super Safe + CLI or GUI tools covering the whole developer workflow
- Disruptive solution: a tool based on GPT-3 that receives requirements and generates the whole implementation automatically
The key thing at this step is to decide what your team can build in the next weeks or months. Evaluating the pros and cons will help your team to understand which one you should pick.
Let's say you don't have the time and resources to go for options 2 and 3. The Super Safe option would already address the developers' need and you could launch it earlier, as an MVP.
Based on their feedback, you could iterate on this option to improve the experience or even jump to the second option as a V2 of your developer experience initiative.
Considering that you would be open-sourcing your JavaScript SDK and sharing the roadmap with the developers community, you could also create incentives for them to build SDKs for other languages and bring your IT team to support them.
Don't get surprised if some developers build the CLI themselves and share with the community!
It's the actual power of open-source!
## Conclusion
APIs are trending all over the world. With more and more applications and devices consuming enormous amounts of user data and communicating with each other, it's critical for digital companies to have a friendly and accessible API.
Companies that already have a developer-centric approach and are investing on developer experience, are years ahead of their competitors.
Becoming developer-centric might be a big challenge, but the benefits are almost infinite and could have a tremendous impact on your business and customers.
It can grow your company, attract new customers, increase your revenue, just to name a few.
Companies like Stripe, Slack, Zendesk, Facebook, and Google have been benefiting from for years. So are their customers and users.
**Developers + APIs = Business Developers**
That's how you should treat them.
So, what is your company waiting for?