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.

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!

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

Our workshop with Software Pricing Partners following the SaaS Summit: All About the Cloud is now finalized! Seating is limited so please check the details below and sign up NOW:

SaaS Offerings: How to Develop, Price, Operate, and Succeed

• One Day SaaS Executive Workshop Covering Technical and Business Topics
• May 13, 2010 at the Donatello Hotel (near Union Square) San Francisco

Executives responsible for succeeding in the SaaS market need to make a series of critical choices in developing, packaging and selling their offerings. This one-day workshop provides the insights and tools needed to make the right choices.

Many of the challenges SaaS companies face can be met by balancing and integrating technical considerations with the business aspects of SaaS. Companies that can do this can bring their products to market rapidly and become cash-flow positive quickly.

This workshop is the first to integrate pricing and business models with development and deployment. The workshop will be held on May 13th, the day after the OpSource and SIIA event SaaS Summit: All About the Cloud at the Westin St Francis Hotel on Union Square in San Francisco. The workshop venue is conveniently located one half-block from the St Francis, at the Donatello Hotel on Post Street.

Which companies 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 pricing 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.
• Ensuring the pricing model, development framework and operational plan will work in complex, highly competitive markets.

Topics to be covered:

• What Makes the SaaS Model Different and Difficult?
• Making Development Choices Strategically
• How to Choose an Effective Pricing Metric
• Creating a Lean Product Development Roadmap
• Using Packaging and Licensing to Increase Success
• Finding the Right Price Levels and Discounts
• Operating a SaaS Business
• Auditing Your Plans with a SaaS Reference Framework

Because of the value of this workshop, the importance of the SIIA/OpSource conference for SaaS providers and the convenience of the venue, this is an excellent opportunity to “put it all together.” The workshop content makes it well suited to a mixed group of business and technical members of your team because it joins the issues of both sides into a single view.

Per Person Pricing

Group Promo Codes

Three or more members of the same team:

• On or before May 3rd – 57KA5G
• After May 3rd – 7GNGBH

All attendees will receive copies of the workshop materials. The workshop fee also includes a “working lunch” and refreshments during the day.

Secure Registration with Acteva.

Hotel

The Donatello Hotel has a limited number of rooms available for workshop attendees at $139 during the period of May 9-14. This is an excellent opportunity to save with a very convenient location if you are also attending SaaS Summit/All About the Cloud Event.

• To receive this discounted rate, you must the contact the hotel directly at 415-441-7100 – and ask for In-House Sales and  the “SCIO Pricing” discount.

About the Speakers

Michael Dunham, VP of Service Engineering – Scio Consulting
Mike Dunham has more than 20 years of hands-on experience helping major corporations and government agencies succeed in an increasingly technical environment. As Scio’s principal consultant, Dunham provides clients insight into trends that affect business and technology planning so the processes Scio uses can bring clients’ ideas to life. As the VP of Service Engineering, Michael defines Scio’s service products and operational processes. A native of Sacramento, CA, he holds a bachelor’s degree in business administration from the University of California at Davis.

Jim Geisman, Principal and Founder – Software Pricing Partners
Jim is an acknowledged expert in software pricing and, since founding the firm in 1982, has helped several hundred companies develop effective pricing models and strategies. His consulting spans established and emerging software companies delivering B2B solution via desktop, enterprise-class and, more recently Software-as-a-Service / on demand software. Jim has been a board member or advisor to several early stage technology companies. He holds degrees in Electrical Engineering from Tufts University and an MBA from Harvard Business School.

A quick introduction on our podcast:

I’ve seen a lot of different “roadmaps” for SaaS products lately. Some of them are good guides for specific questions. Some are simply misleading or poorly focused. But only a few of us are talking about the two guiding thoughts behind a realistic roadmap that are critical to success:

1. Developing a product that customers want, will pay for and will advocate
2. Finding and scaling an economically viable business model without wasted time or money

These two points form the basis for a slowly building consensus among founders of successful (and some failed) SaaS companies and those of us who have been involved in multiple projects over time. If you haven’t come across them, you will if you need to go for funding of any kind or show a business model these days. These folks are in the business of making money from the SaaS business model and developing companies with a worth that is many times their investment.

People who are unfamiliar with the Lean concept often think that it means developing a product that is at best, minimal and at worst, a product that is too basic and that no one will actually want. We’re used to the idea that it can easily require a two-year development cycle to get a fully-featured product to market. So, when someone says, “We can develop a SaaS product in six months or less!” there is a tendency to dismiss them as novice product managers or marketers.

