Doing my research for this article, I can see that this subject was argued about a lot a couple of years ago. Recently however, the discussion seems to have disappeared. As marketing media will do, the term cloud has become a broad brush that can be applied to anything on the Internet. The result is a lot of completely different technologies have been painted a much-abused shade of cloud gray.

The best way I can think of to discuss this is in a series of questions and answers. This may sound like a sort of self-aggrandizing way to do an interview, but actually these are questions we have gotten in discussions with companies moving to the cloud.

Q: What is the difference between virtualization and cloud computing?

A: Virtualization is a technology that is available in several forms to allow technical resources (applications, network services, etc.) to be separated from the physical machines they run on and treated as an abstraction. A good example is a number of virtual servers running on one physical server. Each virtual server runs on its own virtual machine and can be managed by the tools provided by the type of virtualization being used.

Cloud computing on the other hand leverages virtualization technology to provide a model for access to a shared pool of configurable computing resources. One of the best and cleanest definitions I have found is the NIST draft definition.

Notice the five Essential Characteristics they have identified:

• On demand self-service, by the customer without the intervention of the provider.
• Broad network access. Notice that this goes beyond the Internet to include a wide range of client platforms.
• Resource pooling, that allows the provider’s computing resources to be shared in a multi-tenant model with resources assigned and reassigned on demand.
• Rapid elasticity allowing resources to be rapidly and elastically provisioned and scaled out and in either manually or in the best case, automatically either from set parameters or from application logic.
• Measured service that leverages metering capabilities to automatically control and optimize resource usage according to service parameters.

The three Service Models: Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS)

The four Deployment Models: Private, community, public and hybrid.

So while virtualization provides a technical way to separate services from the infrastructure or system that supports them, cloud computing goes beyond that to provide a range of of models you can use to implement computing services economically and dynamically. As Garter has pointed out, there is a lot of confusion in the market aided by a lot of self-interest. SaaS providers need to be aware of this discussion and it’s implication for their businesses.

Q: Why is Cloud Computing important for SaaS providers to understand?

A: For a SaaS provider, business scalability is critical for success. If you can’t achieve scalability in a reasonable period of time and continue to sustain it over the long term, your odds of failure greatly increase.  While the technical side of scalability is only one aspect of the equation, for SaaS companies cloud computing represents an opportunity to achieve operational efficiency rapidly and at a much lower cost than was possible before it became widely available. To take advantage of this opportunity, SaaS companies need to leverage one or more of the three service models and insure they are using vendors who provide services that include the essential characteristics as mentioned in the NIST draft.  Many vendors say they provide “cloud computing,” but a careful review of their service model will often show that they are offering little more than access to a proprietary implementation of virtualization. The heavy lifting required to provide rapid elasticity or measured service is left to the customer and where it is available, cannot easily be passed through to clients. The effort required to build in the necessary service characteristics on someone else’s system is not trivial and requires a good understanding of the underlying virtualization technology. In the end, the investment becomes something of a barrier to entrance and once it is spent, a barrier to exit for the SaaS ISV.

There is no prefect cloud computing platform for SaaS providers, at least at this time. Most cloud computing providers at the IaaS and PaaS level are focused on the enterprise market and the simple movement of enterprise datacenter assets to their service. But there are systems that meet the classic definition better and provide a lot more opportunities for the SaaS provider to leverage them through to the client level. At this moment, Microsoft Azure and Amazon AWS meet the definition best, but the market is very competitive and there are ways to use other services in combination to achieve some of the same benefits available from these vendors.

Q: So, if I just put my existing application on one of the “best of breed” cloud computing providers, I will then have an efficient and scalable SaaS Cloud Computing implementation?

A: Unfortunately, if you are an ISV with an existing application it depends.

If you have a small application without a lot of features and complexity, you are using current methods for web services, you can adopt multi-tenancy and you use some tools for scaling out and in, it should work out just fine. There is no need to change, other to insure your business operations (pricing, billing, settlement, metering, etc.) are automated and will also scale properly, and you can manage maintenance tasks while keeping your reliability within your client expectations.

However if you have developed a large, complex, enterprise application, your cost and efficiency on a cloud computing model, IaaS or PaaS, will not be radically different than on hard metal with traditional clustering techniques. The problem is, your application is likely to be built for scaling up – rather than out. If it is a complex, monolithic architecture, you will scale simply by starting additional instances. The application will require large virtual machine instances, which are considerably more expensive than small instances. It will take longer to deploy new instances (scale out) or decommission instances (scale in) when they are not needed. Performance will be tied to the busiest functionality in the application, regardless of how many concurrent users you are carrying. So, a payroll function in an HR application will drive scaling of the entire application, even though the primary overhead is in computing the payroll itself, not in personnel assessments for instance. This impacts cost (for scaling and maintaining large instances) and operational efficiency.

In addition, complex enterprise applications tend to also have complex databases. On platforms like Azure, the functionality available is tuned to many small, federated databases rather than large monolithic databases. There are many things you simply cannot do on SQL Azure that you could in a standard installation. If you use other cloud computing platforms, you can cluster but clustering large databases requires considerable bandwidth for synchronization. In the end, a little modeling may show that is indeed easier to stay on traditional hosting if your database is large and complex.

In the case of large, complex and monolithic applications, the best bet is to realize that over time they will need to be re-imagined as a group of components that can run on smaller instances and scale independently based on their direct use. This doesn’t mean the entire application has to be redeveloped before a cloud IaaS or PaaS is used, but it does mean that there should be a plan for development of new functionality in a component style and gradual migration of functionality that can be segmented from the core application to separate components. Especially in the early days of deployment of a SaaS application, it is unlikely you will be overwhelmed by clients and you have time to gradually move toward a more efficient application configuration as you meet the demand of the new market your application will be facing. Take your success and plow it back into gradual operational improvement.

Q: We’re planning for an entirely new SaaS application. Do we have to design for the cloud immediately?

A: If you are using the current Lean approaches to product development, no – depending on the stage of product development you are in. In early stages, when you are still working to find an acceptable business model that produces value with visionary customers, use every tool at your disposal to keep development overhead low. Use tools that keep needed coding to a minimum, change turn arounds quick and investment costs low. Don’t become heavily invested in application code that you will probably have to throw away.

Once you have a proven product and market, then spend the time to break down the service functionality and develop a scalable, component architecture as is necessary for cloud-based SaaS. Use tools and methods that are proven for commercial grade, scalable development. Now your investment counts toward the ultimate goal – a scalable business built on a solid foundation.

A new SaaS application is a great opportunity to do things right and not spend a lot of money trying to change out your engines while you are hurdling down the runway.  Using component-based architecture gives you a lot more flexibility over time to tune and enhance individual parts of the application without risking everything. And – if you are in the enterprise market – you will find that most of your customers are virtualized anyway. Depending on how you use the tools available from the cloud PaaS or IaaS provider you select, you can still transfer the application cloud to your customer’s virtual environment where necessary.

Q: Isn’t using platforms and cloud infrastructure risky? Won’t it lock my business to the fortunes and lifecycle of the PaaS or IaaS vendor I pick?

A: Yes, but is that a bad thing?

If you chose well, you will have the advantage of a large number of tools that will lower the time and expense necessary to develop your product. In development today, programmers don’t code directly in assembly for the processor in a target server anymore. In fact, we’re less and less concerned with the base our application will run on, especially on the client side. This is because we leverage abstraction, frameworks, environments – platforms to make development faster, easier and the results usable in a wide range of contexts.  The leading cloud computing platforms are simply the next step in that continuing evolution of computing.

Of course, not every cloud service vendor is going to win in the long run, but we can pretty easily pick the ones that will last long enough to make it worth using their services. They have an established history and user base that is easy to assess. They are competing and innovating not at the distant edges of the technology – they are right at the core where the changes they make have a strong impact on business capability.

In this light, a lot of the “fear-mongering” we hear is nothing more than media hype. You have to evaluate and make choices, but that is a normal business process for selecting any vendor or partner. You can’t afford to go it alone these days.

Q: This is a lot to absorb. There are a lot of changes in the industry right now. Do you offer services to help companies navigate cloud computing as they develop applications and services?

A: Yes.

I guess you could call us a Cloud Computing Enabler. Scio is a partner of both Microsoft and Amazon. We have worked with companies from startups to leading Cloud SaaS providers in the field.  We offer services for business and technology assessment, application planning, development, tuning and maintenance. We are focused on continuing to develop tools and services for the cloud computing market.

But that said, we will honestly say there is no “one-size-fits-all” solution in cloud computing. Every project has its own goals and each client has their own constraints. Our job is to use our knowledge and experience in the field to find the best fit for the work in front of us and not the one solution we can squeeze everyone into.

The conversation continues:

If you are a member of LinkedIn and part of the Software + Services (SaaS) group, you can join the conversation.

As I begin writing this series, I have to admit I am deeply disappointed with the portrayal of cloud computing by the pundits, analysts and technical media in general. “The Cloud” has quickly become a metaphor for anything that can be accessed on a network and for the network itself. The term is so broadly used it now can mean anything and at the same time – nothing.

