As I wrote in some of my earlier postings, the SaaS world differs greatly from the standard packaged and installed software.  The basic ideas are the same, but there are many organization, technology and budget differences that can trip up any product manager.  Let’s take a look at this scenario…

You sold your management on offering a SaaS product in part because of the ability to deploy new features and bug fixes quickly – there is no waiting for the next build to be sent out to customers and no waiting for them to deploy it.  As soon as it’s tested, it can be dropped into production and it’s live.

However, now you are finding that it takes your enhancements and bug fixes a long time to get implemented.  Why is there such a large gap between code complete and deployment into production? This was not supposed to happen.

Before the executives grill you on why this is happening, you may want to sit down with your IT department and have a conversation about incentives – Could it be that you, the product manager, are placing your IT organization in an untenable situation?

Astute product managers know that when the organization fails to deliver, it has in many instances a lot to do with misaligned incentives. This is very much the case between IT and Product Management in a SaaS implementation.

You see, IT wants stability (although they never get it) because they are incentivized to minimize service interruption and system slowdowns.  They are the ones everyone comes after if there is a system failure and customers experience an outage.

Product Managers on the other hand are motivated to get the latest market demands built into their software.  Since market demands change quickly and regularly, they are indirectly incentivized to push change into their products and even with the best change management, the more change you have the more instability you have.

IT wants to control change while Product Management drives more change.  Looking at it this way, it is rather obvious where the problem exists, but how do we fix it?  Incentive Alignment – that’s how!

Now, you cannot provide complete alignment. It’s IT’s job to maximize stability and performance and it is Product Management’s job to maximize product enhancement.  They both serve to keep each other in check and that is not a bad thing overall.  However, you can petition executive management to modify their incentives to achieve a level of alignment.

When the objectives for IT are set, management must ensure that IT embraces change. A goal could be to reduce the turnaround on new features.  For example, any new feature that leaves QA needs to be part of a release in X days on average – basically an SLA on product feature release.  This may cause IT to start scheduling more frequent releases or work together with other teams to more closely align releases to completion of product testing.  This may also cause them to re-evaluate their release process to see if there is a way that they can safely shrink the release cycle. Finally they may generate a business case to increase their budget and get the headcount and infrastructure in place to maintain stability while supporting faster releases.  Once the incentive is there, the wheels will start turning to solve the problem.

The product manager’s objectives must also be modified to ensure that incentives exist to help the IT group maintain stability in their world.  This can be achieved by a basic objective stating that all features developed must also include the ability to support that feature and the ability to track its performance.   This is going to do two things – it is going to reduce IT’s fear of new features because they feel that they have the tools to support them and it will also ensure that Product Management builds features that are not too complex to support because they have to provide the means to support them.

These are just examples – each situation is different and may require different incentive alignments.  As you are the CEO of your product line, you have to decide what you need.  An open discussion with your IT department, your executive management and HR will give you an understanding of exactly where your objectives are misaligned and you can work from there.

A word of caution though – your executive management must be behind you to ensure that this endeavor is successful.  Without their backing, the incentives have no teeth and therefore will produce no changes.

Once you have an idea of the services that will probably require an SLA and the levels that should be expected, you can work with your Product Development and Information Technology departments to determine how much these SLA’s will cost to support.  Using these costs, you can design a multi-tiered pricing package for the SLA’s based on each customer response time and availability’s needs.

For example, every transaction may cost $8 if you take the basic SLA package, which is 95% uptime and a 20 second response time, or it can cost $10 if you want the premium SLA package, which is comprised of 98% uptime and 10 second response time. Some users need 24/7 availability, while others are good with 22/6.

You can design your software to put high SLA customers into faster moving queues and process them on more powerful machines and many companies do.  However, that is not the true point of the exercise.  The exercise has both planning and negotiation benefits.

First, by planning and understanding the SLA requirements, you can ensure that the hardware and infrastructure will be hearty enough to support the application without worrying about hidden costs popping up for unexpected support requirements.  Second, the sales people will not be as tempted to throw in the SLA for free to get a customer to sign a deal.  They will have a framework of “gives and gets” that they can use to quantify the customers desired level of service.  If the customer has to pay more for a higher level of service, they are going to think twice about buying it. (Note:  In order to get the sales team to use the tiered SLA system, their incentives must align with it properly.)

Further, even if you don’t design your software to manage different service levels – which means you really design it at the highest expected level of service – this tiered approach gives you a quality of price discrimination.  You can charge customers that place a higher value on service a higher price than those that do not highly value it.

