Hyperscaling , Kiva, and the magic of selling “as a service”

We are using the example of Amazon to show how “hyperscaling” — selling your internal capabilities as shared services — can be great for business. “Why Amazon is Eating the World” from Techchrunch contributor Zack Kanter explains that this is not only a way to create new products. It’s also a way to ensure that the functions inside a big company are world class, instead of flabby and unresponsive. These functions have to be near the best of breed to compete in their product markets.

My colleague Brad Power brought up a counterexample. When Amazon bought Kiva Systems, they stopped selling Kiva robots to other companies and started using them only in Amazon warehouses. Brad writes “I’m still struggling with why the robots wouldn’t be offered externally as well.”

My theory is that you gain competitiveness if you can run rapid innovation in a service, but you lose competitiveness if you have to ship and install a B2B product. The difference is in the speed of the upgrade cycle. Consider two different cases:

1) Amazon sells Kiva robots to another company that has to install them, program them, and run them. The sales cycle and upgrade cycle are very slow. It probably takes a year to buy the robots and install them and integrate them at a warehouse. The floor probably has to be redesigned. The customer probably does not want significant updates more than once every year or two. So, the vendor (Amazon in this case) spends most of its time supporting old versions of the system. The feedback of data from the customer to the product development team is even slower than the acceptance of upgrades, so this customer is not effective at driving improvements.

2) Amazon runs the robots in their own distribution center and instead sells “Amazon Fulfillment Services”. The customer sends the goods to Amazon’s warehouse instead of setting up its own warehouse. Amazon has immediate access to performance data and can run upgrade cycles as fast as it wants.

You can see that this is a matter of packaging. The robots still handle the same goods. However, if they have to be installed and integrated at the customer site, this kills the upgrade cycle. In case 2, it’s robots (and other fulfillment) as a continuously upgraded service. Given the choice between Case 1 and Case 2, Case 2 is vastly more effective in improving both internal capabilities and external products.

This is one of the major reasons why the world is moving to SaaS and subscription services and on-demand services. The upgrade cycles are much faster in “as a service” sales. Selling installed enterprise systems is frustrating and horrible for innovation.

So, if you are selling capabilities, sell “as a service.” Don’t try to transplant your stuff to someone else’s facility, thereby creating future upgrade tasks. We see a lot of companies trying to get the benefits of sharing and hyperscaling by doing open source releases. This as some of the same retardant effect as enterprise sales. I’m looking forward to running “as a service” side by side with the open source releases to prove the benefit of seizing control of the upgrade cycle.