Since as a word, a cloud carries the sense of a nebulous, vaguely defined mass – I guess it is apt. That description is certainly what it has become in most peoples’ minds. At the same time, every cloud provider is telling developers that they need to use their services and develop their applications for the cloud.  What does that mean? Why would I want to?

Let me begin by defining what I mean in the context of this article when I use the term Cloud. In essence, it is nothing more than virtualized infrastructure. The term includes all the resources necessary to communicate, access, process, and store data – but without having to manage and provision physical hardware. For a long time, ten years or more, virtualization technology has been an enterprise tool; used for managing infrastructure resources in environments that include hundreds of servers.

In enterprise data centers, virtualization is generally used to:

• Lower the implementation time and risk for server deployment.
• Aggregate services to improve total infrastructure utilization.
• Improve and standardize failover and server reliability.
• Improve and standardize server and infrastructure management.

In a pool of many servers, these benefits translate to lowered risk and a lower total cost of operation. Getting those benefits in a large pool of servers generally requires only moderate application configuration and no rewrites.

Let’s compare that to a minimal implementation for a SaaS Application – starting on bare metal (machines with no OS or configuration) so we can see how virtualization will impact operational costs:

As you can see from the diagram, when I say “minimal” – I don’t mean bare bones. This is a basic implementation on either owned, local servers or hosted servers that is redundant and will allow for failover and transparent (to the user) scalability.  A bare bones implementation could be just a web server/application server and a database server. But, in that case, every failure, upgrade, change, etc. will take the service offline.

This is an important distinction because SaaS is a cash flow business. Downtime equals lost opportunity. An opportunity lost in a SaaS business is lost forever. Not because you can’t eventually get the prospect back. You can. But in the meantime, you are still spending money to keep your operations running and available. In a SaaS business, operational costs for unused resources (staff, infrastructure, etc.) take away from margin. If taking a server offline means shutting off your service, you will lose opportunities for new business, reliability in the eyes of your clients, and the operating spend for your unused or under-utilized resources.

So, what does a basic redundant and scalable implementation for a SaaS application include?

• 3+ Web/Application servers in a cluster configuration.
• 2+ Database Servers in a replicating cluster to allow for failover.
• 2 Basic Log & Management Service Servers (could be one, but most implementations will use two).
• Firewall, Router, Load Balancer, Network Switch.
• OS, Web/Application Server, Database Server & Associated Licenses.
• Redundant Internet Access.
• Skilled Staff for implementation, maintenance, cluster and performance management.

Before we get to how we’re actually going to host this implementation, let’s also examine the time required. For implementation on bare commodity servers with experienced staff:

• Web/App Server (install OS, web server, application, apply updates, configuration, test, etc.) = 2 days
• Database Server (install OS, SQL database, apply updates, configuration, load database, test, etc.) = 3 Days +

Now most IT people will tell you it would take a little less time if you were setting up machines on a regular basis and you had some configured disk images ready. But we’re considering a small to moderate-size SaaS business, something beyond a beta phase startup, but certainly not a major service. Economies of scale are not available for server implementation in this size business.

While you’re considering the staff costs for an implementation – because you need experienced staff with an Internet-based skill set – you should also realize that these same implementation times will be true when you need to scale your deployment up during regular operation. Ok. We want to avoid as much of that cost as we can so we’ll use a managed server implementation like is available from most hosting companies. This is comparable to having hot standby servers with the OS, standard configuration, updates, and necessary web/app server or database server installations in place and ready. What times are we looking at then?

• Web/App Server (configure for application, install application, test, etc.) = 5 hours +
• Database Server (configure for application, upload database, test, etc.) = 1 day +

In both cases, the time and risk for implementing infrastructure means we will have to scale considerably ahead of need. As a consequence, most SaaS companies will not risk having less infrastructure deployed than is necessary to meet their peak usage requirements.  If service performance suffers, user satisfaction drops and churn rises. If the service cannot respond quickly to peak requirements, it is a lost opportunity and cash flow will suffer.

This implementation philosophy is known as Build-To-Peak.  What it means is most successful SaaS businesses will be over-provisioned more than half of their total operating time. And remember, in this scenario implementation is a manual operation. Someone skilled has to be available to do the work and be on standby to monitor the server and ensure it is working properly for some period of time after the server is stood up. This also means, we aren’t going to decommission infrastructure on a whim. We’re going to stay scaled to handle what we believe will be peak requirements until we’re very sure our need has dropped considerably and will stay that way for an extended period of time. Otherwise, we’re just throwing money down the drain.

So – what does this cost? Taking into consideration a managed server implementation with any of the major hosting companies (RackSpace, Peer 1, etc.) this implementation would have a cost of about $6,000 per month. That’s steep if you don’t have a lot of customers, but it isn’t  even close to all of your operating costs. Let’s assume a minimal staff load to just maintain the service while we hope our total number of clients rises high enough to give us a positive cash flow. What might we need?

In this scenario, I’ve considered that a lot of the staff will either be contractors (part-time) or an outsourcing firm. I haven’t included one-time license costs, office space and equipment, or any payment for the owner/manager. There is no application development cost because that is an investment, not part of operations. There is also no budget for on-going application development and very little or nothing for special promotions or marketing. At $26,900 a month, we are looking at a cost of $322,800/year for operations of a minimal SaaS business.

At this point, you have to step back and ask:

• How much are we charging for this service?
• How many clients will it take to reach positive cash flow and when are we going to get there?
• At what number of clients will our operating costs increase?

That last point is critical to consider. In SaaS, costs tend to increase in jumps.

Imagine: Your customer service and support person is getting too busy. You have to recruit another staff person, train them and get them up to full productivity before you need them or your service will suffer. In SaaS, costs come due ahead of income. That means, in a period of high growth, you are going to need a cash reserve or you will literally run out of cash trying to capture the new business.

You can see – even with a minimal implementation – the total cost of operations in a SaaS business could mean it will take a long time to reach a decent return on investment. If you haven’t modeled your business model properly you may never reach positive cash flow. In SaaS, business scalability is key and operational efficiency isn’t optional.

Now let’s get back to our basic discussion. What will “The Cloud” do to change this? For this size implementation, if we simply move it to virtualized servers on a standard grid-type “cloud” host it will actually cost more to operate per month.

That’s right: On a one-to-one basis, for a full month of usage, a virtualized server will cost more than a traditional, managed server. It will also require IT staff with a more advanced (expensive) skill set. It will do nothing significant to reduce total staff costs.

At this size, and with this kind of application architecture and implementation, the value of cloud hosting is marginal at best. In fact, most of the value mentioned in the bullets at the start of this article is going back to the hosting company that is managing hundreds or thousands of servers. At most, a SaaS company can only hope to shave a few hours off of server implementation and management by moving their application directly to a cloud hosting scenario.

So – why the heck would I say that SaaS companies could be saving 33-50% of their total operating costs by developing for cloud infrastructure?

How on earth can anyone recommend a cloud-based application for anything but the biggest companies?

You’re going to have to read the next segment of this series to find out.

And believe me – if you are planning a SaaS business it is an important lesson…

Over two years ago, we wrote a two part series about SaaS Metrics that has continued to spark interest in the subject. Since that article was written, Scio has consulted with well over 50 SaaS and Cloud companies through our SaaS Strategy Sessions, Workshops and most recently a program headed by FUMEC in Mexico.

This background has given us a broad view of the issues entrepreneurs should consider to plan and operate successful SaaS businesses. There are four common categories that these issues fall into:

• Business Model Scalability - Finding a scaleable, repeatable business model is key and very often lowest on the list of priorities.
• Operational Requirements – Most companies are laser focused on end user functionality. This isn’t bad in itself, but the fact is that SaaS businesses have to plan to manage operations with the least amount of cost and friction possible if they want to reach their full potential. Understanding the operational aspects of their business that can be built into the application and services is critical to avoid situations where business growth and cost control is constrained by operations that cannot scale efficiently.
• Managing to Metrics – The idea of metrics is widely accepted, but in practice, very few early stage SaaS companies have build the data feeds and internal procedures necessary to have the data for reporting and management. Without planning, it is very hard to back the data out of applications that are not set up to provide it.
• Product Planning – SaaS product planning is part business roadmap and part customer management in a carefully orchestrated system that produces what users need rather than simply complying with their wants. When it is done right, it yields a service that can continue to grow with the user community over the long run and produce a competitive edge that is very hard to overcome.

Recently, one of our partners, Rich Chapman of Softletter (SaaS University) asked us if we had developed a spreadsheet people could use to model SaaS metrics. With our client experiences in mind, we realized that we have talked a lot about using modeling to test business assumptions, but hadn’t provided any insight into how someone could build a simple modeling system and what data feeds and metrics dashboard might include.

To solve that problem, this article includes the Scio SaaS Metrics Workbook. This is an Excel Workbook with two spreadsheets. The first sheet has sample data included to highlight scenarios discussed in this article. The second sheet is blank with just the formulas so that you can use it without having to go through the process of cleaning out the sample data. So – if you want to “play along” as we discuss these metrics, you should go ahead and download the spreadsheet now.

