Chalk X

Finding where to put your mark

Leverage those outside your company to innovate

Summary

  • There are more people outside of your company that can help you innovate than inside your company.
  • Facebook beat MySpace by realizing how to leverage external technical innovators. They did this by sharing some of its software capabilities, via APIs.
  • Application Programming Interface (API) is a common part of software architecture that allows communication/sharing of data and functionality between systems.
  • If you craft the right APIs you too can get the virtuous circle that Facebook did, but you need to be careful what you create and share. 
  • Not all APIs are Virtuous APIs, but all APIs have a market. Understanding the incentives of these markets can help architects and business analysts make better decisions.

For most of my 25+ year career, I have created software products for other software developers. This could be in the form of software libraries, automations, platforms, or APIs. In many companies the usage, marketing, and productizing of APIs is still being understood. This can leave money on the table for a company and creates waste in either underproduction or overproduction of APIs. 

Parables: 

Wikipedia vs Microsoft

In the 1990s Microsoft, the largest software company at the time, created Encarta. This was going to be “THE” encyclopedia of the new digital age. They hired hundreds of experts to create the content. And when it launched in 1993 they sold it for $99 on CD. This was a big disruption in the encyclopedia market.

However it is unheard of today because of Wikipedia. An organization with almost no employees and no money was able to beat Microsoft. They had learned the power of external innovators and were able to tap into that market.

When Microsoft stopped selling Encarta in 2009 it had 65,000 articles and at the same time Wikipedia had over 2 million. Today Wikipedia has over 6.5 million articles, with an accuracy rate of 99.5% according to research by Kräenbring and Penza.

Facebook vs MySpace

 In July 2022 Facebook, despite several headwinds, had ~1.9 billion users visit its site daily. Myspace (which is still around but with a lowercase ‘s’) had 6 million visits on the same day. How did Facebook conquer the once industry leader so completely? In short, they found a way to entice external innovators to build software on top of Facebook’s.

For those unfamiliar with MySpace (the original) it was not the first social media site but it certainly was the first big one. Statista has a good chart highlighting the rise and fall of Myspace.

Facebook launched in late 2004 but was restricted to universities and didn’t open to the public in 2006 when it also opened its platform to technical external innovators.

Was it a better product? Not at first, no. Myspace had many more features including way more options for individuals to customize their page and host music. 

Was it the only other option? Not at all. There were many competitors trying to get MySpace’s views. The older Friendster.com was in the marketplace with a cleaner design, similar to Facebook’s. 

The power of a social network is the size and the information of the users. The users and their information is what you’re selling. So how do you get them to give that information to you for free? Early on Facebook didn’t have the resources to hire the developers that Myspace had and wasn’t sure what would get people onto their network. But they could share that network with others that wanted to grow their business along with Facebook. 

Companies like Zynga games wanted to leverage the network to have more people play their games like Farmville. Facebook created technical hooks that allowed you to share your login information with Zynga and allowed the app to post on Facebook. Zynga used these in their game to keep track of your farm and have you brag to or solicit help from your friends on Facebook. These posts increased interest in the game. It also increased interest in Facebook as these games existed as apps on smartphones, and users got free in-game bonuses by connecting/sharing on Facebook. The virtuous cycle expanded the growth of both companies.

This sort of virtuous cycle, with various partners, caused an explosion of Facebook usage, and within 5 years the irrelevancy of MySpace.  Those technical hooks have a name, APIs.

What exactly is an API? 

An API is an acronym that stands for Application Programmable Interface. Meaning a way to call any software application from outside of that application. APIs have existed in programming for as long as two programs needed to communicate with one another. This communication allows the data and functionality of an application to be shared with another.

Once the internet came along there have been various ways created to share data/functionality via web APIs, sometimes referred to as Web Services. Almost every webpage has many calls to web services. Your web browser can show each one in a developer mode. To access your browser’s developer mode press F12 (chrome/edge). You’ll see another screen pop-up in your browser. Similar to the one below.

Select the network tab in this new window. Now refresh the page you’re on, likely this one but you can do it to any web page. You will see a long list of web calls for resources. Categorically they are not all considered API calls, though an argument could be made that they all are to some degree. 

These calls are grabbing information, images, and code to run in your web browser from all over the internet. Try this on Amazon, there are way more resources being called on that site than this one.

Every website uses lots of calls to get resources, but the company that displays the website doesn’t own all of those applications. Frequently websites are leveraging data from other places on the web. But why would other websites give away their functionality?!

API Markets

