Making things happen around your API
Once a company has made the strategic choice of implementing its software solution with an API, it can expect that a lot of developers will start using it. But this is not straightforward and the path is difficult, sometimes dangerous for a business in places. Providing an API needs the whole team’s commitment; it’s a paradigm shift. In this article we will see how we can help API adoption, considering a business case where it adds actual value.
Industry transformations
A software product might expose an API for several reasons. It could be a never-seen-before product, like Facebook, Snapchat or Github, fully built on technology. It could be a disruptive innovation which transforms an existing market, like Uber or AirBnb, whose features can be integrated in other apps. But, it is simply often about improving an old industry using web and mobile software. Any industry: retail, printing, manufacturing, agriculture…
It is not necessary to expose an API for every business case. There must be a need somewhere, other people than us willing to use it and develop around. The good news is that the old industries are progressively understanding this need. Some of them start investing into technology through sales, marketing, and even software because they understand it is important for them in the future.
Becoming a technology company
Exposing an API provides software the capacity to become horizontal: whatever the business case is, any application can use it and add value to the experience. This way, the company that exposes the API does not only address a business problem; it is also a technology. It becomes possible to create a pure tech offering targeting developers. Then, the business builds a developer community around the API: subscribing users ensure a stable revenue, they handle the use cases and business issues themselves, and they sell the idea to the end customers. The community allows the API provider to focus on performance, support and service value.
Projects or even whole businesses need to be able to rely on an API provider. Providers improve their responsibility and control: if a customer doesn’t want to pay anymore, or isn’t ready to adapt to new rules or structure, they have the power to turn off the tap, change specifications and eventually kill the project or the whole business. On the contrary, if they have a strong partnership with some specific users, they can dedicate infrastructure and optimize the effort to offer a better performance to them specifically.
API providers benefit from the value of every piece of information passing through their network, like clickstream data or any valuable information. This can be attractive as data represents lots of value: additional revenue when sold but also use rate information, pricing indicators…
However, this “I am a technology” position is very difficult to acquire. The provider also has a problem to solve, a need to respond to. And even if it exposes an API, its own front-ends are most of the time their own and only API consumers. When launching a new API product, we can still be confronted by customers who say: “I have money, I need to do what you offer, plus a little piece of software I can’t do myself. Would you do it for me?”. And “no” cannot be the right answer; some day there has to be an income. This equation is the most difficult to solve: becoming a technology company while making money and satisfying end users.
Onprint: an image enrichment solution, with an API inside
Onprint (onprint.com) was created to answer to the need to add more value to printed documents by enhancing them with Web content. Onprint couples image recognition, search, and links to Web content. The service part aims at helping editors, printing companies, creatives, marketing teams to do it the right way.
The product has always been thought as a Software As A Service (SAAS) platform. It offers an API which tries to respect the standards and the document itself. Even if a lot of customers prefer accessing Onprint through the included Web and mobile tools (edition.onprint.com to edit the images, whitelabel mobile applications or the onprint application to scan them), a few of them are also tech savvy and it is more interesting for them to access the API directly.
Providing an API allowed us to stop having to respond to all the customer demands that were too custom and not our core business (we are often asked for online gaming, advertising apps or websites, augmented reality…). We still make concessions and we are still okay to develop some of them, regarding the opportunity it represents and what we can learn from it. But we know that our mission is being a technology platform. Everyday we look for the right balance to respond to needs and provide service as a platform.
Knowing your customers: a maturity model
A maturity grid can help understanding better the different problems of customers, who could possibly need an API, and how to respond to them. The idea is to sort out the different needs and the different products the company offers and know where to put the effort and what service to provide. As an example, here is the Onprint customer maturity model with the different offers we provide regarding the type of customers, which we categorize into 3 levels of ability to code:
As mentioned in the introduction, we generally have noticed a trend towards more and more ability to code in all businesses across all types of industry. As a software business, our role is also to help our customers improve their software abilities. We are satisfied when discovering that a “Low ability to code” customer becomes a “Medium ability to code” one, and when the “Medium” one becomes a “High ability to code” one. The challenge is about supporting every level at the same time.
Great support and software quality
Every level of ability to code has its need of support. Obviously these needs are different: Low ability to code ones have not planned to spend innovation time on the solution. They need adapted productivity tools, training and service. Tools can be Web or mobile applications built with the API. They have to cover the main end-user experience on the product. This is a good opportunity to create reusable code libraries and samples, like SDKs or Web components.
Medium ability customers also need the same tools, because they provide the most straightforward path to get what they need. But their needs may not be fully covered. This is the beginning of a project with them, where it’s better to give them support and help them find partners to develop their technology than to do it for them and charge them for days as any software service company would do, even if sometimes there is no other option. Giving them support will help them grow and gain more ability to code.
The third customer segment represents the ones who are most able to develop and could build their own tools. They will need the highest level of support: phone, visit, reactive email, so that they have no barrier on their path to the API adoption. If getting started is easy, they will be the best promoters of the solution. They can be indulgent with bugs, if they are taken quickly into account and if the API provider team is transparent with them. Communication is always easier because it’s developers talking to developers. Finally, they must feel comfortable and welcome to give feedback.
Taking care of the developer community
Here are the 5 major actions to consider to create a developer community:
1. High quality of core development, backend and API. Few bugs, easy to maintain, standard, easy to understand.
2. Being available directly, at least at the beginning. Then keep it easy.
3. Create a nice developer resources website with samples, quickstarts, as well as the API reference documentation (which can be automated with Swagger or something).
4. Write code around the API: also useful for the customers who do not develop, the SDKs are much appreciated and save time and duplications.
5. Communicate on developer platforms like ProgrammableWeb
It is vital to make a good impression and satisfy the customers who can code because they represent a new generation and the future of the product. They are the ones who see our product as a technology platform and invest on it. The birth of a product ecosystem around an API takes a lot of time and commitment. The market is not always ready, and the problem it solves is not always clear. But once it’s in place it can bring a huge potential to an industry and transform it forever.
Thank you @degoodmanwilson for your advice and help