A few caveats apply to this example spreadsheet:

• Every business model is its own special case. These metrics and the formulas they use are generally accepted and useful for modeling purposes. They are not however, a “one-size fits all” approach. For a deep dive into SaaS Metrics – I strongly suggest you look at Joel York’s excellent articles on the subject and Bessemer Ventures PDF that came out last Fall.
• A spreadsheet is not a complete approach to actually managing a SaaS business to metrics. Unless it is integrated with actual data feeds, a spreadsheet will require far too much manual data management and will eventually be discarded in the ordinary course of dealing with day-to-day issues. The best approach is to build the data feeds and display them a dashboard in the application. Unfortunately, for most implementations this means feeding some information into the report either from accounting processes or manual input. But, automating the reporting as much as possible is critical if you actually want to use metrics for managing your business. This means planning to provide the data as a part of application requirements. If you don’t, trying to get the data without the “hooks” built in will often prove impossible.
• This spreadsheet uses a 12 period window. The length of the periods don’t have to be months, although the Customer Acquisition Cost Ratio is generally managed on a quarterly basis. In a dashboard approach, a walking window could be very useful to see trends over time. The width of the window used is a decision you have to make to fit your business model. Of course, in the best case, a dashboard would use graphs of the key metrics with drill down reports just a “click-away” for more detail.
• Green, Bold entries should be feed directly from application data. This means your application needs to be built to capture and report on this data. If you don’t have these feeds at a minimum – it will be very hard to manage to metrics. Line 44 may bring some questions. Isn’t total revenue the same as renewal revenue? No, not in all business models. If you have transaction based revenue or utility-based features, your total revenue is different than your total renewal revenue.
• Blue, Bold entries need to be entered either directly or feed from accounting processes. This includes sales and marketing costs and operational costs. It is “fussy” to have to do this manually, but if you can develop a process and flow, it can be just be part of regular cost reporting within your organization.
• Clients are the entities that pay for the service. In a business-to-business SaaS application, this will generally be a company with multiple users. End-users are just that – individual application users who may or not also be clients depending on the business model.

So – with that in mind – let’s look at some SaaS Metrics….

Committed Monthly Recurring Revenue (CMRR) and Average Recurring Revenue (ARR)

Because the SaaS business model is predicated on a steady flow of recurring revenue, having a clear picture of your current standing is key. Using this figure, you can also derive the Average Recurring Revenue per Client which is helpful to understand if clients are generally adopting larger commitments or the average size is decreasing.

You will also see in this section, a set of formulas we use over and over. This is the Percent of Change from period to period and the Average Change. This is not a true trend line analysis, but it gives you an indication of where the metric is heading over time. This is important because in the day-to-day management of a business it is easy to miss the trends that are actually driving your business. In the example you can imagine a sales team crowing about their 28% growth in the 8th period and their 15% growth in the 12th period. But in the end, the average change of 6% tells a more important story of how recurring income is growing over time. Average change or trend analysis is a good way to smooth out the spot variations and help the team concentrate on the larger picture.

Retention Rate (RR) or Churn

When CMRR is growing, it can be easy to ignore the reality that many of the new clients don’t stay around long enough to pay off the cost of customer acquisition that comes from sales and marketing expenses. Startup companies often ignore this, hoping “we’ll make it up in volume.” The truth is that churn represents a steady cash leak that can eventually sink a new company. Most companies try to manage to 90% retention or better. In the spreadsheet example, you can see that the company is bouncing along the bottom with an average RR of 88.9%. Although income may seem good enough now, if the situation continues the cash burn could become a constraint on continuing product development. If there is underlying user dissatisfaction with the service, this will begin a spiral that the company may never recover from.

In Trial (IT), Time to Close (TC), and Close Rate (CR)

While not every SaaS business has a trial option, since most do, it is wise to have a way to track effectiveness of trials in bringing new clients onboard. Trials do work as a sales tool. The truth is that most SaaS buyers are already actively using Internet-based services and expect to be able to “try before they buy.” In some cases, the sales team may set up special trials for key customers, but generally these metrics do not track those special implementations. The point of looking the data coming from trials it not just to evaluate how many sales come out of them. You can find out a lot about how well the application fills the needs for specific verticals (if you have a way to collect data from prospects), if the application has as much of a “rapid uptake” as you suppose, how many testers typically participate in evaluations, how much data is generated (which can quickly become a push to sign a contract) and many other facts about the decision process. So – if you have a trial option in your business plans – set up data feeds that will help you adjust the application and the trial process to be more effective in closing sales.

Average Deal Size (ADS) or Average Revenue per Client (ARPC)

It is easy to confuse this metric with CMRR. Depending on the options available, deal size can vary depending on the period covered by each individual renewal and changes in the package purchased (number of seats, feature selections, prepaid transactions, etc.). This metric can help sales evaluate if clients are buying larger packages, changing feature sets, etc. Because the SaaS model is heavily biased toward recurring revenue, this figure generally does not include first time sales.

Average Revenue Per User (ARPU)

This metric is valuable in business models where a client buys multiple user IDs. Users typically require available support resources and in some instances may have access to features that burden utility-based resources like storage and data transfer. If you don’t track ARPU, you don’t have any way to determine if your revenue per user is beginning to making the pricing base unsustainable. Where multiple income streams are involved, it can be useful to track that income separately and use data to determine what kind of users are contributing the most to these revenue sources. Multiple income streams, beyond a simple subscription model, can be very valuable to a SaaS business if the subscriptions contribute enough to provide the base revenue necessary to sustain the business. Depending on variable income streams (rather than subscription income) to provide necessary operational income and profit however can be very difficult.

Cost of Service (CoS) or Cost to Maintain (CtM)

The cost of services and operations to maintain the application and client instances. This includes hosting charges, hardware and software renewals, support, staff operations, and outside services – everything it costs to operate. In a traditional hosting model, the costs tend to match the highest level of operational needs expected regardless of load variance over short periods. In a fully virtualized model, the costs can vary on a utility basis if the application is tuned to take advantage of elastic infrastructure capabilities. Regardless though, the operational costs are what they are – and that is what we are trying to model and view here. Here the running change is a key indicator again because it can offer insight into trends you might not see otherwise.

Average Customer Acquisition Cost (ACAC) or Average Cost to Acquire (AtC)

This is a “front-loaded” cost because you have to spend money on sales and marketing ahead of revenue. In web-based sales, it is hard to know the “lead-time” from the first moment a prospect comes in contact with the service through to sale closure. Only in the case of special marketing campaigns that include promotional codes can you actually begin to see how the sales cycle works. In the spreadsheet example, we’ve taken the simplistic approach of counting the previous period sales and marketing costs as the contributing factor for the sales in the following period. You could modify this to set a period that reflects your sales model better, but until you actually know the cycle, this is a good starting point and modeling assumption.

This metric also points out another factor: Most business-to-business sales models for SaaS include different subscription periods so you cannot simply assume that everyone is renewing every period. If the option is available, some may purchase on a monthly basis, some quarterly, some yearly, etc. In these cases, a separate report for the tracking the renewal period choices made by different market segments could be very valuable. These reports can answer questions like, “are larger enterprises actually buying the longer periods as we suppose?” “Is this market really acting like SMB’s and cautiously buying every month?” “Do clients tend to buy longer periods overtime?”

Customer Acquisition Cost Ratio (CAC)

This is a complicated metric and there are several ways you could look at it. The point is to aggregate costs and trends to help determine how long it will take to pay back the your sales and marketing costs on based on your current customer acquisition. The aim is to reach a ration better than 1. This means your costs are being paid off in less than one year by the revenue driven from clients. If the ratio dips to .5, it means it is taking two years. If the majority of your clients aren’t staying two years, you are losing money while acquiring clients. In a startup situation, when you are still carrying your initial development costs, this may be a perfectly acceptable situation – as long as you have enough cash on hand to carry your off the “runway.” So, in that way, you have to know your situation to know how to interpret what it is telling you. The example we have given is good for a “running company” but doesn’t reflect a startup.

Other metrics to consider…

Customer Lifetime Value (CLV) is an often cited metric but one that is hard to model in a spreadsheet like this. We’ve intentionally left it off, but that doesn’t mean you should leave it off your list of requirements. I suggest you look long and hard at the literature before you attempt to implement it though. You need to understand what you can determine in your data model and what is useful from a business reporting point of view before you set this metric for reporting.

There are lots of other metrics you might want to use. Largest Client % can be very important, particularly in situations when the total client load is not large. If a single client provides more than a third of the total revenue – it is time to start thinking about how to acquire a lot more clients to offset the risk that client presents if they “walk.”

If professional services are part of the revenue stream, it is important to be able to capture their contribution separately and to see if the balance between PS sales and application sales is sustainable. I’ve seen several models where the two sides of the business operate hand-in-hand, but seeing the contribution of each separately can help you understand how much of your resources you should be devoting to each.

This is our current modeling tool. We are using it now in our consulting practice and will continue to improve it based on feedback from clients and responses we get from users. It is daunting to look at – so I suggest first playing with some of the green and blue inputs to see what happens. If you are serious about managing your business to metrics, you will soon find yourself on the blank sheet running scenarios. And if you have questions or comments - please let us know!

