How To Say "No"
It’s not uncommon to hear from our clients that they have multiple versions of their application running, many of them dedicated to a single “special customer”. While such implementations destroy the economics of a SaaS company, sometimes we must bend a few rules and accept certain risks early in our company’s lives to stay afloat. A startup that is desperate for cash will do just about anything to attract and retain their bigger customers, especially when this customer interaction is lead by sales staff unfamiliar with the hidden costs of customizations.
As technologist, maintaining multiple versions of our SaaS software makes us cringe. We all know that this is a recipe for a maintenance nightmare. Multiple versions require – bug fixes, patches, and features to be tested and deployed on different versions as well as dedicated hardware or virtual instances to run the different versions. The cost of this can quickly double a technology organization’s budget when additional QA, developers, and operations staff are accounted for as well as the environments. In fact, when running a SaaS platform with dedicated instances (remember the original ASP days?) one can quickly create the worst of both the hosted and packaged software worlds and sink a company. So how do you know when to say “No” and how do you do it?
The way to make decisions, whether build vs buy or feature prioritization or customizations, is to gather the appropriate data to establish a well reasoned argument without exhibiting “analysis paralysis”. For customizations this general includes the upside in terms of future revenue, the downside in terms of development, environment, and maintenance costs, and the risk. No matter what the sales reps are saying there is no guarantee that with the customization you will win the business or without it you won’t. This is the reason for adding a risk variable (beta) that attempts to quantify the likelihood of success or failure.
If the decision is to say yes, then spend some time thinking about what level of customization will occur and how you can possibly reuse the customization. According to authors Pine and Gilmore in “The Experience Economy” there are four types of customizations, transparent, collaborative, adaptive, and cosmetic. Transparent is when the customer isn’t aware that their version is different from others, such as internationalization. Collaborative is when the product or service works with the customer to achieve a custom solution. Adaptive is allowing the customers to change the product or service themselves, such as choosing personal feeds. Cosmetic is re-skinning the product without modifying the functionality.
If you’ve decided to say no to the customer’s request for customization don’t just say “no”. Think about how you can use a carrot and/or stick approach to guide the customer to where you would like them. Sticks are things like additional costs. If a customer wants to stay on a previous version and you’ve decided that’s not acceptable to you consider charging them progressively higher rates until they either leave or make the upgrade. If they are going to leave any way then the temporary additional revenue will help offset the loss. A carrot approach might be refusing to add new features to a custom solution. Eventually the customer, hopefully, will want the newest features and acquiesce on the customization. Instead of just saying “no” emply carrots and sticks in an attempt to move your customer to where you both will be happy.