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.

There are many reasons that as a product manager you interact with the legal department:

• When introducing a new product or package, you need the customer facing contract to reflect and enforce your service level agreement, warranty, pricing and discount decisions
• When working with your business development group to negotiate a new technical or strategic partnership to complement your product, you need help from legal to formalize the terms of the relationship
• If your organization requires it, when all your collateral must be approved by your legal department
• When you want to protect your company’s Intellectual Property (more on this later…)

Most legal departments are pro-business and willing to go the extra mile to accommodate Sales, Marketing and Product Management. However Product Management and Legal can be at cross-purposes if you do not handle the situation properly.

The essential reason why a legal department may create difficulties at the worst possible moment (launch time) is that legal exists mainly to minimize the organization’s risk (although they like the word “mitigate” better). As you introduce new features, deploy new products, or want to expand your reach to new audiences, you are inherently creating potential risk. Making specific product claims, bringing an unknown party to the table, or targeting a new audience is enough to give corporate attorneys nightmares! The greater the perceived risk, the more time and energy must be spent – usually late in the launch cycle with the potential to erode your time-to-market advantage.

Hence the potential friction – or didn’t you want that launch bonus?

Maintaining a poor working relationship with your legal department could undermine your product initiatives in a number of different ways:

• Delay your product/partnership to explore legal ramifications: How is our Intellectual Property protected?
• Prevent you from creating impactful customer collateral by editing your material in a way that makes it removes its teeth: How can you back up your 20% ROI improvement claim when you have not implemented this product yet? Have you conducted a study to substantiate the claim?
• Prevent you from packaging your product the way you want to by disputing the language in customer facing contracts: We never had these clauses before. How can we enforce this packaging?

The points Legal brings up are usually valid and must be addressed.

How do you prevent a breakdown from happening? By being proactive!!

Here are 3 practical steps you can take early on in the process or at any time during your launch process to avoid the situation:

1. If you have put together a business case, in my book the most important section is the “business assumptions” section, where you lay out the conditions under which the business case is valid. Usually, there is also a section called “business risk” which lists all the bad things that could go wrong. No matter where you are in the launch process, you need to review those two sections periodically with Legal. If they don’t have time to listen to you, at least make sure they know you’ve made an effort to talk with them.
2. Each time you make a claim in a piece of collateral (productivity increased by 20%, ROI by 30%) make sure you have the proper supporting data to back it up. Those that are really on-the-ball might incorporate productivity and ROI studies into the beta test plan. However, if you’re in the unfortunate position of not having solid supporting evidence, (your claims are the result of a theoretical calculation), then you need to negotiate language with Legal that communicates the same intention but does not expose the company. The point here is not to have the argument when the collateral is under review, but to have the discussion with Legal leveling advance for each claim you want to make to justify the benefits of you product. Once an agreement is reached, you can get to your brochures, white papers or eBooks. It is far better to hit a wall early on than when the collateral is written, illustrated and laid-out.
3. If your pricing and packaging is different or appears exotic to the legal team–because you are targeting a new market, using a different channel or a new technology–you must be able to easily explain it to Legal, because if they don’t “get it”, chances are your sales force won’t either. Before you knock at their door, prepare in advance by asking yourself the following: Can you bill for it? Can you enforce the pricing with the customer? What are your proof points? Can you audit the customer to ensure they are paying the right amount? How does the competition package their offering?

Last of all, the legal department is a great resource whose input will make your product stronger. Just remember that they don’t like surprises. You need to be bold to survive, but you also need to ensure that the team that supports you is apprised of your thinking.