However, there are some pitfalls with the SLA process, even if you have designed everything properly.  A problem that I have seen is that the fees incurred when the SLA is not met can be assumed to be the total value of the lack of service to the client, which is not necessarily the case.  In the SLA, customers don’t usually ask to be reimbursed for their total lack of productivity while the system was down, they just ask for a penalty amount for the downtime.  The downtime causes more damage to brand, product perception and customer satisfaction and that is not covered by the penalties specified in the SLA.

In 1998, Uri Gneezy and Aldo Rustichini conducted an interesting study at several daycares in Israel*.  They noticed that parents were coming late to pick up their children from the daycare, so they decided to institute a monetary fine for those parents who showed up late.  While they expected to see a downturn in the amount of late parents, they actually saw a dramatic increase in the experimental group.  The fine became the “price” of the being late and it was an amount that parents were more than willing to pay.

The same thing can happen with your IT Management.  They can decide that the SLA’s penalties are the actual value of the SLA breach, when that is only a fraction of the true cost to the company.  For example, if the penalties imposed by the SLA total $5000 per month then that amount will be used to make decisions.  If the cost of the hardware required to beef up the infrastructure exceeds $5000 a month, your requests for upgrade will be denied.

In this case, the soft cost of dissatisfied customers and brand damage will be ignored in favor of the hard cost of the SLA.   While I don’t advocate the hiding of information from your IT department, I would recommend never publishing an SLA penalty without including a number (even if it is debatable) that represents the damage to brand and customer satisfaction.

* Gneezy and Rustichini, “A Fine is a Price”, http://rady.ucsd.edu/faculty/directory/gneezy/docs/fine.pdf, 2000

In my last posting, I mentioned that I would elaborate on Service Level Agreements and how they affect the Product Manager.  Product Managers have to be proactively engaged in the definition of the SLAs.  If the SLA is not managed properly, you may put your own company at risk. We have been at a customer site during a product outage – watching hundreds of your customer’s employees suddenly standing up in their cubicle and stretching because your product becomes unavailable is not a pretty sight

Let’s start out with a definition of the term, although it is basically what it sounds like it is.  A Service Level Agreement, or SLA, is a formal rider to a contract that details the performance and availability that the customer expects from the service provider, along with the fees and penalties that will be assessed if these expectations are not met.  The SLA will also usually specify the hours of operation when these service requirements will be in place.

Service Level Agreements can be set up to guarantee any level of service for any portion of a service that your company provides to the customer.  Some typical SLA’s include:

• Response Time – A limit to the amount of time on average that it takes for a website or program to respond after a user has submitted a request.

• Transaction Processing Time – The maximum allowable time for a vendor’s system to process a file or set of files containing customer transactions.  This usually comes into place with Electronic Data Interchange (EDI) and batch based systems.
• Uptime Requirements – The percentage of allowable unplanned downtime that the vendor is allowed to have during the hours of operation.  This is usually in the range of 97.5% – 99.999% of the time although there are no hard and fast rules.
• Outage Notification – A maximum amount of time from when an outage has been discovered on a vendor’s system until a vendor notifies the client, along with an escalation contact list, to ensure management on each side is notified of an outage appropriately at the right level.

In my experience, Service Level Agreements are usually first discussed during contract negotiations.  The customer asks the sales rep for an SLA, the sales rep goes to the product manager (if we’re lucky) and the product manager works with IT to determine if he can support the SLA.  This is the exact wrong way to go about the SLA process.  The product manager should write the non-functional requirements with the SLA possibilities in mind and understand the relationships between the SLA and the costs to run the system.

As we all know, nothing is free.  If the IT department has to provide more horsepower to an application, there is a cost to it.  You, as the product manager, must understand those costs and plan for them ahead of time, as you would for any product feature.  If these costs appear to be out of control compared with your business case or MRD, your new product’s existence may be in jeopardy, which is why you need to be specific about the market needs upfront.

Start by meeting with the customer and internal sales staff so that you can understand their business well enough to know how to write your SLA requirements. You may also try to estimate the cost of an outage for your customer so you can ask for realistic penalties. Your customer may not immediately react to an unplanned outage, but you can be sure that they will use that outage to either dispute the next bill and/or ask for a discount during contract renegotiations.

That is not to say that you are going to be able to predict the exact response time that all of your customers are going to need, but you should have an approximate idea of what services they value, how much they value them and how fast they expect the services to work.

