APIs have been around in the technology space for more than a decade but some companies have only started embracing them in the last few years. There has been a need for specialized skills to transform the legacy product suites of many companies and leapfrog them into the digital age. Roles like API evangelist and API strategist have been created to facilitate transformation across different sectors including fintech. Companies are investing heavily to kickstart, revive, and/or accelerate their investments to have a robust API program. APIs became even more relevant during the COVID-19 era as employees were unable to access custom software solutions remotely, forcing vendors to provide the same information on-demand through solutions like APIs.
APIs became even more relevant during the COVID-19 era as employees were unable to access custom software solutions remotely.
Having an in-house API program allows companies to disrupt rapidly and drive revenues in the long run. One of the pitfalls to avoid while establishing an API program is to contract out the initial work to third-party firms that specialize in packaging and releasing APIs. Though this strategy works in getting the program off the ground, it often results in a sub-standard API experience in the long run as there isn't enough knowledge within the employee base to support and enhance the developer experience.
There are three stages to incubating an API program: awareness, implementation, and go-to-market. The awareness stage begins with development teams starting to unlearn some of the traditional development practices and embracing the API lifecycle.
Each stage has its nuances and API teams should keep the end-user in mind during each stage of the lifecycle. Adopting an outside-in approach by consulting with prospective users and understanding their digital transformation pain points allows firms to meet their users where they need the most help. It eliminates a common pitfall of the inside-out approach of releasing what's easy to build versus what's easy for the user to use.
Education and training of non-engineering functions is another important dimension in the awareness stage. Collaboration between client-facing and engineering teams for pitching and selling API products allows sales teams to shorten the sales cycle and creates a tight feedback loop between development teams on the vendor and the client side. Development teams can also work closely with sales engineers to learn about the sales cycle, develop tooling to mask API technical intricacies, and partner with technical writers to build robust documentation.
Collaboration between client-facing and engineering teams for pitching and selling API products allows sales teams to shorten the sales cycle and creates a tight feedback loop between development teams on the vendor and the client side.
At the onset of the implementation phase, it’s imperative that API teams are empowered to make decisions at all stages of the lifecycle. Once the API is ready to be shipped, API teams should define quantifiable metrics that are closely tied to the business metrics so that success criteria can be decided before the API moves to the monetize stage. Business metrics such as "number of users," "net revenue added," and "number of API calls" might not be the best metrics to track API quality and usability when starting off, as they focus on the end result, which may not be directly controllable by the team. A better approach is to come up with metrics such as "reduction in onboarding time," "user confidence in API stability through controlled releases," "X% uptime," and "Y% data coverage" as they allow the team to iteratively track and improve the product which in-turn drives up the business metrics.
The go-to-market phase involves monetizing and presenting the APIs so that technical and business users see the benefit of using them. Business users tend to value insights into how a vendor API can help improve efficiency and reduce cost to the business. API teams can work closely with sales teams to build the right collateral tackling these questions. Technical users tend to focus more on the technical parts to ensure that the API is easy to use, well documented, and releasing changes at a regular cadence. API teams can address these areas through webinars, hackathons, developer portal blogs, and other such forums.
Business users tend to value insights into how a vendor API can help improve efficiency and reduce cost to the business. Technical users tend to focus more on the technical parts to ensure that the API is easy to use, well documented, and releasing changes at a regular cadence.
Every successful API vendor has spent years learning, adapting, and designing APIs that solve their clients’ challenges with a strong focus on governance. Governance and enforcement of development standards ensure consistency across all APIs and creates stickiness as users can rely on consistent policies. Standardized Software Development Kits (SDKs) in different programming languages, consistent API versioning and retirement policies, and easy availability of usage data are some examples of artifacts that help build confidence in the program and reduce the onboarding time. It's important to be nimble and iterate quickly rather than waiting to release the perfect API to market. Remember that an API program isn't a sprint but a marathon!
Mr. Akshay Sheth is a Vice President in the Analytics & Trading group at FactSet. In this role, he manages multiple engineering teams focused on developing APIs and solutions for portfolio management. As part of FactSet's API Steering Committee, he helps define development, product standards, and ensure consistency of APIs across different groups. He joined FactSet in 2012 and prior, worked as a software engineer building distributed system platforms and microservices. Mr. Sheth earned a Master of Computer Science from Georgia Institute of Technology and a bachelor’s degree in Computer Science from Mumbai University.
The information contained in this article is not investment advice. FactSet does not endorse or recommend any investments and assumes no liability for any consequence relating directly or indirectly to any action or inaction taken based on the information contained in this article.