One of the fundamental aspects of any API Program is Organisational Alignment.  In practice this means bringing together stakeholders from both IT and the business to engage on the issues, opportunities, competencies and organisational values inherent in adopting an API first or API as a Product approach. At a base level this can also mean looking at the current roles within the organisation and assessing whether they are sufficient to achieve this approach or whether new roles are required and this is especially true when it comes to looking at organisations providing APIs as true digital products.

Excelsa recently had the privilege of providing an initial set of advisory services around API strategy and API consumer engagement to an Australian Federal Governmental Agency. This Agency is already recognised locally and internationally as providing world leading API products and one of the key stakeholders for our advisory work was a digital services product owner whose portfolio of services included a core set of transactional APIs. 

We will come back to some of the work we were able to do with this Agency in later blogs but I thought it would be useful here to really look at what this role means, whether it is called  ‘API Product Manager’ or ‘Digital Services Product Owner’ or ‘API Product Owner or anything similar, as this is still a new concept to many organisations but is critical for the success of any API initiative.

Until now most organisations have left ownership of APIs to be the responsibility of the IT department and this is the right approach for core system and process APIs (systems of record and systems of differentiation in the Gartner world) but when it comes to APIs that are sitting on the edge of the network that can be consumed by external parties a different mindset is required as these are true digital products.  

Does the role of API Product Owner differ from a ‘traditional’ software vendor product manager. In a lot of aspects probably not – there is a need for a well thought out business case for why the product needs to exist and who will buy it ; for a clear, customer driven roadmap ;  for a properly documented product lifecycle from initiation, build, maintain through to end of life ; for education and evangelism both internally and externally ; and for being responsible for the ongoing reporting and success of the product.

So what’s different ?  I would argue there are 2 big differences. Technical autonomy and ‘value network’ awareness.

Technical autonomy means having a relationship of trust with IT (an API product owner will typically be in a customer experience or digital experience team rather than the IT group) to the extent that the API Product Owner can build and maintain their own APIs at the experience layer. Low/No Code platforms provide the ability for non-coders to build these APIs utilising the IT build core APIs and modern API Management systems provisioned by IT enable the security and operational oversight to enable this trust and expose the resulting APIs. This allows a much more rapid response time to customer needs and changing market requirements not seen even in other digital products such as traditional web services. 

Value network awareness is a little more subtle as a difference. Given the nature of API as Products an initial business case will typically be built on a B2B use case where the second ‘B’ will be existing customers. However, in reality the value chain or value network will actually be a B2B2C or B2P2B or some other variant where ‘P’ in this case is a Platform provider. Use cases and customer requirements will crop up that were never envisioned from the existing customer base and the API Product Owner therefore needs to be able to adjust to completely new business models and potentially new industries as end customers. An exercise in value network analysis and mapping, part of the Excelsa API Program approach, can provide a lot of that new customer interaction but completely unforeseen scenarios will still arise and the API Product Owner needs to be aware of this possibility.

These differences actually make the role much more creative and demanding than would first seem.

For more of our thoughts and advice on the role of API Product Owner and other new API specific roles that enable an API Program please reach out via this blog or at info@excelsa.io