You can Move Down the Stack on Your Own; To Move Up, You Have to Partner

It no longer is unusual for an app provider to become an access provider. Google Fiber provides only one example. Tucows, originally a domain name registrar, has become both a mobile services provider and now a gigabit Internet service provider.

Both Google and Facebook are developing entirely-new access platforms based on unmanned aerial vehicles and, in Google’s case, fleets of balloons. Facebook now leases transponder time to support Internet access operations in sub-Saharan Africa.

Facebook also is testing Wi-Fi services in India.

Virtually every major telco thinks about ways to enhance value by “moving up the stack” and bundling more apps.

That naturally raises questions. Is it easier to move up the stack or down the stack? In other words, is it easier for an app provider to move down the stack, and provide access, or for an access provider to move up the stack into new apps beyond voice and messaging?

Most of us will conclude that it is easier to move down the stack, compared to moving up the stack.

One can think of many reasons why that is so, even if the core competence, either way, is not present, when occupying new adjacencies in the ecosystem.

It is not necessarily the case that “access” is easier to learn than “apps,” though that likely is the case. The simplest explanation is that an app provider moving into access has one major advantage: it is the “customer” for access, and therefore knows precisely why such a move has value.

That also would be true for any app provider getting into the cloud data center or transport business. The move “down the stack” supports core app provider business operations.

Google, for example, even can quantify what “faster access” means for its core business model (at least the present business model). Faster access means more pages can be viewed in any unit of time. That, in turn, creates more ad inventory to sell.

That is a lot easier than figuring out where and how to spend money to move up the stack. The access, transport or data center provider is not the “customer” when moving up the stack. A firm does not necessarily “know” what the customer requires, finds valuable and will pay for, when moving up the stack.

So moving up the stack is more risky. All of that suggests any move up the stack will be less risky when a partnering approach is taken. Not riskless, by any means, but less risky than trying to be right about the end user value proposition, in a major way.

An illustration: service providers created the value of voice and messaging, and were able to build significant  businesses around enterprise need for connectivity. Cable operators were able to create a huge business model around video entertainment choice.

Other entities have been able to create meaningful businesses around enterprise computing (cloud computing and data center operations).

But the app creation function mostly has been separated from infrastructure operations. And it is app providers who must figure out what buyers (consumers) want, and will pay for. In many cases, that includes indirect revenue models, where the actual buyer is an advertiser, not the retail end user.

It all means that service provider app creation typically will require partnering with app providers. App providers, on the other hand, often can simply move into access, transport or data center operations themselves. They are the “customers” for such services.

So there are only three rules for service providers creating important new apps, and moving up the stack. Partner, partner, partner.