If this has been your thought, I don’t blame you.  You should question what is behind that type of claim. If it is just the size of the development team that can be brought to bear on the project, I would remind you of the old joke in production engineering:

“While we know that it is true a woman can produce a baby in nine months, this does not mean it is also true nine women can produce a baby in one month.”

For our own part, we’ve developed our concept of lean product development based on careful analysis of what we could provide to our customers to help them be successful. Rather than repeat the entire mantra – let me call out some leading references you should be familiar with for evaluating your roadmap:

• Bessemer Cloud Computing Law #1 – Less is More! Leverage the cloud. Don’t spend money to build features that don’t provide direct value to the end user.  Go into the market and “rent” services. Services allow you to concentrate your resources (time, talent and money) on your core value. They will in fact be richer and more cost effective than anything you can afford to develop.
• Steve Blank – Perfection by Subtraction – Having a clear, tight vision helps to keep development scope down, but it isn’t the key to the “minimum viable product” often mentioned in discussions about product development.  The key is to get a product in front of customers who can understand the vision and who can become evangelists for it because – They have a problem your vision will solve. They understand they have the problem. They have been actively looking for a solution. They have put together some parts of a solution themselves. They have or can get a budget for something that solves the problem.  These customers can validate the vision and will actively pull it into the shape that fits their context. With them behind you – you can develop a beta product that is much closer to what the market needs.  This is also part of Bessemer’s Law #5 – Build Employee Software – which talks about the “consumerization of software” that SaaS has enabled.
• David Skok – Why Startups Fail – The business model is just as important as the feature set in the end. We’ve all heard of great products that never sold enough to return their investment before failing. Learning if you have a market fit, if you can actually scale your operations profitably, if the cost of acquiring a customer (CAC) is less than the average lifetime value (LTV), and if you are going to have enough cash when it comes time to hit the marketing accelerator pedal – these are differences between success and crash and burn. They come down to having a roadmap that gets you into the market early, allows you to test your business model and your product before you have burned all your cash.
• Eric Reis – The Promise of the Lean Startup – Leverage the Agile methodology and philosophy to develop progressively based on customer pull rather than a miracle of market anticipation. We’d all like to be Apple, but we’re not – and getting there is a lot harder and more expensive than we need to expend ourselves on.  The SaaS multi-tenant model allows incremental releases and fixes, usage monitoring, and real feedback-driven products that customers pay for. Eric has a very good presentation with the difference between two companies he was with – that brought him into Lean thinking.
• And finally – Evangelous Simoudis – Criteria for Determining a Company’s SaaSyness – This brings all the previous ideas together with having a successful business model and product BEFORE you go for funding. This puts funding when it will do the most good – when you can use the extra acceleration to get the proven product in the market and when in the classic hockey stick market model, it will be easier to get cash with attractive terms.

But – that means having a roadmap that allows you to make these things happen with a reasonable investment. It means signing up customers and getting cashflow before you reach what you might otherwise think was a full-featured product. It means a company with a product in a licensed model will have to think a little differently than a startup to retain their existing customers, but the larger picture should remain stable.

So, coming back to the premise of this article – a realistic roadmap for SaaS should allow you to -

• Validate your vision with early adopter/evangelist customers as soon as you can show them your the core of your product’s business value.
• Test your marketing, sales and operations during a beta that is still less than a full-market version, but allows you to show your vision to the broader market and get further feedback.
• Leverage services and products that allow you to focus on developing the core value and keep your choices in line with business outcomes – lower initial cost and faster time to market.
• Keep your investment to a reasonable level, particularly in advance of breakeven, and allow high power funding to come when it can do the most good – when you have a proven product and customers.
• Allow early cashflow by having a product driven by paid customer demand.
• Be Agile and flexible in both your product development and your business model.

At Scio – we have used these points to come up with a general roadmap that we customize for each customer’s situation.

Our choice of methodologies, tools and technologies is similarly aligned to ensure we can execute successfully at each stage. Every outsourcing company will decide where they need to focus but for us this means:

• Using the .NET framework as our core techology base. This allows us to apply common skills across a variety of devices and applications and to tap into a much larger commercial resource pool for staffing. It also keeps costs low because we can focus on building best practices and development patterns while leveraging a large pool of libraries that are available for .Net.
• Building on a SaaS application server – SaaSGrid – that lowers the total cost of development and provides the common SaaS monitoring and operational needs. Sticking to one “best of breed” application server that we understand the internals of lowers risk and “discovery” associated with learning new development patterns and allows us to focus on the problem of delivering business value to end users.
• Leveraging Agile and Lean methodologies internally to allow us to deliver useable software early with feedback from customers and operate with high efficiency.
• Use a Nearshore model to put us in closer contact with our customer base and to better enable the promise of collaborative software development embodied in Agile.
• A production model that can apply consistent approaches and learning across engagements rather than approaching each project as a “one-time shot.”
• And finally – a business model that not coincidentally has a lot in parallel with the concepts we expect our customers to embrace.

That is just the choices we’ve made.  Making these choices is a lot like we ask our customers to do when picking a feature set. We purposely left “opportunistic” approaches off the table that would mean we had to spread ourselves a lot thinner to support them at the same level as our core. It also means we can concentrate on improving our core value set without compromising the services we deliver.  We concentrate on our core – developing successful SaaS products repeatably, economically, and quickly – and let our customers do the same for their clients.

So what is your roadmap? Does it align with the ideas we and others have offered in recent articles on developing Internet-based products? It’s all about using the delivery technology that underlies SaaS products to your best advantage in the end.  Whether you develop your product in house or with a product developer like Scio – I strongly suggest you consider your roadmap and the driving vision behind it. It can save you a great deal and lower your risk greatly.  Worth considering…

SaaS is not a “one-size-fits-all” business. There are many options now for platforms and services you can use and the number is increasing every day. A lot of the information available is laden with marketing hype. How do you make the right decisions?

We’ve been helping companies transition to SaaS as startups and from traditional licensed software for several years and we’ve build up a practice we use repeatedly to navigate the choices. We’re bringing our practice to the Dallas SaaS University event as a workshop to help SaaS executives and entrepreneurs make the right choices for their business. We’re passionate about helping companies succeed in SaaS and we’d like to pass some of our knowledge on to you.

You can take this workshop combined with your signup to the University event or separately, but I encourage you to take advantage of the combined pricing that is available. This is not a “technical” workshop – we will be covering how the technical and business decisions SaaS requires impact your business and product strategy. We’ll be using interactive exercises to help you put the concepts into your context and build something you can take back to your team. It is a full day with a catered lunch and will be a limited group so you will have plenty of opportunity to ask questions and be involved.

UpDate! – Use Discount Code: SCIO100

Here’s the outline:

Charting Your Course to SaaS

Making the Right Decisions for Your SaaS Product

Overview – How is a SaaS Product and Business “Different”?

• Leaving 30 years of industry history behind
• Transitioning to a service-led model
• 10 ways to fail

Your Service is Different

• What does making the right choices mean?
• Understanding your market, product strategy, roadmap, supporting technologies, and skills needed.
• Knowing flexibility is key in SaaS

Sell the Right Product

• Map your core product and customer assumptions
• Consider test marketing plans
• Developing a go-to-market feature set

Make Strategic Development Choices

• Selecting services and platforms
• Selecting a technical architecture
• Making development and deployment choices

Operating a SaaS Business

• Understanding service-led business requirements
• Leveraging operational metrics
• Understanding end-user interaction in SaaS and product management

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 “Professors”
Luis Aburto, CEO of Scio Consulting, is a veteran of international technology and engineering consulting for corporate and government clients in the U.S. and Latin America. Mr. Aburto is the founder of Scio Consulting, and in 2006 was responsible for focusing the direction of the company on SaaS enablement services. Luis has worked with a multitude of software companies of all sizes and across many industries, helping them make the transition to SaaS.

Mike Dunham, Principal Consultant of 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.

As I mentioned – there are several ways you can join us in this workshop and I very happy we have the opportunity to bring it to SaaS University. I’m looking forward to meeting many of my friends at SaaS University for the event. If you would like to know more about what we’re going to be doing or some help building the case so you can get company support to go, just let me know. See you there!

It has been a long time coming, but we’ve finally gotten our blog in place. We’ve wanted to have a place to speak to the industry and our customers for quite a while. We hope you find the posts here informative, short and useful.

To beat our own drum – we’ve made a lot of changes recently at Scio. We’ve moved to our new Nearshore Development Lab in Morelia, Michoacan (yes, that is in Mexico). We’ve formalized several of our services to meet the needs we’re finding in the market. And yes, we’ve started this blog.

We’re not going to stop there – so stay tuned. Subscribe to our RSS feed or just bookmark us. Thanks!