Business Hosted Services

2006-03-18 15 min read Uncategorised marco

The Internet was awash with application service providers that would allow consumers and businesses to perform tasks, even in the very early days of the commercial web. After a few years and a burst of the Bubble, most of the companies that provided online services disappeared, leaving only a very few winners. This was true across horizontals, where only a few of the many related companies survived, and verticals, where only a few types of solutions did.

The bloodbath of 2000-2002 took a lot of ideas and concepts with it that were indeed unworkable and unnecessary. Many that survived that storm recall with particular amazement how the wave of ASP (application service provider) dot-coms cratered without leaving a trace. Consumer hosted services, on the other hand, did much better, as did business-to-consumer services. The former is most perfectly epitomized by the stalwart of consumer sites, Yahoo!, while the latter category is best represented by Amazon.com.

A great many dot-coms got busted because of incompetence of the management team, because of poor choices (in hindsight) as to deployment, cost structure, growth plan, because of the sudden drying up of funds (yes, some really good ideas died just because of the general panic). Some dot-coms though died because their business plan didn't work out, despite early hopes.

# Where Did ASPs Fail?

The standard ASP business model consisted in offering otherwise installed software in a managed, remote fashion. Instead of buying, say, 20,000 licenses of, say, SAP, an enterprise could *rent* those very same licenses from an ASP. This would allow BigCo to reduce the impact of licensing expenses, eliminated the need to have supporting IT staff, and allowed the enterprise to deploy faster than if it had to find resources for the long haul. An additional benefit was the ability to change to a different and better solution without spending one extra cent later on.

The ASP would make money by charging companies for the licenses it bought on an ongoing fashion. Assuming the licenses could be used over a long stretch of time, the rent vs. buy equation would invariably turn in the ASP's favor. The startup cost was very high, of course, requiring extensive capital resources in the form of cheaply available venture capital.

An ASP would be mostly composed of Sales and Marketing staff, selling a commodity product against an unbelieving market. On the technology side, the bulk of the staff would be IT, ready to keep applications available at all times, and fighting security holes, software bugs, and downtimes.

The surprising thing is that there was nothing wrong with this business model. Indeed, it could and should have continued as a possible and rational option for enterprises to this day. So what went wrong?

In one word: **customization**. In those days, the assumption was that everyone that would buy enterprise software would customize it to make it work in their case. The software itself was built around customization, and a lot of the energy of the development team went into making the application flexible, so that IT staff could customize it.

The expectation was that whatever solution would come from an ASP, it would need to be at least as customizable as installed enterprise software. Not a problem, said ASPs, and started tailoring the software to their clients' needs. They bulked up on developers that took on the customization, and became lopsided consulting houses.

The problem now is that the original model had a clause: in the rent vs. buy equation, the renter must be kept for a period of time long enough to cover the cost of the product, otherwise there wouldn't be enough money to pay. The more customization the ASP provided, the longer this time period was, and the end of the bubble forced ASPs to lose customers and sit on incredible amounts of customized software that wouldn't work for anyone other than the original customer who no longer could afford to pay for it and easily walked out of the contract.

# After the Bubble

In 2003 things got slowly sane again, and the Internet started a new period of expansion. Business hosted services (the name ASP was so tarnished, a new one was direly needed) were the slowest to gain momentum, but with the advent of **Salesforce.com** this last barrier to growth finally fell. Salesforce's success was directly related to its decision not to offer anyone else's software, but to create an application from scratch that would be easily customized.

The extremely successful IPO of the company led to a keen interest in other business hosted services, and a new category was born out of the ashes of an old failure.

# DNA of a Business Hosted Service

Trying to avoid the failure of the ASP, modern Business Hosted Service (BHS) providers do not rely on customization of enterprise applications. Instead, they focus on applications built in-house (or outsourced), typically on commodity hardware and using open source software to keep the cost of development low. Since customization is not an option, typical BHS providers tend to verticalize their solution, making it attractive to a specific market segment much smaller than those reached by typical software solutions.

This approach has two main advantages with respect to enterprise software:

1. The service can appeal to a heretofore unserved or underserved market segment 2. Customization is typically much less desirable if the solution is specifically tailored to a problem

The first advantage allows for word-of-mouth marketing as a successful propagation strategy, while the second advantage reduces growth pains: since all customers want the same, rapid growth of the BHS does not translate to the need to staff up.

The Innovator

Creating vertical solutions on commodity hardware with open source software is extremely easy to do and allows for small entities to enter markets rapidly and with great success. A very small team can create a solution and deploy it within months, making the barrier to entry minimal. On the flip side, the markets served by BHS are almost by definition underserved, and hence a lot of the development that goes on consists in finding the right mix of features and functionality for the market at hand.