“Scalability” is one of many cloud buzzwords that is fraught with confusion. Most of the time the term is used with a mixed meaning – covering both technical scalability provided by implementations of infrastructure virtualization and business model scalability. The problem is technical scalability by itself cannot impart scalability to a business model. But, on the other hand, technical scalability can be a crucial component of a successful and scalable cloud business model.

In this two part series, we will address the key technical capabilities required in a cloud service to achieve a scalable business model. I’m writing this article because we have found the confusion to be a common thread throughout many interviews and consulting sessions with software vendors bringing their products to the Internet as services. Almost without exception, vendors address end-user functionality clearly, but fail to address their own need to have a successful, repeatable and scalable business model.

A business model is said to be scalable when the incremental cost of acquiring, implementing, servicing and supporting a client drops as the number of clients increases. In a few business models, the service is repeatable but total costs remain relatively stable as the growth curve rises.  In these cases, incremental profit needs to flow from each new client regardless and attractive scalability will be hard to achieve. A fully-scalable business model is not constrained by resources such as skilled staff or materials. Full scalability is not achievable in all markets or business models. In all business models, the total incremental cost per client will eventually reach a point where it is zero or flat.

When the software industry was primarily selling licensed software – scalability was easy. ISVs would develop a software version once and sell it as many times as possible before investing in another version. Each incremental sale from a version lowered the total cost of goods for the ISV. ISV’s selling licensed software only noticed a constraint when the cost of support to each incremental client was more than the client’s share of the cost of goods generated by application development.

In a cloud service model, the challenge is to identify the services and features you must provide and then implement them so that the incremental cost of providing services for each client goes down as the number of clients grows. To accomplish this, the application has to be planned to support a scalable business model from the beginning. Otherwise the cost, risk and disruption from later changes will itself constrain scalability and cause costs to be higher rather until the investment is offset by profit.

The other challenge is that even a bad business model can look scalable during initial marketing ramp-up and growth.  Rapid growth can temporarily obscure the reality that the costs of implementation, support and operations required are not actually going down as the client base grows. Eventually though, as the growth curve begins to flatten and constraints appear, the pressure to maintain cash flow will make it apparent that the business model cannot be sustained long enough to reach an attractive profit.  In services where the amount of skilled staff required to implement each client is remains constant regardless of the number of client served, the cost and time required to acquire and maintain skilled staff will eventually become a brake on growth.

The length of the curve from the point where a business model begins operation to the point where it reaches a zero incremental cost per client, a flat level of cost per client, or a constrained-level of costs per client is the business model’s scalable range. As cloud service providers, the goal is plan the service so you are able to bring incremental costs per client to the far-end of the scalable range – to the point where the incremental costs per client are the most optimized.

The following points are aspects of the application and technical implementation that can provide leverage for business model scalability. They do not have to be achieved on day one of offering a new SaaS product or cloud service. However, to have a successful and scalable service from a business point of view, the application, its architecture and the infrastructure that supports it must be capable of achieving these points within a reasonable period of time without an application rewrite or major reconfiguration of the service.

Checklist for Business Scalability in the Cloud

1. Application architecture is component-based, uses web-services and the database is multi-tenant. In today’s development environment for cloud services, component-based architecture and web-services should be a given. These approaches provide much of the flexibility and continuous improvement we take for granted in online applications today. And without getting into a lot of religious battles about multi-tenancy – the point here is business model scalability. If you do not use the most scalable database architecture, you will always carry the risk and skills necessary to scale and manage alternative approaches.
2. Application maintenance and updates can be applied, or rolled back, to all client instances without business interruption and with minimal effort. In today’s market, cloud services are expected to have both continuous updates and operation. The procedures required to maintain application availability during updates need to be integrated into application development, straight-forward and repeatable.  Again, this has become an expectation across the industry. If your service has significant “down-time,” either planned or unplanned, your availability and reliability will be suspect from a client point of view.
3. Operational service functions (e.g., subscription management, billing, etc.) and reporting are part of the application but separated from client functionality so that they can be extended to additional applications over time, they can be tracked and managed. Operational functions generally scale in a linear fashion as the client base grows. If they are planned properly, they can be leveraged over multiple applications during the service lifecycle – driving down the operational cost. Not having operational functions integrated and automated as part of the application means manual processes will add to the cost of each client, payment cycle, billing change, etc. Manual operations will seriously constrain scalability and profit.. These functions facilitate client interactions with the service provider but they do not directly add to the value a client receives from the service. That doesn’t mean however they are unimportant. If these functions are not automated as part of the service they become a brake on growth as service operations struggles to keep ahead of growth while keeping costs to a minimum.
4. Application services can be purchased and embedded in the offerings of other services. Planning cloud services to allow other vendors to leverage application functionality creates additional channels at very low cost and greatly improves business model scalability. It is less important to know when or how it might happen that other vendors will want to leverage a service than it is to have the capability. When it does happen, it should require nothing more than a sales negotiation.
5. Outside services can be used to extend operational or client functionality as necessary. Application development is a part of the total cost of a cloud service. Just as it is important to allow other vendors to leverage service functionality in their offerings, it is equally important to have the option of leveraging other services so you can adapt their functions into the service without “redeveloping the wheel” unnecessarily. In early phases of the product lifecycle, software development will be the largest contribution to cost and will be carried as a burden over many clients before the business can reach positive cash flow. Leveraging outside services for selected functions (like pricing and billing for instance…) can lower the initial cost of development, significantly improve functionality for non-core needs and allow development effort to be focused on areas that have higher value for clients.
6. User interfaces can be extended to alternative platforms through web services and API calls to allow users to access to client functionality on emerging devices. The market for smart phones, tablets and mobile devices is exploding but it is also highly fragmented. Tying a service to a single end-user platform can constrain growth and put the application in a lockstep with the lifecycle and fortunes of the selected platform. Providing standard, documented methods to extend the service to end-user devices as they develop greatly increases the market and lowers the risk that extensive rewrites will be needed to adapt to new technology.
7. Client implementation is automated and immediate, on demand. Manual processes and delays required for operational functions like client implementations are costs and risks. Client implementations should not require anything more than authorization from the billing and settlement component of an application. This is a good example of the “consumerization” of software. The increasing use of online applications by consumers has created expectations for user-experience that now have moved to business software and services have to adapt to current client expectations.
8. Client instance configuration and integration is client-driven. One-off customizations and integrations should be strongly avoided in favor of embedded configuration choices and API calls that provide necessary data integration. Developing and maintaining split versions is simply too risky and expensive to be considered a sustainable business practice for SaaS and cloud services.  I’ve sat with many prospective vendors who say “our users demand customization” and they simply cannot imagine any other course. But the reality is the practice only works when clients are willing to deal with the costs of system integrators, delayed version updates, and the maintenance issues the practice brings in their own data center. When clients outsource to a service they expect you to bear the cost and risks. Standardizing a product to one version, including those configurations that take the place of 80% of the individual issues clients want to address, solves a great deal of problems for both the client and the service while it increases overall business scalability.

Is this all? Not by a long shot. We’ve got 12 more points in in the second half of this article. Business scalability is a core competitive edge in SaaS and Cloud Services – so please – join us for Part 2.

This is the fourth article in a series with excerpts from this year’s workshop titled, “How to Eat an Elephant – Developing a Real-World Product SaaS Product Roadmap.” Each of these articles will cover one part of core subjects in our Cloud Product Roadmap.  If you are just joining us – you can return to the first article in the series and find out more about the workshop background and other articles in the series.

Excerpt: How to Eat an Elephant Workshop by Scio Consulting

Planning and developing a Cloud product can be a daunting prospect, especially if using cloud-based infrastructure and services requires a departure from your “comfort zone” in more traditional installed and server-based products. One of the biggest concerns is developing the architecture for the project. For an implementation on something like Amazon Web Services how do you decide on the break-down of the application between the various services Amazon provides? Can you model the utilization scenarios and understand your costs in different situations?

Before you begin that consideration – let’s first make it clear that straightforward server virtualization is not the key feature of Cloud technology. Where Cloud implementations really shine in their value is in the ability to provide highly elastic capacity for specific application elements. This means the architecture can to break out client service elements that are based on utilizing elastic storage, moving large amounts of content, or have bursty characteristics.  Simple server virtualization schemes are limited reaching these scenarios economically because they are based on replicating a the server footprint rather than extending individual application  components.

On the other side of the coin, the “client side” of the application is not the only thing we’re concerned about. We also need to consider an operational side of the application that will support our product strategy and business model.  Hobbling operations by relying on manual processes to onboard customers and handle operations is not a sustainable way of dealing with the “back office details” of the service.  Generally, the operational side of an application will scale in a linear fashion. These components will scale in relation to the number of clients rather the usage patterns of application features by clients. That means utilizing different scaling strategies for various parts of the application. It also means cost modeling needs to be split between dynamic services that are consumed directly by client use and the more linear use patterns of components that are required to operate the service.

