API as a Product: Building an Enabling Developer Experience & Measuring Success.

The fundamental of every API Strategy is the developer’s experience (DX) of an API product. Whether it be an internal developer platform (IDP) or an external developer platform (EDP), the DX is as important as the API functionality. It is, therefore, imperative to build developer experiences with intentionality. All types of users must be accounted for, and their use cases MUST be covered to ensure users can maximize the value of the API platform.

These users include :

1. Developers — The core users who manage the technical aspects of feasibility, testing, design, and integration.
2. The Business — The key decision-makers who are responsible for the commercial aspect of the service offered.

There are three elements in building the API as a product, and the right developer experience is key to enabling a self-service platform for your users. This article will discuss all three and break them down individually.

1. The Developer Console
2. The Developer Community
3. The Business Management account

The Developer Experience

The Developer Console

The console is an environment where developers can play with the tools needed to integrate with the API features. It comprises a developer console landing page, API documentation, sandbox environment, API security, and API gateway. These elements impact the developer experience and how its users make decisions.

• Developer console landing page: This page should describe the value proposition of your APIs, along with use cases.
• API Documentation: This includes the landing page, user guides, and API references.

The Landing page should clearly define the types of APIs available, and their features should be identified by their value proposition. The golden rule here is to use standard nomenclatures rather than internal language. For example, use “Send Money” instead of “Transfer account to account or wallet to wallet”.

User Guides must educate the users on your APIs by including sections such as getting started, definitions of API specification, security, how to go about the process as a developer or a business, how to go live, and Know Your Customer/ Business (KYC/B) requirements for all API products.

API references should include a clear and concise pattern for testing the APIs, and the different response types. It should be a simple test environment with a responsive User Interface (UI) to test each API and endpoint for their different behaviors.

• Sandbox environment: All API testing should be done on the sandbox server, which is the test environment for your APIs.
• API security: To secure an API, you must authenticate a user and authorize each feature. This feature acts as an identity and access management tool, much like the bouncer at a club who determines your level of access, whether regular or VIP. Users must be able to access and manage their access and refresh tokens on the developer console, and request go-live permissions for the APIs. Rule of thumb: Avoid basic authentication as it is not robust enough to secure your products.
• API gateway: This is mainly used for load balancing, identity and access management, access control, monitoring & logging, etc.

The Developer Community

The psychology around developing a community is as important as your API.

Three levels of community strategy:

1. Business level — This focuses on the community and creates value for the business.
2. Community level — This focuses on how to create value for the community members.
3. Tactical level — This is the strategic point where you drive business value using the community as a competitive advantage. It is almost effortless to build products but much more challenging to replicate in a community.

Every business starts with a community of users, such as friends and family, who give product feedback before they eventually find their product market fit. Duolingo is an example.

To enable the tactical level, the developer community is an integral component. This community must be built with intentionality and strategic goals. In my experience, I have built developer communities using the SPACES model from David Spinks in his book, The Business of Belonging.

SPACES model includes :

1. Support: Improve support and help customers (developers) solve problems for each other. The community can also serve as a knowledge base or provide expert resources for users, such as the Asana community forum.
2. Product Ideation, Innovation & Feedback: Accelerate innovation by empowering the developers to build their use cases and sell value through the marketplace. Companies can leverage the collective insight of their community to get ideas for innovative features, identify the most critical changes that will improve their products, and save money and time on surveys — for example, the Lyft Driver Advisory Council.
3. Acquisition and Advocacy (Growth): The community operates as a network of ambassadors who drive awareness and growth for the business. For example, hosting online and offline engagements that speak to your APIs value proposition will improve the API adoption — for example, Lululemon Global Ambassadors.
4. Content and Contribution: The goal is to motivate the contribution of content, products, and services. Distributed content models are changing the way businesses function. From user-generated content to open-source platforms, distributed models allow value to be created by the community, with the company just providing the platform- for example, Google developer groups.
5. Engagement: This should be internal and external, bringing together a group of people around a common interest, in this case, the product, giving them a sense of identity and belonging and increasing customer retention with podcasts, video series, leaderboards, badges, newsletters, etc. The Nike-run club(External), LinkedIn (Internal) are examples.
6. Customer Success and Advancement: Make customers more successful at using software by upskilling how they use the product and empowering the customer to become mentors and instructors for the product. Example: Notion Community.

The Business Management Tool

This tool should enable the user to complete the KYC/KYB process and request to go live. It should also include features such as a wallet and analytics that enable the merchant to manage their API account.

1. Request go-live — The user should be able to upload of KYC/KYB documents and complete the validation/verification process. Once this process is completed, the user should be able to request to go live.
2. Wallet — This enables the business model to implement its testing pricing model. More often than not, the pay-as-you-use pricing model is the most effective for APIs, bar unique cases like that of partnerships with telcos whereby there is a bulk load purchase into a master wallet per a stipulated period of time.
3. Analytics: This is derived from the usage of your APIs and can be monetized as a feature for the API customer to give information such as who is using their services, location, time of use, etc. This data can then be leveraged to serve their users better.
4. User Management: The business tool should enable multi-tenancy so that each user can access the product and multiple users can create one account with different levels of roles and permissions.

Measuring Success

There are various ways to measure the success of the developer experience, and they can be grouped into seven categories:

1. Adoption — To measure adoption, you must track developer engagement in the community, number of API users, active users, and API requests over a period of time (at your discretion).
2. Performance Metrics — Track the response time of the requests made, latency, error rate, uptime, and downtime.
3. Documentation & Support — Track problem resolution time, the number of support tickets created, and the feedback and views of your API documentation.
4. Scalability: Ensure that the request volume, auto-scaling triggers, and resource utilization are tracked.
5. Customer Satisfaction: Churn rate, customer feedback, renewal rates, net promoter score.
6. Rate Limiting: Breaches, requests per account, and per second.
7. Financial: Return on investment, cost per transaction, revenue, revenue churn.

Finally, all of these will not be feasible if there are no policies or processes put in place that make it easy to do the right things and challenging to do the wrong things. This is known as API governance, and it enables consistency, security & compliance, and efficiency while providing a standardized framework for managing the API platforms, whether internal or external.

I look forward to sharing more about API governance, but until then, check out API Integration 101 & leveraging APIs to 10x business revenue.