APIs. If you haven’t heard of them, then start reading. They will be the foundational fabric that binds the next generation of the web, and in many ways, they already are. Think about how many apps and website are connected to your favorite social network like Facebook or tools like Google Maps – those are powered by APIs.
- The identity of the company is rapidly evolving from a legacy financial services company to a cutting edge technology company. APIs are one way the company is doing that.
- Employees and customers alike are excited about this. I am often approached excitedly at developer conferences and literally thanked for being there representing the company.
- There is a tremendous amount of value that a company like MasterCard can provide, whether in be in the areas of payments, fraud and risk mitigation or data services, for example.
I thought I would share some recommendations from experiences I’ve had along the way:
If you’re working within a relatively large organization where many stakeholders are responsible for ensuring (and/or allowing) the growth of your group, then take the time to properly educate them on what you are trying to do and the importance of it in the context of the market. Once those primary stakeholders are excited about what you’re doing, that excitement will spread throughout the organization, and your efforts will be more easily accomplished and more rewarding.
Building the Right Products
At MasterCard, there is no shortage of API products that we could build. Like any individual or organization, however, there is limited capacity. Make sure you build products that prospective customers will actually use. Perhaps the best option is improving services you already have rather than creating new ones. In any case, you need to understand your own goals and plan appropriately.
Having a Capable Platform
Similar to building the right products, a platform capable of managing your API products is essential. US-focused products, for example, will require very different architectural support versus global products in terms of both content and usability. When building platforms, it is important to take a long-term and realistic view of your requirements. Your platform construction will also depend heavily on your product architecture. For example, if you are building a service that requires a server to make several calls to your API per use case it may make sense to test your own platform against a relatively high transaction per second (TPS) scenario – you don’t want unnecessary call failures because of the popularity of your product, after all.
Engaging Where It Matters
In my mind, there are primarily two different types of API customers who can be engaged: in typical sales / business development scenarios with larger companies, or within the general developer community. The former may very well be a continuation of existing processes. Just tell your sales people that they can sell products with similar or the same value propositions as existing ones but with significantly lower integration costs for customers and they will be all for it. The latter type of engagement is much more difficult, however, and could probably take up a post on its own. The best way to be successful is to be present in the developer community in a grassroots way. Attend meetups. Go to those demo days. Be recognizable. Be branded (not quite NASCAR-style, but not too far off, either). Build a community around you and the products you represent.
Support Can Be Tough
Supporting developers who are trying to or are currently using your API products can be extremely encumbering on both sides, but there are ways to make it easier and good things can come from this type of engagement. When it comes to in-person support, thorough understanding of the products and major languages is necessary. You can decrease the amount of support required by having awesome, humanized documentation. In-person support provides a great opportunity to help inform your development roadmap, as well. Digital support is best provided expeditiously. That means using Twitter, email, web chat, etc. Don’t forget about regional differences – while most software development occurs in English, there may be language barriers linked to (non-software) language.
Recruiting and Deploying the Right Talent
Everything about APIs is technical – the platform, the product, the documentation, and the customers. It is important, therefore, to have a team that knows or has the capacity to learn technical details. Everyone on the team doesn’t need to code, per say, but everyone must be able to communicate with each other clearly. You also want people on your team who want to be doing what they are doing and want to do it in the best possible way – as Steve Jobs said in 2005, “Stay hungry. Stay foolish.”
This goes for any type of product management, but it is very important to measure as much as possible. There has been a lot of material written about measuring success. I recommend watching this GV presentation on OKRs and reading up on the subject. Measuring correctly will allow you to quickly make course corrections as you build and scale your developer program.
What are your thoughts on building successful developer programs? Tweet at me with #dev, and let me know!