To understand the issues, let’s go back to one of the basic problems of a SaaS or Cloud product. There are several elements of these applications that are critical to operations but take considerable effort to plan, develop and implement:

• Multi-Tenancy – For most SaaS and Cloud Services, multi-tenancy is the core approach to application management, generating new instances, and structuring client data. Multi-tenancy is implemented in the database of the application itself.
• Application Management and Availability – Regardless of whether they are designed for the Cloud or not, modern applications are not monolithic. As we have discussed, they are actually a group of components that may have different use patterns and performance characteristics. Managing performance and scaling for the entire application is a basic requirement, but in a component model, you may need to manage performance and response at the component level to leverage the opportunities that true Cloud architecture offers.
• Product Management – Configuration, metering and billing are necessary to manage service packages that can be offered to clients. It is likely your packages will change over time, so your management system needs to be flexible and accept a wide range of scenarios. If you plan to leverage reporting to determine feature acceptance and value, you also need to be able to monitor feature-level usage over time.
• Usage Metering & Billing – If your service has usage-based billing, no matter how it works, you need some way to translate usage into billing. What seems simple can be come complicated quickly when you are faced with various combinations of partial months, changing user counts, differential pricing by user role, promotions, and other unexpected complications. Being able to respond to a changing elastic deployment. It requires much more effort to maintain reliability over changes to the core and operational sides of the application. In the best case, the basic architecture of the application platform supports the kind of load-balancing and instance version control that makes this possible.
• Subscription Management – A subscription is the package of services that a client has subscribed to and pays for in regular periods.  Although they are utility-based, very few Cloud Services can adopt a totally unpackaged, spot use model.  Granular spot use models are hard for the client to plan for because they can represent a risky “uncapped expense.”  And – unless they are based in regular use by a very large client base, they can result in a cash flow that is impossible to plan on. Because of this, regardless of how the service works, most SaaS and Cloud Services will have subscription-based packages and require on-going subscription management and the ability for clients to change subscriptions based on the current feature pricing schema.
• Access Control – Users must be able to access the features related to their role within their company subscription and if the service includes a suite of applications – their access needs to reflect their participation in the suite.
• Customer On-Boarding and Provisioning – When a customer signs up and is accepted, the application should be able to use the information provided at signup to provision a client instance and provide the necessary credentials, roles and access needed to the customer without any manual intervention or coding.
• Service Management and Configuration – When web services are used to provide the different components of an application, each service needs to be managed, versions need to be tracked and dependancies need to be respected. Without a management tool, this work needs to be done manually and can greatly complicate the job of managing new component rollouts.
• Contextual Logging – All servers and applications provide some level of logging – but if there is no mechanism to tie log information to users, clients and features, it can require a lot of effort to track down issues. Some sort of contextual information attached to logs speeds support efforts and improves overall customer support and reliability.

Taken together, these features require considerable planning and development effort to implement. They are not part of the core product value a SaaS or Cloud Service delivers, but they make the difference between a business model that operates and scales successfully and one that becomes burdened by too much overhead to scale repeatedly and successfully across enough customers to reach profitability. As you can see, these components will technically scale in relation to the number of clients the service has, not the features in use by clients and users.

SaaSGrid is one of a relatively small number of middleware servers or platforms that vendors can build on to provide these operational features and it will run either directly on servers or as virtualized servers on a service like Amazon Webservices. In either a virtualized or “bare metal” installation, a tool like SaaSGrid can lower the effort required to develop and implement a SaaS or Cloud product by as much as 60%.

So, when we get down to it – fully leveraging the capabilities of the Cloud for an application means understanding component-based architecture, the expected scaling characteristics and use patterns of each component, and finally the “orchestration” or web services messaging that allows all the components to act transparently across many clients as one application. On the business side, all of these elements have to be packaged and modeled to develop client offerings that have prices aligned to value and use. And – building a SaaS or Cloud product means planning for both client and operational functionality.

<Read the previous article in the series<

Do you need to know more about developing SaaS and Cloud Services to develop your application and business model? You should consider joining us at:

How To Eat An Elephant

Developing a Real-World 
SaaS Product Roadmap

28th April 2011

from 8:30 am to 1:30 pm
  (including breaks)

The Venue

Embassy Suites – Southeast

7525 East Hampden Avenue

Denver, Colorado

Prices

• How to Eat an Elephant Workshop – Standard price – $499
• Register NOW for our Denver Workshop and take advantage of our Apprenda-SaaSGrid Special Price
  

Agenda

• The Business Case for the Cloud - Assess if the Cloud is for you by identifying the business opportunity, investment needs, risks, etc.
• SaaS/Cloud Product Strategy – Define the competitive and positioning strategy for your product within your context and your market.
• Your Cloud Business Model - Define how your product will make money and what is needed to make it happen.
Developing your SaaS/Cloud Product Roadmap – Develop a tactical roadmap to align funding, development and marketing objectives.
• Key Technical & Functional Requirements of a SaaS/Cloud Product – Understand the architecture and functional elements required to deliver your service smoothly and profitably
• Cloud Readiness Checklist – Identify key requirements of SaaS and Cloud operations, customer support, legal, financial considerations, sales and marketing that you will need to prepare for to make your product successful.

You can take the workshop by itself or in conjunction with

SaaS University

THE Industry’s Most Comprehensive Cloud Application Conference

At the Embassy Suites, Southeast – Denver, Colorado – April 26th to 28th 2011

Prices

• SaaS University Package – Regular Admission – $999
• SaaS University Early Birds – $799 (Early Bird Registrations On April 15, 2011)

Get an additional discount from Scio – Regardless of when you register

• Because we are participating in this event, you can get an additional $150 off your registration.
• Just enter the Scio’s Discount Code: SCIOsave150 when registering for SaaS University.

Go to SaaS University Denver Registration Page

Installment 2: Our 2011 Workshop Series

This is the second article in a series with excerpts from this year’s workshop titled, “How to Eat an Elephant – Developing a Real-World Product SaaS Product Roadmap.” Each of these articles will cover one part of core subjects in our Cloud Product Roadmap. If you are just joining us – you can return to the first article in the series and find out more about the workshop background and other articles in the series.

Cloud Product Roadmap – Product Strategy

Excerpt: Lean Product Development and the Customer Development Process

The Product Strategy section of our Workshop covers the Lean Product Development approach and how it leverages the Customer Development Process. One of the opening slides mentions this quote, “Product strategy is like a roadmap, and like a roadmap it’s only useful when you know where you are and where you want to go.” (McGrath 2001)

This is the core idea behind our Product Strategy presentation and our Cloud Product Roadmap – helping companies considering SaaS and Cloud products to find where they want and need to go.

Lean Product Development rests on a basic premise: The product features that customers will value are unknowns. In the case of a software, regardless of how it is delivered, that means the features and services the application will offer are simply a hypothesis until they have been actually evaluated by users in their own context and use. By using Agile development and practices and evaluation by key customers, product management seeks a minimum feature set that will provide the greatest value while reaching the widest customer coverage. The Agile development approach provides a system of relatively short development cycles or iterations that produce features that users can evaluate immediately.

The Customer Development Process provides the basis for customer involvement, particularly during early product development. The founding team seeks clients who can understand the product vision. These clients will become early adopters and customer development partners during application development. The Agile development iterations are used to test the feature hypotheses with the customer development partners to validate that the features developed provide real value and will drive sales. The point is to find a product that reliably produces value for enough customers to sustain a business model that can be scaled.

Based on Customer Validation, the process continues into creating market demand and scaling sales to reach positive cash flow. The product development doesn’t end however, it continues throughout the lifecycle of the application as the customer pool grows, continually feeding discovery and learning. At the same time, the company itself manages a process of transition from being a product development organization to an operational machine that can continue to execute and serve customers as sales scale.

The key starting point for this process of product and company building is finding the Minimum Viable Product (MVP). This is a product version with the minimum features needed to solve the core problem of the target market. In most cases, it is a lot less product than is necessary for a market release. This is an important difference from the traditional product development process where the aim is to bring together as robust and complete a feature set as possible that will fend off possible competitors and produce an apparently over-whelming feature advantage. This is possible because traditional product development processes depend on the assumption that the market is known and the needs of users are fully understood. It works well when the product line has a solid history of success and the product management team has been participating in the market for some time.

Internet-based applications and services, however, have the possibility of reaching new markets and customer segments that were out of reach in the locally-installed, licensed model – even for ISVs in the market with products. While a SaaS or Cloud product developed with traditional product development methodology could capture its existing customers, it could easily miss newly available market segments with unexplored problems.

To address this gap, Lean Product Development and the MVP approach are aimed at testing the value hypothesis and allowing the visionary early adopters to “fill in the gaps” when it is validated that the MVP is solving a real problem. If the MVP isn’t solving the core problem, the cost of re-evaluating and approaching the opportunity from a different direction is small and early adopters can aid in defining the issues contextually. In this approach, the risk of wasted effort and time are minimized, and the opportunity for clarity in solving the real problem is greatly improved. Once the MVP is proven, the vision can continue to be achieved in small increments without the waste of producing a laundry list of features that in the end no one will pay enough for to realize a profit.

