Defining value in the age of Platforms and APIs - Part 2

In the first part of my little series we took things really slow and gentle. This time, we are getting to the more debatable aspects of API powered Platform Economy.

Products are not projects and platforms are never projects

Let’s just walk through one important assertion that almost always pops up when platforms, APIs and in general “digital transformation” is being discussed. The assertion that a platform way of thinking about value propositions is forcing most organizations on earth to let go of structures and core beliefs that are deeply engrained and conditioned over a long period of time. Examples include, separation of concerns by departments, product focus with product management usually the main discipline, split functions that need to work intertwined for greatest pace and productivity. Ultimately for innovation as well - but in reality, are not designed for it. If you ever ran a tricky change initiative you know how many visible and invisible hurdles there can be within an organization to innovate. The metaphor used there is “inertia” as a result of a big structural weight and therefore little maneuverability.

Inertia has the potential to become dangerous though. With customer behavior going into all directions, expectations on the rise. Competitors both known and unknown having access to advanced services cutting away the comfort of being an established player with plenty of head start and a massive entry barrier behind. With these things in motion, things change. Now, companies have no choice but deal with data science, making sense of massive volumes of data, integration of systems that never before saw the light of the public. Now, companies realize that annual or half-annual releases of code do not reflect the reality of taking advantage of latest and greatest opportunities anymore, nor does it help that systems that were built to be locked up now have to be opened up to the world for premium experiences, better offers and much more.

Now, all these things have to change - to stay relevant and eventually, even stay in business.

Platforms often accompany digital transformations, and platforms always beg the question how serious your efforts are. If you are serious then in the light of all mentioned there is no way you could treat a platform initiative as a project. Which is another big change of thinking about delivering pretty much anything in most organizations where all deliveries center around projects.

Instead, your aim would be to continuously develop and deliver value by experimenting and measuring all along the way. Yes, planning is important, but eventually you need to understand things do not unfold according to plans and what makes your initiative sustainable is your ability to change course. What your platform inevitably is from day one is a product. It lives, breathes and requires careful management. What it is not is a project which has a definite start, a definite end a checklist of success criteria to tick off.

Apigee talks about the product mindset in this context.

"An API product mindset means designing and delivering APIs for long-term value at scale, and evolving them over time to meet changing customer needs."

"APIs are much more than system integration technology. They are strategic assets that give companies the speed and agility to satisfy ever-changing customer needs and gain a competitive edge."

To illustrate why a project mindset and a product mindset are fundamentally different, let’s see how Apigee stacks them up against each other.

“At its core, an outside-in approach to building an API is about an obsession with the customer— i.e., relying on customer needs and preferences to guide product strategy. The outside-in perspective is data-driven, avoids making presumptions about customers, and considers both developers—the API’s direct customers— and the end users those developers serve. An inside-out approach, in contrast, tends to either base strategies on the resources IT says are already available or on an internal presupposition about what developers and end users might want or need.”

While it’s easy to acknowledge it makes sense that a platform with all its APIs would not be one discrete project as such but rather a product, the reality of how e.g. funding or running projects and programs work in most organizations are not helping. If you are looking of the short-term profits then platforms and opening up APIs are probably only cause you a big disappointment. Long-term you may get into much bigger trouble though if you don’t embark on that journey.

And to be a little bit less abstract, here is a practical how-to guide for an API (product) that everybody can be happy with:

https://medium.com/api-product-management/api-product-ideation-and-validation-aef140db00b

A great write-up that summarizes the whole thought-process behind an API that people will use and that does add value. I will write a lot more about how to get started with your personal API story. For now, let's sort out the meaning of outside-in first.

Classic vs Outside-In Assertions

As mentioned before, outside-in as Apigee coins it basically means looking at capabilities and functions in a holistic manner, with user/customer lenses on. Classically APIs were predominantly seen as technical integration tools. A more up to date take on APIs and the platforms powered however extends that view quite a lot. That updated view takes into account all the growth potential of diversifying distribution channels and cross-pollination across different services and offers. That said, products will always have their important place, however services are where the potential is. Microsoft knows it is and is moving full speed away from a product centric to a service centric organization.

Now, a distinguished view of mine on APIs and platforms, taking an outside-in viewpoint, would look something like this. (Check out the original Google slide for additional content.)

In the middle of the diagram you have the basic ingredients of a (technical) platform. To the top you have all the aspects that live up to the "classic" assertions of APIs of being handy integration tools. Of course, APIs definitely are exactly that. Nevertheless not only that and that is reflected in the bottom part that discussed the outside-in assertions.

And never forget that this change of mindset has far-reaching implications for the organization.

Of course, others have published their view on outside-in as well, for example Bloomreach.

Check out their whitepaper named “API-led Commerce”.

It’s pointing out some key differences between how they see outside-in taking a different approach than traditional “one stop shop” tools. The key point is staying flexible and agnostic to change course whenever and whenever needed. In a world that sees experimentation more and more important to figure how to deal with changing expectations, certainly a good idea. Speaking of living up to changing customer expectations and in particular in the field of e-commerce, another good read would be “APIs for Modern Commerce”. The theory there being that experience focused commerce without channel boundaries demands rather service compositions than one-stop-shop solutions. Glued together via a “digital experience platform”. I was giving a talk about experience platforms myself and would back up the argument about experiences taking center stage anytime.

The promise of digital experiences falls perfectly in line with Outside-In. Outside-in assertions are not new to the industry – in fact, all major players today acknowledge that the world of tomorrow holds different business models and growth opportunities. Driven by a change of culture and values as well as omnipresent interconnectivity.

Mercedes Benz is developing an API platform right now, with Cloud Reply as their service partner. They are overhauling their infrastructure as a result of the recent mergers of DriveNow and Car2Go, so it's a big integration project as well.

And thanks to Tesla's open API you can built IOT buttons that open up your Tesla.

Allianz Insurances are opening up their services and assets to the public as well – setting out for an “insurance ecosystem”. “An open marketplace of ideas where businesses pool capabilities in insurance and software is a ‘combination that’s hard to beat’. Allianz aims to have built a network that benefits the entire industry.”

Of course, at the same time newcomers are working on changing the way insurance is obtained altogether. APIs and the platforms they belong to tend to give even the most traditional businesses a push and remind them that nothing is for granted.

APIs even allow you to explore space, thanks to Nasa opening up their wealth of infos and assets. It’s a nice service to the world, at the same time may result in the next big findings and groundbreaking advances to be a community effort rather than one of a bunch of NASA scientists. For the benefit of all of mankind.

You see, API driven platforms are very attractive for all the business and experience enabling benefits mentioned. Ask Salesforce.com - buying MuleSoft was part of their consumer (journey) centric strategy.

In the next part of the series on?Defining value in the age of Platforms and APIs, I'll write about how to get your journey started. Of course it all starts with an API. What else? Alas, playing the API game is not as easy as you may think.

Follow this link to read part 3 of my series.