Those of you who have read books about platform economy, know that transactions are more important for the platforms than the products or services they create. Without enough liquidity in the markets platform does not stay alive. That liquidity partially depends on how well the platform ticks eg how well the producers and consumers match and interact with each other. Of course the marketplace must have offering, but without interaction there’s no transactions. Successful transactions are what the platform operator is looking for.

Curated Pile of API Economy articles (and books)

As part of the background research (for work, hobby, book) I have collected a list of some good API and platform economy articles so that you don’t need to use tens or hundreds of hours to find those. I have read the material and created curated list for you. Unfortunately the list was kickstarted in Medium which has turned into mostly sh*t due to greed, but I hope you can read it anyway despite of the paywall thingy.

Different shades of developers

As a Developer eXperience lead at the Platform of Trust my focus is on the developers buzzing in our platform. My concern is how I make the developers “tick”. As it was discussed previously I have to manage both internal and external developer experience. Now we need to add another aspect as well.

At the Platform of Trust we have two separate developer segments, both external developers. First one handles the data integration while the second builds apps on top of the data. Both are needed to fill the marketplace with apps. Both of them have managers lurking somewhere near. They need to be taken into account as well. But still the main focus must be in the actual developers.

Make data available - integrations cycle

The faster the integrations cycle spins, the more data products we have at the market place. That in turn attracts more application developers to our platform. The positive effect stays as long as the amount of data products grows and quality stays high enough. For integration cycle we have to make data product creation, management and sales processes as easy as possible.

For this integration cycle to spin as fast as possible, we don’t have the luxury to go on with legacy style integration projects which take months. Getting your data from several system with Zapier alike clicking is not a simple task, but we’ve found a scalable solution for that. Aim is that actual development (as code) is needed only in fraction of the integrations.

This has been my primary focus since June and I will continue with this “speed integration” feature for the rest of this year. More about that later this year. If we would satisfy with simplifying data integration, we would be “just” another integration platform. But no, we go further.

Create value out of data - applications development cycle

Likewise the more faster application development cycle spins, the more applications we have in the markets. The rising amount of application feeds the data providers and creates incentive to add own data to the market place for application developers to utilize.In the application development cycle we must make data products as attractive as possible, and as easy to use as possible.

Furthermore, platform must enable and maximise the right match between supply and demand. For example it does not make sense to matchmake lights status data product and air ventilation management app developer. The platform must find a way to match data products with right kind of developers. If the developer keeps on bumping with too much irrelevant data products, it does not provide any value to the developer at that point. Developer just walks away from the platform.

Platform cycle - ticks or dies

Our tasks is to reduce the friction in the spins. Our task as platform operator is to reduce the friction between the two spins and means to collect and match the needs of both sides. The faster side cycles spin, the faster platform cycle spins (more transactions). The more transactions we have the more lucrative the platform is - for us, data owners (producers) and application developers (producers and consumers).

Lesson is that you can’t just look at the details like how’s my API documentation; does it have enough code examples, or do we have sufficient getting started guides. You need to understand the bigger picture. Like with single API case in which you need to think the value chain up to the application consumer. In platforms you have multiple value chains to think about. Get the big picture first, evaluate it and start building the needed element to maximise interactions eg ticks. Needless to say that developers in various forms are your focus point.

Some more to read from 100 Days DX