You've read the articles, attended conferences and webinars. You understand the intent. Ecosystems. Embedded business models. Collaboration opportunities beyond the boundaries of today's customers, supply chains and partners.
All are made possible by APIs as products.
Imagine your organisation manufactures specialist machinery for industrial clients around the world. You’ve been researching the opportunity for a digital API product that complements your physical product heritage and experience such as described by Marjukka Niinioja.
You have narrowed in on an API product idea: a carbon footprint calculator for your machinery. This expects to interest customers wanting to provide better visibility of the green credentials of their key suppliers. Some software companies also seem interested in being able to build this type of feature into their offerings: they are looking for an edge with similar customers to yours.
So the WHY? for this API product opportunity stacks up, and it connects to a more eco-friendly and sustainable business model for the future. It would seem like a no-brainer.
However, you're facing resistance. Resistance from colleagues, funding bodies, steering committees.
It feels as if you are spending more time explaining why this is important, or justifying why to go ahead, when you could be focused on taking API products to market. You want to be getting out and talking to new or prospective partners. Designing and building great APIs. Testing their impact with customers.
So why is it that others aren’t on board yet?
Finding the right home
For organisations that haven’t "grown up digital", it’s common to find some of the great APIs-as-product ideas stalling. Without an obvious team in the organisation to drive ideas through to execution, they risk being orphaned.
In our example of the industrial sector business, the sales and marketing teams might align with specific geographies. Or with established customer market segments such as utilities, construction or transportation. The product development teams may be unused to collaborating closely with IT experts on getting value from underlying data sets, and working on the developer experience that will form part of the go-to-market.
The company-wide transformation program is more focused on strengthening the supply chain and digitising customer processes. Meanwhile people with the best technical skills to articulate some of the potential may not have the right customer knowledge or access.
The main streams of investment are into teams aligned with today's ecosystem. These include: current customer/market segments, today's business process domains, or existing technology assets.
Without an obvious candidate to take the lead on behalf of everyone else, it's hard to find a group to get behind the new product opportunities.
Measuring differently
Wherever the centre of gravity for API product thinking ends up in the organisation, it will certainly involve collaboration beyond traditional organisational boundaries.
For our machinery business, imagine you’ve got through this. People are successfully on board with your API product opportunity. In fact, successfully enough to have earned you the responsibility and seed funding to pull a team together and bring it to life.
As you reflect on what your role as an aspiring API product manager will look like, you get going on the roadmap and investment case.
From different ways of monetising APIs—such as explained by Matthias Biehl in "5 Patterns for API Monetisation"—you’ve identified software businesses that could be candidate users for your API product. The proposition to them is that it is easier and better over the long term to use your APIs than to try and build capability themselves. You've also got sales colleagues pressing for customer-oriented APIs to move on from their current rigid ways of integrating with your core processing systems.
Each case points to use cases for "embedded" business models. The opportunity for firstly establishing new channels—software partner organisations in this case in the burgeoning xTech space—and, secondly, for expanding into new ways for existing customers to get more value from their current products. Both align with the enterprise's wider strategic agenda to expand into new models; and to make an "ecosystem play".
However, the numbers don’t seem to stack up.
This is a common challenge at mature organisations. There are other ways to evaluate investments, such as those described in Geoffrey Moore’s “Zone to Win: Organizing to Compete in an Age of Disruption.” However, it’s still common practice to evaluate investment opportunities based on familiar patterns such as efficiency, revenue growth or compliance.
So a cloud migration plan or a process digitisation might deliver significant savings based on today's costs. This efficiency model is well understood financially and can be easily measured up against the benefits of an alternative investment opportunity.
Meanwhile, you’re asking to support a productised API-enabled business venture. It’s targeted at potential developers-as-customers for them to unlock the value of your own organisation's data to help their organisations colonise new markets. And it might take a few quarters to realise its potential.
This can be a hard sell when compared to something that can free up some short term IT cost savings that will be realised in the next three months.
Of course, a complete overhaul of the organisational investment prioritisation process might get your initiative higher up the list. However, this is a much more far-reaching change. At a practical level, getting serious and getting going with API productisation in today's model may mean putting some investment aside with different payback and success criteria. At the very least, testing the market to develop some proof points will help show people the bigger potential.
Finding the time
Once you’ve got committed investment, it can still be challenging for stakeholders to give your initiative enough time, effort and attention. It’s likely you’ll need input from a wide variety of teams and stakeholders—such as sales and marketing, product and pricing, security, access and identity, customer support etc—while there is so much else on people’s plates.
Customer process digitisation; remote working infrastructure; strengthened cyber defences; or supply chain risk mitigation are among the many technology-related investments high on organisations’ priority lists.
APIs arguably contribute to many of these, and so it may be practical to start building productised API opportunities on the back of them. You or your colleagues could be bedding down API management, governance, standards and the like. You may be implementing your second generation APIM platform—or maybe consolidating multiple gateways and solutions onto a single platform.
Getting going
It could even be that APIs are proliferating through the organisation more quickly than the necessary design standards, continuous delivery environments can keep pace. Or, once delivered, quickly as part of an initiative that has moved on, API maintenance risks getting underestimated or forgotten about.
It's never too late to get started on building muscle and experience in thinking of your APIs as products with a strategic direction, a reason for being, a lifecycle and associated funding.
This can also be a reason why taking a two-pronged approach: 'cleaning up' the API portfolio that is in place today, while experimenting with external-facing APIs-as-products can help build expertise and competence. You don’t need to try and answer the bigger, harder questions such as how to change funding or operating models before getting some practical experiences in place.
Productised APIs for many require different ways of looking at opportunities, and getting value from these to build continuous learning and feedback from customers. Shifting to this type of thinking is best done with a combination of education, communication and demonstration of proof points.
For the imaginary carbon footprint calculator, the sooner an early prototype gets into the hands of a first potential software partner or transportation customer, the sooner you’ll get feedback and insights into the potential. It may not get expected results either first or second time, but with focus and rapid feedback loops, you’ll be able to collaborate with them on realising the potential.
The key thing is to get going. Start small and keep it tight. Learn. Repeat.
About the author
Claire Barrett makes strategy happen and notably API-enabled business and technology change. She is a director at APIsFirst, a founding member of The API Collective, and global lead of Women In APIs. Opinions expressed are those of the author and do not represent the views of any individuals or organisations. Photograph is sourced from unsplash.com.
Comments