The advantages of Lean Product Development:

• Reduces the risk in bringing a new product to market
• Reduces investment prior to positive cash flow
• Accelerates time to market with a viable product
• Aligns product features with proven customer needs
• Provides a rapid, dynamic feedback loop from the customer that drives product design, product packaging, price structure, and competitive positioning

The competitive positioning issue is one that is worth a few extra words. The Customer Development Process engages customers and creates a shared sense of product destiny. In turn this increases customer satisfaction, loyalty and retention. These are critical to success for online services like SaaS and Cloud Products. It produces a product that fits a client base tightly and is a barrier to competition. It has been shown that products with a Replace Strategy need to be perceived to be nine times better than the product they replace to gain market traction. The longer a customer is retained in a Lean Product Development model, the greater the barrier the competition will have to overcome.

<Read the previous article in the series – Third Article in the Series>

This is just one of many critical subjects we cover in our workshop.

This series will be covering more in the days leading up to the event. But reading these excerpts will not give you all the material and is no substitute for attending and joining in the discussion.

How To Eat An Elephant

Developing a Real-World 
SaaS Product Roadmap

28th April 2011

from 8:30 am to 1:30 pm
  (including breaks)

The Venue

Embassy Suites – Southeast

7525 East Hampden Avenue

Denver, Colorado

Prices

• How to Eat an Elephant Workshop – Standard price – $499
• Register By April 1st for our Denver Workshop and take advantage of our Early Bird Pricing

Agenda

• The Business Case for the Cloud - Assess if the Cloud is for you by identifying the business opportunity, investment needs, risks, etc.
• SaaS/Cloud Product Strategy – Define the competitive and positioning strategy for your product within your context and your market.
• Your Cloud Business Model - Define how your product will make money and what is needed to make it happen.
Developing your SaaS/Cloud Product Roadmap – Develop a tactical roadmap to align funding, development and marketing objectives.
• Key Technical & Functional Requirements of a SaaS/Cloud Product – Understand the architecture and functional elements required to deliver your service smoothly and profitably
• Cloud Readiness Checklist – Identify key requirements of SaaS and Cloud operations, customer support, legal, financial considerations, sales and marketing that you will need to prepare for to make your product successful.

You can take the workshop by itself or in conjunction with

SaaS University

THE Industry’s Most Comprehensive Cloud Application Conference

At the Embassy Suites, Southeast – Denver, Colorado – April 26th to 28th 2011

Prices

• SaaS University Package – Regular Admission – $999
• SaaS University Early Birds – $799 (Registrations by April 1st, 2011)

Get an additional discount from Scio – Regardless of when you register

• Because we are participating in this event, you can get an additional $100 off your registration.
• Just enter the Scio’s Discount Code: SCIOsave100 when registering for SaaS University.

Go to SaaS University Denver Registration Page

Introduction to Our 2011 Workshop Series

This is the first article in a series I will be writing over the next several weeks with excerpts of this year’s workshop titled, “How to Eat an Elephant – Developing a Real-World Product SaaS Product Roadmap.” Each of these articles will cover one part of core subjects in our Cloud Product Roadmap.

Background

First, some background on our workshop. The concept behind the workshops comes from our consulting experience at Scio. We provide Nearshore Product Development for SaaS and Cloud products from our Development Center in Morelia, Mexico. Our clients come from a wide range of industries and cover the range from single entrepreneur startups to multi-national corporations. We focus primarily on the Americas because that is where we can leverage our collaborative Nearshore model best, but we also provide services for companies in Europe and Australia where our background with SaaS applications is particularly important to the projects. Our services center around software development for SaaS and Cloud applications, but in the course of developing apps for our clients we also realize it is critical we contribute what we can to their success.

Over the years we have been providing our services we have found that clients repeatedly hitting the same “bumps” in the road to releasing a service. Some of the issues are business and some are technical. In response, we began to develop consulting services that could help our clients avoid those problems and have a clearer picture of the way forward. These services are strong and well-received, but basically focused on the needs of a single client prior to development by our team. They don’t scale in a way that we could easily provide them in a more generic setting to multiple companies. So – to fill that gap – we developed a more formal approach to what we began to call the Cloud Product Roadmap.

The idea of a Product Roadmap is not new and we’re certainly not the only ones to use the idea. Our particular focus however brings a concentration on the factors that are critical to success in the field of SaaS and Cloud Services. Broadly, our roadmap leverages the concepts of Agile Software Development, Lean Product Development, Customer-Driven Product Management, and the collaborative environment they require at all levels of the project. From our experience and a growing number of practitioners in the field, this is the secret sauce behind a growing number of successful SaaS and Cloud products. The elements of this roadmap are increasingly seen as the standard for product development and management in the field.

The workshop itself is an intensive, interactive discussion of the critical issues and decisions that need to be made to launch, manage and maintain a successful SaaS or Cloud application. It covers both the business and technical aspects involved as well as the iterative cycle of decisions that have to be navigated to arrive at a complete roadmap. The events are intentionally small to provide more opportunities for discussion and adjustment to the needs of the attendees.

So – what do we talk about in our workshop? Here is an except from two slides in our Business Model presentation:

Cloud Product Roadmap – Business Model

Excerpt: The Democratization of Entrepreneurship

A successful business model in SaaS and Cloud Products evolves from a series of iterations between the concepts for the product and the business that supports it while deriving income from the value it provides clients. The process has been best conceptualized in the writings of Steve Blank and Eric Ries and identified as the “Lean Startup.”

The key point is that the ideas behind business model development and the process of developing a successful software product have changed in the last few years. Experience and technology have come together in a way that makes it much easier for individual entrepreneurs to enter the field.

Consider the traditional barriers that confronted entrepreneurs:

• Long, technically-driven development cycles – A lot of the basic functionality required didn’t exist. There where no models or platforms to build on. Development required research and highly-skilled, technically creative development teams. Development cycles were long, feature lists were exhaustive, and the risks were high. Imagine a development cycle of more than a year for a platform that has a regular renewal cycle of three years. Add to that an implementation environment that varies from client to client because they are all isolated. There is a lot of risk to absorb in taking on a project like that and most individual entrepreneurs don’t have that kind of resources.
• The high cost of the first customer – In this environment, the first customer implementation carries tremendous cost and risk. If there is a failure in the implementation or the product fails to meet expectations, it becomes very difficult to recover. Is the product wrong or the customer a unique case? It is hard to know. If you go forward assuming this case is unique, you continue to carry the risk that you have spent a lot of money going down the wrong road. If you assume this is a clear indication that your product is at fault, you could increase your total cost and risk even more by spending the effort to fix the perceived problems. This is exactly the risk that high license fees had to address. The entrepreneur fronting the development of a complex product is taking a lot of risk in an installed environment.
• Limited financing options – The high capital needs and limited options available for a pool of thousands of new businesses created a focus on funding rather than the product itself. This was the era of the one-page business model and the endless cycles of meetings with venture firms in Silicon Valley.
• Expertise in entrepreneurship and product development concentrated in a few places – The skills and resources needed to form a successful team concentrated in parallel with the financial firms that could handle the risk and investment. Outside of Silicon Valley and a few other areas, it was very hard to find resources.
• High failure rate – Entrepreneurism is a process of failure. If you are averse to risk and failure, your upside is badly constrained. With the high investment required, only a few could stand the risk of a new project.
• Slow adoption of new technology – By its nature, the success of a software product depends on the adoption of the basic unit of implementation – the computer or platform that runs the software. If the initial cost is high, skilled resources are limited, and the knowledge of the value that can be derived is low – adoption is limited to the few brave souls with the vision and resources to take the plunge. When communication itself was slower and less driven by the individual, it was very hard to build acceptance of new technology.

What has changed?

• Compression of the product development cycle – Instead of trying to cover every possible aspect of a founder’s vision, current product development processes focus on the minimum number of features required to deliver value. Using Agile development techniques, a functional application can be evaluated much sooner and put in front of customers at a much earlier point. Add this to the ubiquitous delivery medium of the Internet and you have the capability to reach a wide range of prospective customers in a very short period of time. This allows you to leverage customer much sooner in the development cycle and correct your course while your risk is still manageable.
• Lower funding requirements – Over time the number of tools and services that lower the effort required to build and implement a product, especially in current cloud configurations, has increased geometrically. This lowers the time-to-market and investment needed, which creates an environment where investment can be forestalled until a ramp up is justified by market acceptance, positive cash flow and real customers.
• Funding tuned to encourage and manage the search for a sustainable and scalable business model – Smaller steps in the development cycle, success-based funding, with a focus on waiting for key investment until a repeatable and sustainable business model is found. In fact, in many business to business models, venture funding is not needed at all. Positive cash flow and traditional business instruments can carry the load.
• Entrepreneurship recognized as a management science - The overarching process and philosophy is well understood. A successful business model is not luck. It is achieved with a roadmap approach that can be repeated over and over.
• The consumer Internet paves the way – The acceptance of the Internet by consumers and the change in their perceptions of technology is becoming part of business DNA.