API creation, sharing, and use are influenced by the incentives of their markets. By understanding the incentives of the various API markets you can see why a company may give their functionality away. Sometimes companies give away functionality when they shouldn’t. Sometimes they overproduce or underproduce APIs. Here are 4 common API markets:

  1. Virtuous – Those when used make a business and the integrators business grow. 
  2. Revenue – Each time these APIs are called the caller is charged a use fee. 
  3. Reusable –  Ones used inside your corporation to speed up development. 
  4. Needed – Needed to make an application work

Virtuous 

The virtuous APIs are like the ones Facebook created. The more that they were used and integrated with other software the more it grew both Facebook and the API user’s/integrator’s reach. This is a classic win-win API. Typically seen in social networks or search engines. The provider gets additional user information to sell to advertisers and the consumer gains access to functionality(search) or a market (Facebook). Other examples: Login APIs, Paypal, etc. Here the cost of running the API (not free) must be offset by the value of usage. In the case of PayPal this can be easier to calculate, but for things like login or Facebook sharing the calculation is similar to that of economy of scale calculation. This calculation is necessary or a virtuous circle can quickly become a vicious one. 

Market : External, win-win, value is created by usage not billing. 

Revenue

These are APIs that cost the user something to use. Creating an API, and more importantly running it, is not free. Whenever you see a free service we know that the person offering it is getting something from us. This has been seen recently with “free” AI software. By giving the service away to users, the company is training their AI engine, making it better. As we have seen recently with ChatGPT this allows them to now offer a premium paid service. A product made better by giving a lower tier away for “free”.

ESPN spends a lot of money to collect sports information. And you too can add this to your app, website, or AI predictive engine, for a fee or a partnership. There are lots of ways to earn revenue from APIs, check out examples like ESPNs API Market to see different ways to sell API usage.  http://www.espn.com/apis/devcenter/docs/ If you look at their site you’ll see they categorize 3 layers of use for their APIS: Public, Partner, and Internal. Public are virtuous, partner APIs where they will earn money by providing them, and internal which are used by ESPN employees to make apps. These fall into our next category, reusable.

Market : External, deal enhancing, value is created by partnership or per-use billing. 

Reusable 

The value of these APIs come from the frequent need of a corporation to share data or functionality from one application to another. An internal reusable API could be shared, slightly modified, and become a virtuous or an Revenue API, as seen in the ESPN example. The key in understanding them is that you need to understand the demand for the data. This is not the frequency of the calls but the variety of users and systems needing the data. One way to discover a reusable API is during large projects one team is always called in to provide data or update their functionality to accommodate a new product. This is a sign that that team is becoming Myspace, and they need to start thinking like Facebook. There are lots of good API discovery techniques that I will go into in a future article.  Examples of reusable APIs could be employee data, building data, or orders.  Tip: If you organize your business around business units, they should have some APIs they own. If they don’t then you are missing out on opportunity. 

Market : Internal, cost minimizing, value is created by minimizing duplicate development and creating consistent data. 

Needed

These are APIs that are required for an application to function. The demand here is that the application itself needs it to function. For example a website needs to call a server API to display a dashboard of metrics for a user. This is unlikely to be reused because it is so specific to a given application. These APIs could be a composition of other reusable APIs, but this is a separate conversation about API architecture not API markets. 

Market : Internal, applications can’t run without them, value is created by the app itself and good API architecture to enable apps and minimize execution costs.

A market just like any other

Understanding these categories means understanding the market in which an API could live. Once you know your market you can find what your customers want and to figure out what to charge, if anything, for your APIs.

If you have software as part of your business you could be leaving money on the table if you aren’t leveraging APIs as part of your product strategy.  Look for opportunities by finding what aspects of your business can be used in a win-win virtuous scenario to open up external innovation. The key is understanding the user of the API i.e. who is the other side of the win-win combination. 

Usage:

  • Don’t take an API built for one market (an application) and put it into a market it wasn’t built for. The movement of functionality should include modifications to make the API match the new market and its userbase. These can include:
    • Adding Tracking of usage or other analytics data. 
    • Simplifying the interface and removing internal wording/data when exposing an API externally. 
  • Don’t waste time and money on making all needed services reusable or accessible to external parties. Follow demand and incentives.
  • Find teams overwhelmed with demand for new features or that are project bottlenecks. Make sure they have an API strategy to decouple them and speedup all project development.
  • Treat APIs as part of your product strategy. Don’t become MySpace. 

Published by

2 responses to “Leverage those outside your company to innovate”

  1. […] This article is the second part in a conversation on APIs, for the first part see the article. If you haven’t read it or are unfamiliar with APIs I suggest starting there: Leveraging those outside your company to innovate […]

    Like

  2. […] with other software: operating systems, frameworks, and APIs. If you read my article on APIs, or are familiar with them, you’ll know most applications today depend on lots of different […]

    Like

Leave a comment