Otto Weininger quote

"All genius is a conquering of chaos and mystery." - Otto Weininger

Tuesday, December 31, 2013

Cone of Market Coverage

Delivering a product via the Software as a Service (SaaS) mechanism has a number of advantages, both business and technical. But in order to successfully realize those advantages a company needs to follow a disciplined approach to how they grow, and in particular to the kind of customers they take on. In working with several SaaS clients over the past year I've found the idea of the Cone of Market Coverage, described below, to be useful. Over time the functionality of an applications should increase, as shown in Figure 1.

Figure 1: Cone of Market Coverage

This concept ties into two critical success factors on the technical side of a SaaS business: scalability and quality. Scalability of the application, of Data Center operations and of the business in general allows the company to market and add new clients aggressively and efficiently. Clients trust the company to run the application for them and assume a level of quality in return for that. They do not expect to encounter unexpected down time or random errors and if these do start to occur may push for their own isolated environment, or opt for an on-premise or hosted build.

One of the key ways to achieve scalability and quality is to maintain a single code base. This makes it easier for the company to operate a multi-tenant environment, and leverages the development effort by focusing all the work on that single code line. This makes maintaining high quality much easier without the need to consider either multiple code lines and/or customized code.  And equally importantly it creates an environment where the company can most effectively focus their resources on expanding the product, offering market differentiating features and functions.

As the company penetrates the market the degree to which it can stay within its Cone of Market Coverage, shown in Figure 2 below, will help determine how easy it will be to keep to the single code line approach. These clients use existing functionality and don't require client-specific changes to the code line.

Figure 2: Target Clients

Sometimes clients that are just outside the cone will be encountered, referred to as Near Outliers. These can often be handled with reasonable changes to the product roadmap, as shown in Figure 3. In fact in some cases this kind of market feedback takes the product in a good direction that may not have occurred otherwise. This, of course, depends on the changes being made within a product context, rather than as a customization.

Figure 3: Near Outlier

The real challenge comes when a potential client that lies well outside the cone is encountered, referred to as a Distant Outlier (see Figure 4).

Figure 4: Distant Outlier

In general it is very hard or impossible to meet the needs of a client like this within a standard product context. This generally leads to one of the following approaches, all of which are difficult to deal with in a SaaS environment:

  • Pseudo product code where the changes required are controlled by configuration parameters controlling only single client changes. As more of these creep into the code the challenge of managing all of these parameters, and the code they control, increases exponentially.

  • Customization of the single code line which makes it very difficult to maintain the integrity of that single code base. It becomes more difficult to make changes since the client-specific code needs to be considered. As the number of customizations grows this problem increases. In addition the testing of releases grows progressively more challenging as the level of effort needed to insure that the custom code works from release to release increases.

  • Branching the code into multiple code lines. This leads to redundant work in maintaining those multiple code lines which leads to a lack of efficiency. As the number of code lines increases, the inefficiency grows.

This leads to problems for a SaaS vendor which is why understanding and attempting to stay within the Cone of Market Coverage is an important concept for any SaaS company. There will be reasons a company may feel pushed to go outside its particular Cone, and there may be times that it is a necessity, but the degree to which these decisions are made plan-fully, keeping the Cone in mind, will allow the company to control the impact of those decisions, helping insure their success.

Would love to hear your thoughts on this concept and how it maps to your own experiences in the SaaS space.


  1. A very nice expression of the problem. I would expand this and say this is actually a product problem that occurs regardless of deliverable model (on-prem, SaaS, etc). In early product offerings (especially SaaS), the temptation to leap for the cash/customer can be overwhelming and lead not only to forking codebases but to other schisms in the organization as a result. What I call the Alignment of the org gets skewed or kinked and the result ends up being an increase the number of hard decisions and trade-offs to be made. In most cases, servicing the outlier customer is a mistake; however, it can be done successfully if, for instance, the investments made by both customer and provider work in alignment to broaden the Cone of Market Coverage in a matter that amplifies and focuses the product offering rather than causing a downstream set of rather unnatural acts for the whole business.

  2. Jan, great comment. I especially like your summation in the last sentence and the need for the customer and provider to work in alignment.