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

This is the third 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 – Technical Architecture

Excerpt: Reviewing the Roadmap Template for Technical Architecture

In this installment, we going to look briefly at what needs to be in your Technical Architecture plan rather than review a part of the presentation from the workshop.    We provide MS Word templates for each element of the Cloud Product Roadmap, which can be modified and brought together to document your plan.

So just for the sake of understanding the outline – let’s review the major points of a Technical Architecture plan as for SaaS and Cloud products we see it:

• Technical Architecture Design Model
• Technical Architecture Design Process
• Architecture Design Elements
  • High-Level Architecture Requirements
  • Application Architecture Design
  • Tenancy Approach
  • Scalability Approach
  • Metering Approach
  • Security Authorization & Authentication Approach
  • Audits & Compliance Approach
  • Provisioning & Implementation Approach
• Gap Analysis & Third-Party Solutions
• Cost Estimation & Optimization

It is important to note at this point that this is not the complete technical plan. The roadmap also needs to include Development and Maintenance Processes, Operations and the Support Approach. You will also notice something it doesn’t include: Long, detailed descriptions of end-user functionality. This is because we recommend companies with SaaS and Cloud products use Agile development processes. Using an Agile approach means that the application is planned up front at a high-level using “user stories” that describe the main points of functionality needed by users. These descriptions will be broken down in more detail during the development process, but within the context of the evolving application. This allows the product manager to consider what the application needs to do, but spend less time on about how the functionality is implemented. Today developers leverage a wide range of tools and frameworks to deliver rich functionality more quickly and with better quality than in previous years. But each set of tools has its own implementation pattern. A product manager that spends too much time specifying HOW things need to be done, rather than focusing the outcomes, is likely to be wasting time on specifications that don’t leverage the frameworks properly or creating work-arounds with increased risk and development effort.

Another aspect of this plan are the elements included specifically for Cloud and SaaS applications. Tenancy, Scalability, Metering, Provisioning and Implementation are all architectural issues that concern online applications. In our experience, it is common for product management to focus on end-user functionality and leave the specifications for operational purposes until a later time. In many cases, this means the development team either ends up “back-porting” critical functionality into the application or tacking it on the side somehow. This usually means that important opportunities to do it right the first time are lost and in many cases issues like metering never have the flexibility they need. The point of our templates is to help our clients to consider these and other critical elements at the right time in the planning process – before choices are made and effort is expended that is hard to back away from.

The Design Process

If you have an existing product or assets in the form of technical assets (libraries, web services, algorithms, etc.) you can migrate, the first thought is of course leverage them to build the new Cloud or SaaS product. Using them provides a level of comfort and could lower the total cost of development. However, depending on what the assets are and what technologies are involved, they may also become a constraint that will prevent you from optimizing costs, performance, processes and the user interface. ISVs with existing products quite often consider ways to leverage their existing assets – even going so far as to just host instances of their application for clients ASP style to get something in the market quickly. Their basic thought is that the value of SaaS or Cloud all based in the delivery model. Typically startups design their applications from the ground up because they rarely have technical assets to consider.

Existing assets that are not already setup for the Cloud can also suffer from a lack of operational features to automate customer on-boarding and implementation, feature packaging and pricing, and usage metrics. Conversely, building from the ground up doesn’t mean you have to build everything. Using the Cloud model, you can leverage best of breed components to fill the operational gaps and allow you to focus on developing your core value.

You can also leverage specific SaaS and Cloud platforms that provide a many of the operational elements of Cloud products and usually enforce a level of code consistency. These can greatly lower the effort required and can offer capabilities that you can use immediately but would rarely put in your first product version. The build or buy decision in this case is usually a product of business priorities for budget, effort and the time required to bring a product to release.

So, in essence, the design process is a series of choices and compromises that finally arrive at the approach for the final product. The choices can be difficult but are usually made easier by making a series of strategic business and product decisions before you begin to consider the technical architecture. Making decisions on the technical architecture before key business and product decisions are made can lead to wasted development effort and increased risk that the development process will take longer than planned.

Special Attributes of Cloud Products