When it comes to SaaS, manage your SLA before it manages you.

As I wrote in my earlier posting, implementing a SaaS delivery model for your software product is more than just hosting servers and storing data.  In order to make SaaS happen at your organization, you first need to adjust your perspective, since this new model is all about renting as opposed to selling.  Your customers are now tenants rather than owners.  Think of how different your expectations are when you are a renter vs. an owner.

If you’re an owner and your furnace needs to be replaced, you call the furnace company who tells you to call the electrician to do some new wiring and then the plumber to run some new gas lines and then tells you that the new furnace is backordered.  If you’re a renter, you call the landlord and say, “Fix the furnace!” and you are done.  The furnace company, the electrician, the plumber and the coordination are all handled by the landlord.

As a Product Manager, you are not going to be the one running around and getting the servers, storage, routers and hubs to run your software, but you ARE going to be the one budgeting for all of it.  Budgeting incorrectly for a SaaS migration can cause you major headaches, so you have to understand what you’re doing.  If you set the budget too low, the product doesn’t perform and you lose customers and reputation.  If you set the budget too high, you sit around with wasted capacity and have to explain your excessive purchases to some very angry executives.

That said, the impact of moving to SaaS is in no way limited to sizing the technical infrastructure. You are turning your revenue model from a one time payment (license plus implementation services) along with yearly maintenance to a multi-year subscription agreement with a revenue stream that is inherently more predictable. This will have a huge impact on almost every part of your company including sales, finance, R&D, support and services.

• The customer’s expectations have changed, so policies, procedures and people must be put in place to manage those expectations differently.  Customers are increasingly asking to have their service expectations quantified with a Service Level Agreement with penalties for poor service.
• The model for the sales team is going to change dramatically also – they won’t necessarily know how to sell services– and it is your job to ensure that they are armed with the right knowledge and sales collateral.
• Your customer delivery has to change.  Just as you wouldn’t invest significant money customizing a rental apartment for your use, companies don’t want to have to invest large amounts of money and resources in setting up and customizing your product for their use.
• The finance organization must come up with an accurate cost accounting and billing system to ensure that revenues are properly captured and the SaaS operation remains profitable
• The IT department is used to supporting they internal infrastructure, but now they will be responsible for managing the client facing infrastructure which leaves significantly less room for problems.

If you’re starting to wonder why anyone would migrate their products to SaaS, there are significant benefits.

• You are in control of the whole system.  You don’t have to worry about product failures due to installation issues, problematic customer infrastructures or any other hardware setup issue.  It’s your software running on your hardware.
• If you set it up properly from the beginning, you can have perfect data on customer usage of your product.  You can see how individual customers are using the system on a transaction by transaction basis and you can create trend analyses based on all of the usage patterns of all of your users.  Even better, you can use a customer’s data to locate inefficiencies in their workflow and create new products to address the need.
• You decide when your customers upgrade – they will always be on the version that you want them to be because you own the system.  You will never have to wait to roll out a new billable feature because your customer’s IT department is too slow and you will never be forced to spread your support staff over multiple product versions.
• You can add an element of stability to the company revenue stream.  The subscription based model can be very attractive to your company’s investors because it is now a more predictable revenue stream.

Do the benefits outweigh the costs?  We’ll figure that out as we explore managing the changes and maximizing the benefits of your SaaS implementation.

As Software as a Service becomes more and more popular, many Product Managers find themselves faced with this inevitable roadmap question – Should I offer a SaaS version of my product? If I do not, am I inviting my competitors to own the space? If I do, how do I offer my traditional licensed and installed software product as a service?

I am going to take several postings to describe what you need to know to answer the who, what, where, how and why of a SaaS migration.

Before we get started, let’s set a baseline for discussion – Software as a Service, or SaaS, is exactly what it sounds like it is. You provide all of the hosting, security, storage and bandwidth necessary to run your application for your users and they simply log in and get to work. Overall, it’s an excellent deal for the customer – they can reduce their IT budget and increase their expectations! (Note: Just because it’s an excellent deal, doesn’t mean that it will be an easy sell – big companies are wary of letting their data live outside their walls.)

At first glance, this doesn’t seem all that daunting. After all, many traditional, customer installed products offer a web interface. You may be tempted to think that you just need to host the servers at a data center instead of at the customer site, open some firewall holes and you’re good to go. If that is your perspective, then this series of postings are going to be a very enlightening journey.