This translates into a problem for the first mover: a good part of the development cost is sunk into the process of finding the features by trial and error. Once the feature set it defined, it is easy for the second mover to copy the features at a much lower cost. This is not specific to BHS providers, and is a problem encountered by any software (and hardware) vendor that enters an underserved market (a green field opportunity).

In the case of BHS providers, though, the lack of switching costs can be a real problem. Moving from one BHS provider to another is extremely cheap and requires only a data migration and end user training – a problem kept from the old days of ASP providers. Hence, the only way to keep the BHS successful is to continue investing in innovation, and to constantly come up with a better solution that serves the needs of the customer better.

The strategy of constant innovation has to be augmented by legal theft, where the first mover BHS turns the table and copies outstanding features of competitors’ products, and intellectual landmines, the protection of intellectual property (by virtue of copyrights, trademarks, and patents) that makes it harder for competitors to catch up.

This is a first fundamental difference between a BHS and an ASP: in an ASP, innovation was unnecessary and outside the business model. In a BHS, the Innovator is the most important figure, and the best Innovator will invariably catapult his or her BHS to prominence.

The Shepherd

Features and functionality are one half of the BHS equation. The vertical market is excited about a solution that is obviously tailored to specific needs and that provides intuitive flows. The notion that the BHS provider is a friend of the customer is born out of synergy of intent: the BHS vendor needs to innovate, and needs the customer to find out what is required; the customer feels listened to and gains increasing benefits from the product.

To facilitate this bidirectional flow, the BHS provider needs to find a shepherd, someone that has a very strong gift in listening and coaching, someone that can guide the customer along, showing how to be productive, but noting where the service needs to be improved to make the customer productive. The balance between the need to guide and coach vs. the willingness to accept the customers’ superior expertise of the business product is extremly difficult to maintain, and makes the role of the Shepherd as important as that of the Innovator.

The Shepherd, in addition, is the logical entity to direct the flow of money. This is due in part to the recurring nature of revenue in a BHS (where subscriptions require continuous engagement with the customer), which put most of the revenue collection in the hands of the customer advocate; in part this is due to the bond of trust that is established between the successful shepherd and the customers.

The Stewards

Understanding the customers’ problems and creating solution that fit them are not the entire bill. Of course, customer satisfaction is not made of features and functionality alone, and is based on the entire customer experience with the product. A BHS is typically used as part of key business processes, and hence needs to perform evenly, predictably, reliably. Each BHS will have one or more Stewards, typically one in each functional area of the product, that takes care of the regularity of the service and protects it from downtime and security breaches.

In a typical BHS, there will be three main Stewards:

The person responsible for the quality of the product, who monitors future development
The person responsible for uptime, who monitors current developments
The person responsible for data integrity, security, and privacy

The Stewards are easily forgotten in a successful BHS, because it is their failure that is visible, not their success. Hence, if everything goes well, nobody will know about their crucial contribution; their failure will always look like a personal one.

# Structure of a Business Hosted Service

Aside from the Innovator, the Shepherd, and the Stewards, each BHS needs a small cast of members. It is both encouraging and exciting to see how a BHS can indeed be formed by a small set of people and stay small over time.

Close to the Innovator is the development team, that implements the ideas of the innovator. The development team will typically perform a dual function, in that it will help resolving customer issues with the product and potentially help the Stewards perform their respective tasks.

The Stewards needs their own respective staff, in QA, Customer Experience, Security, Data Center Operations. Security and Data Center Operations typically require constant monitoring, which makes the job quite stressful.

The Shepherd needs staff to coordinate the resolution of customer and user issues, in a reversal of the typical role of Technical Support. The need to bond with the customer makes it paramount that the Customer Contact be close to the Shepherd and share in a great many of the personality traits of her/him.

Special staff is required to gain Customer Growth. As mentioned, traditional marketing and sales efforts will not be as successful as word-of-mouth and viral marketing, because of the smaller customer base. Sales staff hence needs to be trained in bonding with the customer and will benefit from proximity, direction, and support from the Shepherd.

Revenue Model

Since the commoditization of BHS solutions is built into the model, the revenue opportunity is always challenged by a ceiling in the charges per customer. Copycat services will charge minimal fees, derived both from the poor functionality and the smaller development cost. The reason copycat services cannot be successful is that they are not able to establish the primal bond with the customer, that knows there is someone that listens to them more and better. Nonetheless, the revenue per customer garnered by a BHS has a natural upper bound, and this needs to be factored into the solution.