Current Cloud products, particularly those that take advantage of services like Windows Azure, can scale compute, storage, and delivery in direct response to needs in a specific dimension. That means if the application needs more storage, but doesn’t need more compute power, storage capability can be scaled up (or down) by itself. Conversely, if the application needs to process a great deal of data, it can add compute until it reaches a satisfactory performance for the job at hand. This ability to scale elements of the application separately provides opportunities to approach design problems in new ways. Where before we scaled simply by adding more servers, which included all elements whether we needed them or not, we can now scale just what we need to meet demand. This changes the design process to include considerations for issues like:

• What processes can be handled by a compute role, possibly from a queue, and processed in the background to reduce front end pressure?
• What degree of scalability will be required by each process?
• How will the application scale up and down? What will be monitored and how will it trigger change?
• What types of data will the application use and what resource can be used to store it?
• Are there content distribution needs that could take significant bandwidth?
• Does our scaling model fit within our pricing, packaging and overhead model? Are there better ways to accomplish same end with a lower overhead? What are the trade-offs?

Each cloud platform has its own capabilities and design patterns so there is a learning curve in deciding which applies to a specific product and project. But once basic decision is made for the platform, the next level is to consider how to design the application so that it can scale and leverage the platform transparently and make the best use of its strengths. It is best not to duck the decision and just go for a simple virtual machine approach because, with the exception of a few special cases, most of the value leveraging a cloud platform will be lost in the process.

If working with the interplay of decisions between your product strategy, technical architecture and business model is something you are struggling with – you should consider joining us for our workshop!  It will help you parse your priorities and bring together a roadmap for product development that meets your needs.

<Read the previous article in the series – Next article>

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

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

How many times have you seen software marketing pursuing “feature comparisons” – either as a method to breakdown version options or as a comparison against competitive brands?  Does “thousands” or “millions” of times sound more accurate? Can you navigate feature list comparisons?

If we were really honest. I’d bet most of us would admit when faced with feature lists we simply resort to numbers. Product  A has X number, the alternatives have X minus. But then, who makes up the list? And who says which implementation of a feature is “better” or even real? The marketer making the table is the one making the rules of course. If I make a feature comparison table, you can bet my product or service will have “more” checks in the boxes against the list I make.

So, what really counts?

I was reminded of this discussion (which we at Scio engage in as a matter of course when we start considering development of a new product for a client) by two recent blog posts by SaaS and product marketing gurus, Peter Cohen and George Colony.  Peter’s post, “Too many choices aren’t necessarily a good thing” points out that most customers, when faced with a lot of choices simply freeze and don’t buy. We see this all the time. Entrepreneurs entering the field of SaaS for the first time are often overwhelmed by the number of choices they are faced with. In response, they either drop the idea of developing a product “for now” or simply make a few gut level choices and charge on hoping for the best.  Most put the idea on hold.  Considering the risk, if they can’t parse the choices or get someone to help them, maybe it’s for the best.

George’s short post, “Apple Versus Nokia: The Primacy of Design” contrasts the returns on the Apple approach to product options to Nokia. Nokia has 86 models of cell phones available. Apple has two. Nokia sold 111 million phones in Q2 for a net profit of $286 million (3%). Apple sold 8.75 million cell phones for a net profit of $1.1 billion (21%).  Which business would you rather own? Better yet, which business would you rather run on a daily basis?

Of course, there are many sides to the question of buyer choice. Maybe buyers do want the “cool factor” as some say of Apple products. On the other hand, if Apple had an additional 84 models – would it actually sell more phones at the same margin? The answer is – most likely no. The cost of development and manufacturing alone dictates that in a market with limitations (not everyone wants a phone, needs a new phone or can afford one with service) that significantly more models will inevitably result in a higher margin and lower profit, even on higher sales.

There is also another factor, perhaps more interesting for the SaaS market. To a large extent, Apple is selling to end users. They have only one carrier, AT&T. There are a limited number of calling plans available for the iPhone. Buyers don’t have a lot of choices to make beyond, “Do I want an iPhone?” Nokia, on the other hand, is actually selling to carriers. Carriers differentiate on the combinations of brands, models  and plans they offer. For end users, this makes their choice even more complicated. You want phone X because of features Y and Z? That is only available under plan B with carrier C in your area. In the end, most users end up making the choice simple by asking “how much can I afford and still get decent service?”

Considering this paradigm in the context of a SaaS product – I would point out:

• SaaS is by and large a “business-to-business” (B2B) market where purchase is funded by a business client but endusers ultimately determine value and client retention.
• The more options a pricing plan has the less likely it is the client can make a logical choice for their users. Faced with a wide range of options, most will simply pick the highest or lowest price depending on their immediate budget and perceived value. That choice may or may not work well for their users, which one way or the other will play out in adoption.
• Feature lists do not equate to usage. Experienced SaaS vendors with feature monitoring and metrics can tell which features are in use by which roles, by size of client, by time of the day, month, year and a lot of other factors. Vendors of premise-based, licensed software rarely, or never, have access to that kind of data.

Understanding these key differences in marketing, pricing and determining features for a SaaS product are critical. Starting out, a SaaS product is much better off focusing on a narrow set of features (the 80% of value is driven by 20% of features – the Pareto principal) with customer development leading the way to a product that meets real needs.

The simple facts are:

• Having a strong understanding of the core value your service can deliver to its customer is not the same as knowing what endusers need to utilize it.
• Most often core value is supported by process and decisions within the client operation – incorporating and integrating them in the application is key to retention. If you don’t – eventually client workarounds become solutions or existing solutions become barriers to adoption.
• Monitoring, embedded user feedback and client interaction can (and should) be built into the “application suite” from a user point of view and part of the product management/feature development process pre- and post-release. Progressing from the core product to a form that quickly and continuously delivers value to endusers does not need to be an act of black magic in SaaS.  The tools and methods are available, accepted and expected by users and clients in today’s market.
• Building from the “visionary core value” to delivering a service driven by user and client “pull” puts the vendor in a very unique and competitive position. The client’s perceived value increases beyond cost and if they understand the product development process, becomes a key factor in retention.

But all this brings up one question -

What is “Core Value” for users and clients?

To answer this question, I suggest borrowing from the Theory of Constraints and ask, “What limitations will the service remove for clients or endusers?”

• Will it remove questions caused by the lack of quality data or understanding?
• Will it remove costs that prohibited action?
• Will it remove long processes, strict controls, rules, workarounds, or assumptions that limited users or client capability?
• And finally – What value will removal of the limitation unleash for clients?

Notice that cost and value are not the same. A simple accounting of costs does not account for lost opportunity or gained speed, quality or competitiveness.  It is also important to consider that in many cases, the client cannot see what they are currently doing as a limitation. It is simply what they do to achieve a goal. Gaining adoption requires creating the vision of what would be different in the end while still accomplishing the goal.

Figuring this equation out and developing the vision isn’t light work. But it does put a different light on marketing, the features required and the pricing of the service. It is equally important for new services and existing offerings. It is an on-going activity – it doesn’t end on day one of the new product release or after the latest “version” is in front of users.

So, it might seem that “Keep It Simple, Stupid” (KISS) applies, but in truth, there is nothing stupid about understanding and acting on core value in SaaS. Clearly understanding what a client sees and can realize as value is the key to developing, marketing, pricing, sales, adoption, retention and success in SaaS.

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…

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 debated writing this article.  Do people expect me to write about Project Management? Well… developing software products does mean you need to plan a project. You need to know and control your risks. So – yeah. I guess it does fit.

My thoughts on this subject come from practical experience.  Companies who come to Scio with their projects often come with a multi-megabyte PDF, UML diagrams, and a list of specifications. “Give us a firm, fixed price for getting this project done by June 2nd at 2pm Eastern,” they say.

Their basic idea is:

• Software projects have a unenviable record of finishing over budget and way over the estimated completion date – we’ll set those so they can’t creep.
• Software outsourcing is risky so we’ll limit our risk by agreeing to a cost and timeframe we can live with and possibly tag onto some event.  “Shoot for the June trade show so we have a shiny new product to sell,” Marketing begs.
• We don’t have the resources to do the project in house, but we don’t trust any outsourcing group – so we’ll rope them in with a fixed fee and time and put all the risk on them.
• We know perfectly well what our product needs to be. If we don’t nail this down, we won’t get what we need for the price we can afford.

The result of this thinking generally speaking is:

Flaming Disaster!

Why? Their basic instinct wasn’t wrong. Software projects do fail to meet their targets with astonishing regularity. They were just trying to limit their exposure. What is happening?

There are five intrinsically linked factors in estimating software product development projects:

1. The Total Elapsed Time expected to produce the specified product.
2. The Effort required to produce the product.
3. The Cost the client expects to expend.
4. The Resources required for the project – their skills and availability.
5. The Specifications for the product; the features, functionality and user experience.

In general terms, what clients are trying to do is set a “target.” In project management, the general assumption is you can set any one of the five factors as a target for a project, but when you do, you need to let the other four float to where they need to go to reach the target. So if you set cost, you need to vary time, specifications, effort and/or resources to reach a mix that will achieve the project goals within the target cost.

Instead, clients set two or more factors in an attempt to “hold the line” on all the other factors. They spent a lot of time on those specifications. They need them all!

But in fact, setting more than one factor as fixed creates an almost impossible tension among the remaining factors that almost assures the project will fail to meet its goals. There are no levers left to control the project! It starts out with the best of intentions, but with two or more factors fixed, any change in circumstances during the project creates an imbalance that cannot be corrected with the remaining factors.

Why does this happen?  Stepping away from our example of setting time and cost as the fixed factors – think about each of the factors individually and the impact they have on the project:

Time

The elapsed project time from start to finish is always different than the total effort applied. Time is measured by a calendar start to finish. Conversely, effort is the sum of all the time expended on a project by the assigned resources.  Total time is never equal to the total effort unless only one resource is assigned, full time.

Software development projects rarely finish on time. Unplanned specification changes, unexpected risks, and resource changes always build up over time and eventually result in a project that is both over budget and beyond the allocated time.

Time to completion can only be estimated and controlled well over short periods. As the time period considered in an estimate increases, the accuracy begins to degrade because of variations in expected effort, the depth and complexity of the specifications involved, the skills and availability of the resources required and the limitations an assumed total cost puts on the project.

It should also be understood that time to project completion is rarely scoped as a direct result of the estimating the effort required.  More often, “artificial completion dates” evolve from a point in a product marketing plan, the current product position, and/or customer demands.  When this happens, there is usually some consideration of project scope, but is rarely enough to address the situation that arises from not first doing a straight-forward evaluation of the effort required to complete the specified product.

Effort

The accurate estimation of effort is key to successful software project costing and setting a realistic expected time to completion. In practice however, the amount of effort required to actually produce each bit of application functionality always varies from estimates. The more detailed and contingency bound the estimate becomes, the more likely it is to be wrong. Because of this, past experience and general effort assumptions are used across a project estimation, in the belief that in the final outcome everything will average out. Of course the reverse is also true; averages can never address the all risks in an individual project. So, while averages are a practical approach to project estimation, they cannot yield a project quote that can be fixed to a specific figure without risk.

In this situation, risk buffers for variations in specifications and resources are recommended for effort estimation, especially in Agile development methodologies where development iterations are “timeboxed.”  Timeboxing iterations means variations in effort will generally cause functionality to be pushed ahead to the next iteration and a “snowball effect” can be produced where the amount of effort required for each iteration increases incrementally beyond estimates over time. If buffers were used, more projects would reach their estimates, but in the drive to reach a more competitive price, they are rarely employed when using assumed effort to arrive at fixed cost.  This results in a very narrow margin for error in effort estimation.

In addition, the amount of time required to reach project completion is not directly related to the number of resources available concurrently. Determining effort depends on an experienced assessment of an efficient team size for the project and the methodologies used.  Increasing the number of resources and concurrent tasks beyond a certain point increases coordination and communication overhead exponentially.  Increased team size tends to increase errors, oversight, and testing cycles without a cost effective increase in total output.

Estimates of effort required tend to be assessed from a straightforward analysis of specifications.  During projects, the actual effort required frequently increases beyond estimates because of “fixes” required to bridge the gap between specifications and the product as realized in development.  In addition, the elapsed time required for QA by the client team is often under-estimated and can result in either idling development or moving ahead with incorrect assumptions and subsequent rework.

Cost

Software development projects almost never finish under their expected cost from the point of view of clients. A few finish at the client’s target cost, but generally only at the expense of other project factors. As a result when projects do cost what was originally expected, the product is often a failure from an end-user point of view.

For clients, target project cost is generally a function of:

• Expected product price and the desired return on investment that could be produced by an estimated number of paying customers in a reasonable period of time.  In other words, a string of dependencies that may have little basis in the final analysis.
• Available funds and cash flow limitations.
• Experience with “similar projects” – However, only rarely do estimates based this way actually work out to be similar in the effort required.

Target cost is never or only rarely based on:

• The steps and effort actually required scope and develop a product that is a successful market fit.
• Small, incremental steps that can be estimated with a reasonable chance of success.

Specifications

Specifications are almost always assumed to be a known and set factor in fixed cost projects. They are used as the basis for effort estimation and effort estimation ultimately determines quoted cost. Clients generally have a basic expectation that their specifications do not need to be varied from substantially to produce the desired product at the specified cost.  Clients often expend great amounts of time producing specifications for bid to assure they will be complete and assumed to be fixed. But in fact, not assuming specifications will need to be varied as over the course of a project to meet fixed cost results in a continuous tension between the effort required, the scope remaining and the time remaining on the project clock.

Most fixed cost projects have intentionally limited options to change scope.  Instead, limiting scope change by not providing workable options increases the risk the project will not reach desired goals when actual product is assessed by end-users.

Software development requirements can never be complete enough or communicated well enough to insure understanding and success.  Errors in interpretation, over-broad and over-complex specifications result in many “fixes” that are not related to actual code errors by the development team.  These fixes are actually elaborations or “clarifications” of project specifications, but in most projects they are assumed to be “bug fixes” in the process of development, testing and QA. In practice this means the actual functionality works as specified but the implementation is not as desired by the client. Fixes of this type generally add to effort and resource allocations without the assumption they should impact specifications, time or cost.

Software development project requirements are by their nature improved by discovery on the part of both the development team and the client team during analysis and development.

In the course of normal work, discovery exposes:

• More depth than expected (scope creep).
• Different aims and approaches from client and end-user feedback or unexpected insight from seeing the product as it develops.
• Technical limitations or alternative approaches that change requirements, the effort and time required.

In most software development projects, there are no assumptions or procedures to handle specification discovery and subsequent changes. This results in many variations from project estimates and is a significant factor in project overruns.

Resources

Resource management is a function of having the right skills available when needed for a specific task in a project. With limited resources and funds, this is a difficult task for software development companies.

Both internally and externally, software development companies have an ongoing need to balance new projects against support, maintenance and enhancement of existing applications. Companies need to decide the level of investment they will put into new technology. Using time from existing work to move to new technology skills is a difficult and expensive proposition. Recruiting for internal resources is a long, expensive process that often fails to yield dependable, trained resources in the long run.

These factors are the leading reasons clients consider outsourcing. But they are also a factor in outsourced projects themselves because at some level, the client team becomes involved directly with the outsourced team and the results of team resource management. The management of new software development projects is difficult by itself. Because of the time and risks involved in recruiting resources with appropriate skills and knowledge, client project/product managers often don’t have a good understanding of the technology and limitations in the project they are managing.

In this situation, outsourcing software development often leads to a confrontational relationship where the client team feels they have lost control and don’t understand the choices the outsourced development team has made or what effort is being applied to produce deliverables.  They don’t understand that the estimation for time to completion was figured against assumed effort but the accuracy of that assumption varies according to specification clarity, resource skills and availability.

In Summary

Variations in the five factors during a software development project leads to:

• Defensive reactions to clarifications and changes between the client and development team.
• Situations where the actual effort in the given time varied depending on specification accuracy and resource skills and availability leads to confrontations.  When time to completion is figured for fixed cost, it is generally figured against assumed effort. Without assumptions for what controls are available to deal with variation, the confrontation continues to simmer throughout the life of the project.
• Lost opportunities for a partnership-like relationship of shared risk and reward.

The solution could be as simple as not setting more than one factor as fixed, but in practice that is hard to do for many projects. What is really needed is a consultive framework for communication and decision making that is informed by real time reporting during the project and collaborative resolution of issues to reach the client’s goals. It’s easy to say, but it takes understanding, planning and agreement to accomplish.

We’re constantly working on this paradigm everyday – it’s challenging and rewarding. What’s your experience? How do you hold the line? What controls do you have realistically? Have you recognized the five factors in your project estimation process formally? I’d love to hear your thoughts…

]]> http://blog.sciodev.com/2010/04/06/the-5-variables-of-project-estimation/feed/ 5