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.

Agile Coaching, Part 1

I had the opportunity to talk to the New York City Scrum User Group last night on this topic (nycscrumusergroup/) and wanted to summarize some of the key points of that talk. The industry press is full of statistics about the increasing rate of agile adoption and there are many teams accomplishing excellent results with agile. But there are also a lot of teams that are struggling.

Agile is deceptively complex. In the classic waterfall project we're all familiar with:

• Communication is between silos at stage boundaries


• The process is well defined


• Delivery is some time in the future, mostly

In contrast, with agile:

• Communication is constant


• The process is not well-defined


• Delivery is in the next few weeks, at most

All of this contributes to make agile more complex, while at the same time it appears deceptively simple. This, in turn, leads teams to employ what's becoming known as the SCRUM-BUTT approach, "enhancing" their agile process with waterfall or other adornments to address the perceived shortcomings within the core agile processes. Now some teams have made useful additions to their process, but in too many cases the problems could have been solved by applying the basic agile framework better.

When I coach teams I start by establishing a basic understanding of why agile works:

Agile works because we don't need to pre-define everything. We don't need to pre-define everything because:

• the team and the Product Owner have an open dialog to insure the sprint requirements are understood


• it is easy to change the software


• we keep entropy from accumulating in the code


• we have a safety net of automated tests that give us confidence that we haven't broken existing functionality

Agile also works because we deliver production-ready software at the end of each sprint. We do this because:

• we have that safety net of automated tests


• we have a clear definition of "Done“


• we insure that we meet our definition of done on each story

If the team doesn't embrace these core principles and hold themselves and each other accountable for meeting them every day the team will probably struggle. For example, if the automated tests don't do an adequate job of covering the system (and this is very often a problem for teams just starting out, putting them in a hole they then struggle to ever get out of) changes to the code may introduce defects that slip through into QA or even production. The team then ends up constantly interrupted to fix priority defects, which means they then struggle to deliver their committed stories each sprint. This in turn puts pressure to do things faster, which leads to cutting corners, leading to even more technical debt until someone concludes that "Agile doesn't work!". That's the wrong conclusion. The root of the problem is that the team isn't executing the process correctly.

Once the team grasps these core principles we can move onto actually defining and adopting the process. This involves establishing the "Philosophy of Agile", which build closely on the core principles, then moving on to the basic fundamentals of the Scrum process. I'll talk about that in part 2.

The last thing I stress to the team, going back to the SCRUM-BUTT phenemona:

• We will get better by doing it and delivering value along the way


• And, if you’re tempted to change the process...




• STOP!


• Are you at Ri? (If you're not familiar with the ShuHaRi concept you can read about it here (martinfowler.com ShuHaRi)) And if the team answers yes to this, the follow on question is "Really???" since teams frequently overestimate their progress on this scale


• If you are not at RI you shouldn't be changing the process, so go back to first principles


• And if you don't understand how to do this, get help

More on this in the next post. And, by the way, Happy New Year!