The Second Installment in this Series is now Available >

So – Are you considering or developing a SaaS or Cloud Product? Are you operating a Service that isn’t reaching it’s potential? Do you want to know more about how you can leverage the success others are having in the field?

• How are you going about the process of business model and product development? Is it serving you?
• What do you know about current techniques and experience in the field? Can you evaluate which ideas could work for you?
• Do you have a product roadmap?  Do you know how to put one together and use it?
• Do you know how to navigate your product to a successful launch while minimizing your cost and risk?
• Do you know what it takes to operate and maintain your service while continuing to respond to your customers needs?

…This workshop answers these questions and many more. It leverages our field experience across many projects and many situations

How To Eat An Elephant

Developing a Real-World 
SaaS Product Roadmap

28th April 2011

from 8:30 am to 1:30 pm
  (including breaks)

The Venue

Embassy Suites – Southeast

7525 East Hampden Avenue

Denver, Colorado

Prices

• How to Eat an Elephant Workshop – Standard price – $499
• Register By April 1st for our Denver Workshop and take advantage of our Early Bird Pricing

Agenda

• The Business Case for the Cloud - Assess if the Cloud is for you by identifying the business opportunity, investment needs, risks, etc.
• SaaS/Cloud Product Strategy – Define the competitive and positioning strategy for your product within your context and your market.
• Your Cloud Business Model - Define how your product will make money and what is needed to make it happen.
Developing your SaaS/Cloud Product Roadmap – Develop a tactical roadmap to align funding, development and marketing objectives.
• Key Technical & Functional Requirements of a SaaS/Cloud Product – Understand the architecture and functional elements required to deliver your service smoothly and profitably
• Cloud Readiness Checklist – Identify key requirements of SaaS and Cloud operations, customer support, legal, financial considerations, sales and marketing that you will need to prepare for to make your product successful.

You can take the workshop by itself or in conjunction with

SaaS University

THE Industry’s Most Comprehensive Cloud Application Conference

At the Embassy Suites, Southeast – Denver, Colorado – April 26th to 28th 2011

Prices

• SaaS University Package – Regular Admission – $999
• SaaS University Early Birds – $799 (Registrations By April 1st, 2011)

Get an additional discount from Scio – Regardless of when you register

• Because we are participating in this event, you can get an additional $100 off your registration.
• Just enter the Scio’s Discount Code: SCIOsave100 when registering for SaaS University.

Go to SaaS University Denver Registration Page

I can think of many reasons to be at SaaS University in Washington, DC, July 20-22, beyond my session and Scio´s workshop. But I want to be clear: The sessions at SaaS University are always changing, always relevant to developing SaaS products and successful SaaS businesses. It is the only venue available with a focus on helping SaaS vendors navigate a complex business model.

This time I have the honor to be presenting a session on the second day titled: Increase Your Bottom Line Value with Multi-Tenancy.  Here is the session summary from the University agenda:

There is a lot of debate about multi-tenancy.  Most of us understand its value from a technical point of view, but what can actually translate to our bottom line?  How does it change what we are able to do to increase operational efficiency and customer retention?

Multi-tenancy is not a magic bullet, despite what you may have heard. Implementing your SaaS application with a multi-tenant architecture offers great returns, BUT ONLY if you understand how to leverage it along with metrics, operational automation, your ecosystem, and the network effect of your customer base – effectively.

This session will answer questions concerning the value of:

• Different architectures for implementing multi-tenancy and maintaining flexibility.
• Reliability, scalability, maintenance, and product evolution to your clients.
• Multi-tenancy in operations across your product organization.
• Implementing metrics in a multi-tenant application.
• Your customer and user network, delivery network and ecosystem under multi-tenancy.
• Methods of implementing multi-tenancy without breaking the bank or slowing product release

This session is strategic for C Level executives and product managers planning, implementing, or enhancing a SaaS offering. Participants will come away with a clear understanding of how they can leverage multi-tenancy at every level of their service and increase their bottom line potential.

This session is replacing a similarly titled session by planned Lincoln Murphy because of a scheduling conflict he has encountered. I want to thank him for his recommendation that I take his slot. I must say, although I want to keep the same broad focus for this session, my approach to this subject is different than Lincoln´s. My background with multi-tenancy comes from planning SaaS products with Scio´s customers and many years of working with companies on Internet-based business models.

In itself, multi-tenant architecture is not new.  The same could be said of the SaaS business model. What is still new is the broad market attention to on-demand services and the opportunities that virtualized infrastructure gives to business. The knowledge of how to leverage architecture and technical choices to impact product features, customer value and operational effectiveness is what is lacking in my experience. This is what I will lead discussions on in my session at SaaS University.

In addition, if you aren´t aware of it, SaaS University has a third day of full day workshops that provide a ¨deep dive¨on specific subjects. Our own session is Charting Your Course to SaaS, which will help it´s participants navigate all the choices they face in developing a SaaS product while they develop a road map that can get them to market and positive cash flow sooner.  I can also personally recommend Jim Geisman´s Right Pricing Your SaaS System: Beyond the Basics – Advanced Workshop. Jim and I had the opportunity recently to give a workshop together and I greatly enjoyed the experience, and I know our audience did also. Ideally, product teams should consider sending representatives to both workshops because they are complimentary points of view that are very important to understand.

So, with that background, here is the overview of our one day session at SaaS University for July 22, 2010:

Charting Your Course to SaaS – SaaS University, Washington DC, May 22

This is the third time we’ve offered this comprehensive workshop on SaaS and it continues to evolve as we respond to the needs of our participants. Following our joint workshop with Jim Geisman of Software Pricing Partners, we’ve continued to tighten the content and for SaaS University, will offer a more interactive format for this workshop, especially during the afternoon. The aim is to keep it small enough to allow everyone a chance to move the discussion toward the issues that interest them most.  It remains however, the only workshop that covers the business, operational and development issues that are critical to success in SaaS.

Companies that can benefit by attending this workshop:

• A new venture or as an ISV with on-premise products considering developing a SaaS offering
• A service company with significant vertical expertise than could be delivered and monetized in a SaaS model.
• An existing SaaS provider who made choices opportunistically that now constrain growth and cash flow.
• A SaaS entrepreneur with limited funding that needs to achieve positive cash flow early with products that evolve with the market.

Company challenges this workshop can help overcome:

• Building out a suite of products but are unsure of the strategies, metrics, and operational models needed to grow.
• Developing a framework for sorting out technical and strategic choices required to move to the SaaS business model.
• Facing significant operational problems including efficiency while keeping churn under control in an existing SaaS product.
• Developing a product roadmap and unsure of what can be accomplished and timeframes

Topics to be Covered:

• How is a SaaS Product and Business Different?
• Reference Framework for Creating Your Roadmap
• Making Strategic Development Choices
• Operating A SaaS Business by the Metrics
• 10 Ways to Fail at SaaS
• Applying Lessons Learned to Your Issues

Who Should Attend?

This workshop and seminar is important for anyone considering a SaaS product, in the process of developing a product or offering a product that hasn’t reached its potential, including: Entrepreneurs, CXO’s, product managers and key executives in startups, vendors moving to SaaS or existing SaaS companies.

About Your “Professor”

Mike Dunham, Vice President, Service Engineering for Scio Consulting, has over 25 years background in the development and introduction of new technology working with startups, government and the largest enterprise software companies. He has worked with Scio for five years, regularly authors articles on SaaS and the software industry and hosts a series of podcasts on SaaS best practices. Mike leads Scio’s professional services helping companies develop and bring to market new SaaS offerings.

The workshop costs $695, but you can get an Early Bird Price of $495 when you combine it with your SaaS University registration - total package price of $1290. As a way to bring together a great amount of information in a short period of time, the combined package is a great opportunity. As we get closer to the event, I’ll expand on the agenda, but this is a great time to start planning and get your team together to attend SaaS University in Washington, DC!  I hope to see you there…

The relentless change brought to us by the consistent doubling of computing power that Moore’s Law describes continues and is now likely to change at least some SaaS applications in the near term.  What do I mean? Consider – we now have a very competitive mobile application market and thanks to Google Chrome and now Apple Safari, it has crossed to the desktop on browsers.

Meet the New Paradigm

The event that brought this to mind was the announcements of the release of Safari 5.o.  Leaving out the typical “improved performance” claims – two things were apparent – it is now a platform and it is designed for use in a cross-platform, mobile environment. On the platform side, Safari has joined Chrome in providing an extension system that allows developers to in effect, build secure and stable, rich clients into the browser. We’ve seen this for a while in the form of the “app stores” that are proliferating for mobile devices like smart phones and the “iPad” category (however you define it).  On the mobile, cross-platform aspect, the browser is now tuned for mobile users.  It is very noticeable if you try the new Reader function of Safari. It is quite usable on a desktop or laptop, but it really shines in the limited real estate of mobile devices. Multiple page articles merge seamlessly into one. Space wasting banners, sidebars and menus disappear. The browser becomes a credible, focused article reader for all devices.