A prime mover BHS, on the other side, can count on high levels of customer satisfaction and low turnover. As long as the product innovates itself and the bond with the customers is kept alive, there is little reason for a customer to switch or discontinue. This translates into a double revenue increase:

Given high renewal rates and regular customer growth, the forces of past customers add themselves to those of new customers for an ever growing revenue stream
Given successful word-of-mouth marketing, there is a network effect in the offing. The more customers the BHS has, the more new customers it will attract thanks to personal relationships

Hence, even a small BHS can grow large, depending on the size of the customer segment and the willingness to spend for a tailored solution.

In addition, you will typically find that a good BHS can find markets adjacents to its primary market: markets where a vertical solution is missing, connections with the existing market are strong, and the current solution is a partial fit. In this case, a spin-off can take the existing solution and develop a new one on top of it (or start from scratch with the knowledge of the past) and use the knowledge of the BHS DNA to create a similar solution. This translates into the same type of growth as in the case measured above, but now on a horizontal platform that allows for scaling even where the current market is depleted.

Frequent Mistakes

No discussion of business hosted services would be complete without a brief analysis of the most frequently made mistakes in a BHS.

1. Discounting the Role of Innovation

Fact is, only the best service is the one that can establish the bond with the customer. All other services will only be able to compete on price (exception: see below), which automatically translates to minimal margins, minimal market share, and hence minimal revenue. All in all, the history of the Internet has taught us over and over that only the strongest wins.

A BHS can concievably think it can get to the prime mover position and discontinue innovation. The MTTC (mean time to catch-up) on BHS though is so small, any hosted service will be feature-matched by its competitors in a short time (typically less than a year). Then the competition is entirely on price, which ends up being ruinous to all except the one with the lowest cost structure. This is strictly analogous to the way consumer hosted services evolved: the ones with high cost died (Excite being one example), while those with low cost (like Yahoo!) survived.

The decision to discontinue investment in innovation, or the loss of the Innovator, invariably proves to be the most common detectable cause for failure in BHS providers. This kind of mistake is most common in companies where the decision making body is composed of people that were in traditional Sales and Marketing roles in enterprise software and hardware companies.

2. Discounting the Role of the Customer Bond

After a while, all succesful BHS providers end up complacent about their success. In particular, frequently customer complaints are not registered any more, because the single complaining customer is such a small fraction of the revenue.

Fact is, any legitimate customer complaints is a way to make the product more successful. Listening enables a powerful feedback loop that translates in higher customer satisfaction, higher retention rate, more widely recognized thought leadership, and ultimately more success.

On the other side, listening to bad customer suggestions can lead to the same fragmentation in the product that old ASPs had to contend with. Evolving the product in a customized fashion is bad, because it cannot scale with the customer base.

Without a good Shepherd, the BHS fails, because it is not able to function efficiently and is invariably overrun by better organized competition.

3. Discounting the Functions of the Stewards

This mistake is particularly easy to make, because the Stewards become visible only when they fail. Since the Stewards perform functions that are typically relegated to the Back Office in traditional companies, it is even easier to feel their relative lack of importance.

The opposite is true, and the Stewards perform critical functions that are vital to the BHS, much more so that traditionally more highly regarded functions such as Marketing.

Since the Stewards define the operability of the system, their performance is critical to the success of the company.

4. Defining the Product Using Traditional Means

Traditionally, software products are defined by asking customers what they want and building that. In a BHS, this is not feasible. For one, all BHS providers have the same access to customer opinions, and can easily copy from each other. This means that building what customers want leads to a level playing field that destroys the prime mover advantage. In addition, the market is defined as underserved, and hence it is most likely that the customers do not have a clear idea of what they want. Building by request ends up frustrating the customer, even when the requirements were dictated by him or her.

Instead, the successful BHS needs to collect the Shepherd’s feedback and translate into an innovative solution that bypasses the customer request by enhancing it and subsuming it. This is not possible without deep understanding of the business processes and without the willingness to ignore customers for their own sake.

The Innovator in a BHS better transcend his or her customers.

5. Sticking to Traditional Hierarchies

The way a typical software house is organized is modeled after a typical hardware house: capital influx is the main thing, and the Master and Commander (CEO) typically is powerful because of his or her role as purveyor of capital. In a BHS, capital is secondary to the overall structure of the business, and the roles of Innovator and Shepherd need to be sovereign. Any attempt by the Master and Commander to dominate over the two other roles will end up in confusion and frustration for both the company and customers.

Of course, the Master and Commander can function in the roles of Innovator and/or Shepherd. This is certainly a good compromise solution, in that the role of M&C is active only sporadically (when new capital is needed), while the Innovator and Shepherd need to function continously.