Is an API a product like any other? How are we managing API’s at Proximus EnCo? Are our consumers also our customers? How are we interacting with developers? Here is a paper from Pierre d’Ollone, product manager working with EnCo on the SMS API integration.
Managing API
As a product manager working on APIs, I am very often confronted to others’ puzzled look when explaining what it is that I do. Indeed, APIs are technical in nature and if they can (or should) be considered as products too, it’s not obvious to everyone what there is to manage as a product (even for technical people that really just think that it’s another marketing buzz)… After all, aren’t APIs just technical enablers without any users? Does that mean they can’t be treated as products? Obviously, the biggest difference with traditional software product management is that APIs are a lot less UI driven. Indeed APIs are used by computers rather than humans, but that doesn’t mean that they can’t be considered as products or services. According to the businessdictionary.com, a product is “A good or service that most closely meets the requirements of a particular market and yields enough profit to justify its continued existence.” (Source). At Proximus EnCo, that’s clearly what we’re trying to achieve… and seeking the right product/market fit is one of the most exciting challenges that any product manager must face. For APIs, this translates into “building stuff that Developers will want to use to solve a problem, programmatically”.
“The API consumers”
That’s where it gets interesting. Building an API product is sometimes more complex than just pleasing the developers, as they will usually have their own customers or end users to satisfy. So, should we ask the developers or the end users? Well, both!! Actually like any other product, you look at the market through competition analysis, market survey and trends, interviews with prospects or existing customers, usage statistics, etc. At Proximus EnCo we usually look at our API requirements from at least two angles:
- the domain in which the API is built and the services that it provides in order to solve a problem (For example, sending SMS alerts)
- At Proximus EnCo, we try to build one API platform that unifies multiple domains: IoT, Telecom, Cloud and Big data. This requires expertise from the various domains and we usually have various product managers involved from the different domains. This entails nice planning skills and a taste for compromise ;), but more than anything it means that we need a good understanding of the ecosystem and market dynamics.
- the basics of any proper API in order to make our developer community happy (For example, fast response times or properly documented error codes)
- Since the developers are the ones which will either directly make the purchasing decision, or at least heavily influence the buyer, Proximus EnCo needs to pay special attention to making them happy. In this article, I will further explain the interactions between Proximus EnCo and their developer consumers.
“The developer consumer”
It would be too easy to categorize developers with typical clichés such as “introverts”, “nerds”, “hackers”, “lacking business acumen”, “technical genius”, “wearing glasses and typing mysterious code while eating pizza and drinking coffee”, etc. It is true that certain traits are common to all developers, e.g. they are usually looking to fix a concrete problem in the most elegant fashion, which means writing as less code as possible. But in all fairness, there are many types of developers, ranging from amateurs to the more college-educated ones. Some will be more into building a beautiful, scalable, maintainable piece of code, almost like an art-form. Others will be more into a down-to-earth pragmatic problem-solving approach. Some developers will want to hack existing code, when others will prefer to fully write their own stuff from scratch. You could even argue that the same developer could code differently depending on the product that he is working on, his experience level or the culture of his team (peer pressure). The bottom line is that, at Proximus EnCo, we need to target different types of “consumers” or “cultures”: the makers community (https://en.wikipedia.org/wiki/Maker_culture ), technology start-ups and innovators, more established tech companies with larger teams of developers, and even bigger non-IT or governmental corporations. So what kind of interactions do Proximus EnCo have with their developer community? How do we communicate with them and what tools or features are essential to making them happy?
“Developer interactions”
According to me, one of the key things to grab a developer’s attention is to be very specific and have a very well structured documentation. Proximus EnCo has a self-service based model. We don’t actively sell by making phone calls, showing demos or organizing business meetings one after the other. Obviously our goal is to be recognized as a brand in IoT, Cloud, Big data or Telecom APIs but we historically serve developers that usually have a rather precise idea of what they want to accomplish. Therefore our website is organized so that the developers can quickly find the API they want to use, read the technical documentation, create an account, test, and ultimately pay for the service.
Documentation and testing
One of our business assumptions, based on our experience, is that developers wish to quickly be able to test the APIs. So even though it is key that the technical documentation is always up-to-date, a lot of developers will actually skip it and go directly to setting up their first API calls. This can be a frustration for a product manager (or the support team) who has spent time on the documentation (we are very often tempted to reply a simple and direct “RTFM!” to a customer asking a dummy question), but this is something that has to be acknowledged as part of the “normal process”. Here’s how we try to help and minimize friction at this time:
- Part of the documentation is automatically generated which means that it should always be up-to-date. But for the highest possible quality we believe that manual work is necessary, and to be honest we’re not there yet! By the way if you have ideas on how we can improve our documentation, use the comments and let us know (be nice thoughJ)…
- API consistency is also an everlasting work in progress. On top of making it RESTful (we’re trying hard to follow the standards), we should also be coherent throughout our services, reduce the amount of exceptions, increase reusability, follow naming conventions, error handling. Even though APIs are ultimately consumed by machines, a developer will use it…
- We try to provide code samples and demos. They can usually be found with the documentation, making it easier to read about a feature and test it at the same time. During the testing, it may also be helpful to make debugging easy which can be achieved by adding well written user facing logging.
- Using an API means that an API client needs to be developed in a certain programming language. Providing SDKs in various languages can help our programmers. We’re still debating internally the best approach (e.g. automatically generating SDKs with lower quality but less maintenance on our side and more languages covered, or manually write ones that are either maintained by us or our community).
- We provide special free trial accounts so that developers can test our APIs. This requires the right level of freedom for enough testing to happen but not too much as to compromise our operations. We had a lot of internal discussions on whether to have freemium accounts (that never expire but have limitations such as throttling) or trial accounts (that expire after a certain time but have no throttling). We created both types and will see if it makes sense to keep them both in the future.
Pricing / Business models
After documentation and testing, it is decision time… and there’s one last hurdle before we can get the developer “hooked”. APIs can be used in various types of business models.
Usually developers have their own existing application that is doing X and Y. Consuming an API will allow them to do X, Y and Z, which is expected to add value to that existing application. The developer will end up evaluating the value of Z based on the following questions: is it a mandatory or optional for my product? Does it have high or low added value? Will it differentiate me from my competitors and how? What’s the cost / benefit ratio?
Another entirely different way is the “broker” model whereby a developer uses an API doing Z and repackage it so that it still does mainly Z, but with some extra customizations or specific extra integrations that are relevant to a niche market.
Those two different models have a huge impact on the way our developers perceive the API product. This essentially impacts the way the account management, the billing or the reporting work. In the first case, the developers will only require a basic account for all his transactions. At EnCo, we see a lot of those types and they usually are smaller companies and start-ups which need a less risky “pay as you grow” model. In the second case, “brokers” need more advanced features. They may need to be able to manage multiple sub-accounts (something we are working on) with a suitable billing and reporting (e.g. per sub-account) to make things easier on their side.
Technical support
Another of our assumptions is that the support needed by developers for APIs is different from most other product types. As developers progress in their understanding of the product they will quickly want to start testing (as described earlier). The amount of effort and the type of resources required to support developers hacking their way through your APIs are very different from other types of software products. Developers usually need to talk to like-minded people, preferably developers that have a good knowledge of both the functional capabilities and the technical constraints or limitations of the API. This leads to organizational challenges within the support team and often implies a higher need for domain and technical experts. At Proximus EnCo, we try to overcome this with a high degree of people interactions, collaboration and knowledge sharing. We use Scrum to form a multi-disciplinary, autonomous, self-organizing team which, we hope, results in an ever increasing product quality (meaning less support is required) and a more knowledgeable support team.
More pragmatically, we also have tools to help us troubleshoot. We use Splunk to better manage and analyse our logs. The right level of logging and what we do with it is key. When we get some client logs, we can quickly match those with our own logs and identify possible reasons for customer issues. Also we can have a more proactive approach with Splunk. Indeed, we can add intelligence to our logs by finding patterns and using those to either fix issues before they become impacting, or automatically inform customers of identified erroneous practices.
Marketing and communication
Lastly, despite the technical nature of the product, it doesn’t mean that APIs have no marketing and communication activities. To meet developers, Proximus EnCo regularly participate to hackathons as sponsors or participants. In these events, we help, coach, or even actively code within a team of non-EnCo developers. We obviously have our own internal prototypes or demos using our APIs. That’s always fun to work on concrete examples and use cases of what the APIs can be used for. It’s also a good practice to test your own product as if you were the customer (in other words: “Eat Your Own Dog Food”). We sometimes organize workshops in our offices and invite developers to concretely work on such prototypes. For example, one of those workshops was related to the EnCo – IBM Bluemix integration. The goal was to share expert knowledge on a specific topic, and get immediate customer feedback at the same time.
There is a lot more that could be said on API product management and more specifically what this means in terms of customer relationship. Whether you share my views, disagree or think that more can be said, I would be very interested to know about it in the comments below!!
Also, very importantly, we are currently running a survey on our EnCo’s roadmap candidates. If you have 5 to 10 minutes, any feedback would be hugely appreciated!