Don't Get Confused: When Service Matters More Than Features

Simon Wardley, one of the better thinkers in the technology market, whom I have only recently had the pleasure of discovering, has been writing for years on the inevitability of the move to "cloud" on the one hand, and on the other why Amazon Web Services (AWS) has so dominated the Infrastructure-as-a-Service (IaaS) market and how to properly compete against it. He believes - and I agree - that this competition is crucial for the benefit of the market, the customers, and, in the end, the providers as well. Monopolies, market granted or government enforced, inevitably lead only to the benefit of the monopolist, whereas more competition and a somewhat fragmented market leads to more innovation, lower costs and better service.

In a recent article, Simon delved into whether or not OpenStack can successfully compete in the IaaS space and, eventually, dominate it. En passant he discussed some of the major mistakes potential earlier competitors with AWS made in their attempts. Here is my favourite line from the article, and a crucial insight into any business moving into the services space:

OpenStack's chance of success has IMHO been severely harmed over the last few years by what I can only describe as "flat earther" opinions e.g. a product mentality of feature differentiation and company competition applied to a utility world ruled by service quality differentiation and a battle of ecosystems. In terms of strategic play, pretty much the only thing OpenStack has got right is being open.

I have worked with countless companies who were in the product business. Most were software, some were hardware, a few were other consumer products. All have the same common, and necessary, mindset. People buy products due to a mixture of features, costs and availability. Market perception (the Apple "cool" factor, e.g.) are part of the product features. As such, providers work hard to provide products that have the right mixture of features and price to capture the desired share of the market. But once the product is shipped, it exists on the customer site: iPods, enterprise software, work desks, HP servers, paperback novels, toothpaste... all work at the customer. The customer implicitly (and usually subconsciously) accepts some level of responsibility for keeping the thing in good working order, with the assumption that the provider has sold a product that will last reasonably well. If it has some failure, some outage or downtime, the customer is not pleased but accepts it as a risk they take. Your iPod fails, you are annoyed, you bring it in, eventually you buy another, unless it fails too catastrophically or too regularly. IT departments buy multiple servers and link (or cluster) them together assuming they some will fail.

On the other hand, when you buy a service, you care about the features, but you care more about the service level. If your internal backup software and drive don't work once or twice, you call customer support, get it fixed, and move on. On the other hand, if your backup service doesn't back up, you say, "this is what I am paying them for!!"

The core job of a services company - of which a cloud/SaaS/IaaS/PaaS/BaaS is just a special case - is to operate. Customers pay services companies to take the headache and responsibility of operating their enterprise software or HP servers or payroll off their heads, so they no longer have to worry about availability and uptime and backups and administration and all of the headaches and costs involved in making sure they run just about all of the time.

Product companies, and especially software companies, regularly become confused when transitioning to becoming a services company, and especially cloud. They believe they need to provide the same products, just do it online. They need to pay for data centres and servers and systems administrators, but just enough to keep it running. But service companies are fundamentally different than product companies. They require a different culture, different investments, different structure and different staffing.

Here are three example areas for technology firms. There are many more, which I work with my clients to achieve:

1. Structure: Software companies will usually have a CTO and a VP R&D (sometimes called VP Engineering). Cloud companies need a VP Technology Products, who owns all software development, the core product, and VP Technology Services, who owns all of the infrastructure (even if in the cloud), middleware and daily operations. These are equal executives. Both of them do engineering and operations. Of course, there may still be a CTO.
2. Staffing: Software companies will invest the bulk of their technology budget in engineers, secondarily in software tools, although open source has made the second part shrink significantly. Cloud companies should be investing more in the services - engineering and operations of the system itself - than in the software development/engineering. If a customer is paying you more to operate the system than for the features, where would you invest?
3. Culture: In a software company, customer support traditionally works on a rigid critical/high/medium/low priority continuum. The default is to have 8x5 support, with 24x7 available as a premium. In cloud companies, the default needs to be 24x7x365 operations and support. They still need to prioritize, but less by level of customer importance than by time of impact. A customer affected by a "low" in the cloud for 24 hours, even on the weekend, will cost you more in lost business than one affected by a "high" for 2 hours.

If your product company or vendor is increasingly offering services, and it is having challenges with delivery, availability, customer satisfaction, the culprit is often the difficulty in making the internal transition. As they say, "the first step is admitting you have a problem. The next is getting help."