What does this mean for SaaS? Take this evolving “browser as a platform” trend together with the announcement of iOS 4 (the artist formally known as the iPhone OS) and the growth of the Google Android and Chrome OS and you have a quickly changing landscape of operating systems tuned for a rich mobile environment and a browser-centric application implementation system. These advancements mean the expansion and adoption of HTML 5.0 is moving even faster than many of us thought. They will make the often tricky environment of JavaScript and Ajax less of an issue and the user experience of properly-tuned SaaS applications much more fluid and “desktop like.”  It means that locally-installed, OS dependent applications are becoming ever less relevant and cross-platform, network-delivered services are becoming increasingly rich and useful.

Frankly, as interesting as this news is, it also points out that SaaS is a very fluid environment. Keeping ahead of it is increasingly difficult. Knowing how to manage a SaaS product and chart a plan to navigate development is critical. Knowing what you need to support scalable SaaS operations and what you should embed in the application is critical. Understanding your user environment and what is expected in your market is critical. The list goes on and there has to be a way to understand the landscape and to make the choices easier. And the point of this article is – there is – it is SaaS University.

As a company, Scio has stayed involved with SaaS University because it answers the need our clients and the SaaS community has to have current knowledge about our industry and important issues. Because Softletter produces regional events quarterly, you can plan to attend when and where it makes sense and take advantage of the evolving content as you need to. The tracks and workshops are well attended, but generally sized so the sessions can be interactive and remain relevant. If you’ve been to the larger, vendor-led conferences – SaaS University offers content that is focused on providing valuable insight to SaaS entrepenuers.

The next SaaS University event is in Washington DC, July 20-22, 2010. There is a full two-day agenda of sessions in two tracks covering a wide range of subjects and a third day that offers a choice of four in-depth workshops. On that point in particular, I want to highlight our own workshop, Charting Your Course to SaaS.

Charting Your Course to SaaS – SaaS University, Washington DC, May 22

This is the third time we’ve offered this comprehensive workshop on SaaS and it continues to evolve as we respond to the needs of our participants. Following our joint workshop with Jim Geisman of Software Pricing Partners, we’ve continued to tighten the content and for SaaS University, will offer a more interactive format for this workshop, especially during the afternoon. The aim is to keep it small enough to allow everyone a chance to move the discussion toward the issues that interest them most.  It remains however, the only workshop that covers the business, operational and development issues that are critical to success in SaaS.

Companies that can benefit by attending this workshop:

• A new venture or as an ISV with on-premise products considering developing a SaaS offering
• A service company with significant vertical expertise than could be delivered and monetized in a SaaS model.
• An existing SaaS provider who made choices opportunistically that now constrain growth and cash flow.
• A SaaS entrepreneur with limited funding that needs to achieve positive cash flow early with products that evolve with the market.

Company challenges this workshop can help overcome:

• Building out a suite of products but are unsure of the strategies, metrics, and operational models needed to grow.
• Developing a framework for sorting out technical and strategic choices required to move to the SaaS business model.
• Facing significant operational problems including efficiency while keeping churn under control in an existing SaaS product.
• Developing a product roadmap and unsure of what can be accomplished and timeframes

Topics to be Covered:

• How is a SaaS Product and Business Different?
• Reference Framework for Creating Your Roadmap
• Making Strategic Development Choices
• Operating A SaaS Business by the Metrics
• 10 Ways to Fail at SaaS
• Applying Lessons Learned to Your Issues

Who Should Attend?

This workshop and seminar is important for anyone considering a SaaS product, in the process of developing a product or offering a product that hasn’t reached its potential, including: Entrepreneurs, CXO’s, product managers and key executives in startups, vendors moving to SaaS or existing SaaS companies.

About Your “Professor”

Mike Dunham, Vice President, Service Engineering for Scio Consulting, has over 25 years background in the development and introduction of new technology working with startups, government and the largest enterprise software companies. He has worked with Scio for five years, regularly authors articles on SaaS and the software industry and hosts a series of podcasts on SaaS best practices. Mike leads Scio’s professional services helping companies develop and bring to market new SaaS offerings.

The workshop costs $695, but you can get an Early Bird Price of $495 when you combine it with your SaaS University registration - total package price of $1290. As a way to bring together a great amount of information in a short period of time, the combined package is a great opportunity. As we get closer to the event, I’ll expand on the agenda, but this is a great time to start planning and get your team together to attend SaaS University in Washington, DC!  I hope to see you there…

Last week our team, like lots of other members of the SaaS community, attended the OpSource/SIIA SaaS Summit 2010 – titled, “All About the Cloud.”  We had a busy and meeting-filled week, as I’m sure many did.

Because SIIA and OpSource gave this conference jointly – it was somewhat different than the OpSource led conferences we have attended in the past. Instead of being an industry conference tilted towards a single vendor’s customer base and prospects, it was much broader, bringing in a wide array of SaaS vendors and industry providers.  Since OpSource has been an industry leader for some time, I wouldn’t attribute the change entirely to the influence of SIIA. More likely it was the combination of the two constituencies along with a bit of a push from the uptick in the economy. Whatever it was, it was one of the biggest groups I’ve seen for SaaS/Cloud conferences in a few years.

It was perhaps most surprising to see the “maturity” of the industry in our guests. Most of the vendors were not from start-ups or ISVs moving to SaaS – instead they were established SaaS vendors – regardless of the lifecycle stage of their product offerings.  This shifted the conversations we had at our booth from “what does it take to build a SaaS product?” to “how do I scale my architecture?” or “how can I extend my offering to bring new services to my customers?”

This is a good thing to see, but I wish the presentations had been more geared to the audience and less to information about vendor’s products, but it could be said equally that no one knew for sure how the attendance would balance out long enough in advance to plan for it. I think that will even out next year, now that there is some history in the combined event.

Jim Geisman and I gave a workshop following the summit that was quite successful as we “filled the house” with as many guests as we could comfortably engage with. It was a wide-ranging group with representatives from some of the largest software vendors in the market to some new entrants from Latin America.  If there was a common theme among them it was the need to understand the options and structure of product development and pricing for SaaS. The folks from DreamSimplicy were good enough to feature a video of our workshop on their website.

There is certainly a void when it comes to clear information that isn’t filtered by a supplier’s agenda. We all do it – but there are also some who push their value above everything else. And, unfortunately, there are several instant pundits in the industry who really have less background than opinions.  From that point of view, I am proud to be associated with someone like Jim Geisman for this workshop because his background shows in the depth he can bring to the subject of pricing.  To say you can’t “afford to get your pricing wrong” may be a bit of an overstatement – companies change their pricing and survive – but it can certainly be as much of a market killer as developing a product that misses the mark.

In no particular order then – some notes and learnings from the Summit:

• Pick your strategy, play through, check your metrics, adjust and play again. I saw several companies who were trying multiple strategies for product, pricing, marketing, etc – simultaneously.  The result is – every attempt is a one-off with no way to measure one against the other logically or if the strategy might or might work if tried more than once.  The people trying to execute on all these ideas are playing a difficult game. Which idea really has legs? Which one do we really want to go with? And by the way – what do their customers think of this apparent lack of single purpose?  It’s difficult to navigate no matter where you stand.
• Look for your weak spots, eliminate them or optimize as well as possible. I heard many stories of early decisions that will eventually put a SaaS company in a no win situation.  Your infrastructure maintenance costs are eating into your cash flow at an ever increasing rate as you grow. Or – perhaps you want to change your pricing or offer a discount and it seems like the only way to do it is take payments manually and adjust the books, unless you want to redevelop your pricing and billing system…. It is easy to say you might have seen these things coming, but that’s Monday morning quarterback speak.  It sounds too simple, but there is help in the Theory of Constraints: First, optimize the situation as well as possible, looking for ways to manage the issue at best you can. Don’t stop there, leverage the stop gap only as long as needed to develop a true solution to the problem.  If you’re losing opportunities or burning cash in SaaS, you’re killing yourself, slowly but certainly.
• If you have an opportunity to speak to your peers and prospects, give them value. This sounds a little simplistic, but it’s worth a thought.  We need to take every opportunity we can to expose our products to new customers, especially in this tight economy, but you can’t spend the time you’ve been given with a blatant sales pitch.  The audience paid to sit in front of you.  What can you give them for their attention? Knowledge. What do you know? What have you seen? What experience do you have you can share? If that is the sum total of your talk, it will be remembered. If it is embedded in your new product announcement, it is more likely people will hear it.  To many of the presentations at conferences today are symptoms of our economy.  Our audience is looking for positive news and knowledge, just like we are.
• SaaS is a business model – not a technology. I still see far to many attempts to sell SaaS as a technology and the same is true when we switch to using “cloud” as a substitute term.  There are technical advances that are becoming available because of the growing SaaS/Cloud market, but they are just enhancements of what otherwise is a service-led, cash flow based, business model.  Companies in the field need to be successful at reaching an adequate size market with a positive cash flow and technology can only assist in achieving that goal.  Understanding the business of online services and planning to scale effectively is critical to success.

I hope to get more chances this year to get out and be in the field and at conferences to hear and share more ideas and experience.  It is a great opportunity to learn more about what is happening “inside” the business of SaaS.