"Down and to the Right" Versus "Up and to the Right"

Down and to the right is a reasonable depiction of internet service provider, capacity provider, mobility or telco legacy revenue per unit trends of the past several decades. That applies to wide area network capacity, internet transit prices, voice prices, long distance calling prices, text messaging rates, or mobile network minutes of use or data usage charges. 

That is distinct from the “up and to the right” depiction of the fortunes of growth industries, firms and products. At various points, internet access and home broadband, for example, have been “up and to the right” products. 

Which is another way of noting that business strategy is different for legacy and declining products compared to new and growing products. Think of “S” curve and its strategy implications. 

When a product is late in its life cycle, it is nearly pointless to invest too much, as no matter what one does, the product is destined to be replaced. So firms harvest revenues as long as they can. 

source: Strategic Thinker

The opposite has to be done for the newer replacement products: one has to invest in them. All that raises a question: is the move to try and monetize network functions using application programming interfaces (APIs) a move that helps connectivity providers extend the revenue production of declining products or propel the average revenue per unit of new products? 

To the extent it might represent both, how much does it create value, compared to how much it could destroy value? In other words, can monetizing API access to network features create big new revenue streams faster than it can commoditize the same?

In the former case, slowing the rate of revenue decline for some products might be described as “winning.” In the latter case, accelerating the rate of revenue growth constitutes winning. 

APIs might enable either outcome. If this all feels somehow reminiscent, think of the adoption of TCP/IP by global service providers as the “network of the future.” IP created layers of functions that are connected by APIs. 

So the network of the future necessarily separates application creation and ownership from network transport and access functions. 

Has that helped or hurt? And whom has it helped; whom has it helped?