Is Your Software Protection Meeting Your Monetization Needs?
March 06, 2014
By Peter Bernstein, Senior Editor
As independent software vendors (ISVs) struggle with all of the changes that are rapidly altering almost every aspect of the way in which they do business, of top concern is whether the protection of their intellectual property (IP) is optimized for the realities monetizing their efforts. SafeNet’s (News - Alert) Rana Gupta recently wrote an insightful blog post on this subject, and TMCnet asked him to do a deeper dive given the criticality of the insights he provided for ISVs as they meet the challenges of what is turning into a true brave new world—where asking the right questions and adopting best practices hold the keys to future success.
In response to the question asked in the headline, Gupta highlighted three key areas of focus for enabling ISVs to ask the right questions and some recommendations you need to consider as you evaluate the many choices for the path ahead.
Maintenance
The first area involves annual maintenance. As Gupta explained in the blog, at the bare minimum, ISVs are selling annual maintenance to existing customers and need to allow customers to have access to product support in the wake of any issue faced in the current version, which leads to a series of questions:
- How do you manage whether a particular customer asking for support is entitled for it or not? Consider whether this requires your team to manually search for various records before their support entitlement can be established.
- Will having a self-service portal that allows the customer to access the latest updates cut down your support costs?
- Do you have an easy way to get a list of customers who haven’t renewed their maintenance plan? Having a list of such customers or those with expiring contracts could be highly valuable for your sales team.
Gupta told TMCnet, “Using a license string that corresponds to maintenance/support will be helpful to keep track of the customer’s entitlement to support. This license string will be: installed on the customer side and hence the customer will be able to see the validity of its support in the application itself; and stored in the Entitlement Management System (EMS) on the ISV side. Hence, the ISV and customer can see the support validity period by going to their respective portal views on the Entitlement Management System.”
He added that another benefit to ISVs is the ability to run reports from the EMS to build the list of customers whose support plans are expiring in the coming period and then have its sales team reach out to those customers for the timely renewals. In addition, ISVs can link the support portal to the EMS, providing a valid support plan that gives the access through the customer support portal.
New software releases
The second area dealt with the challenges surrounding new software releases. Gupta noted that ISVs need to be asking themselves:
- What is your software pricing strategy for new versions of your products – do you give those to your existing customers free of cost? Defining your software pricing strategy for both new and existing customers is important to your bottom line as well as your customer retention strategy.
- Do you have an easy way to get a list of customers who haven’t upgraded to the new version of your software?
The example Gupta provided TMCnet on this subject is definitely food for thought. “Usually a new version (say, version two) will be launched at a higher price (say, x number of dollars) to enable the sales team to ask for higher value for the new features in the release. As version two is released, ISVs need to make sure that anyone who has a legal or valid license for version one is not able to run the new version two. This brings up the delicate issue of how does the ISV enforce this? This enforcement can be facilitated only if the licenses for the two versions of the software are different in some way so that the version two doesn’t recognize the license of the version one software.”
He added that this is critical, not just from a straight monetization perspective to maximize sales of the new software, but is also important when ISVs are selling through a channel. The reason is that the ISV in this instance doesn’t have direct control over the number of copies sold or to whom.
Furthermore, the ISV may want to roll out an incentive plan for existing customers in order to encourage them to move to version two. For example, “existing users of version one are offered a discount of 20 percent on version two if they upgrade by a specific date,” Gupta explained. Again the question arises as to how this can be enforced. Gupta points out that issuing a license string for version two is not sufficient. It requires a special “upgrade” license string that checks for the presence of an existing license for version one before upgrading it to version two. In short, protections are needed to assure version two gets maximum exposure in the market, and that all license instances can be accounted for and tracked not just for monetization reasons, but also compliance.
Entering new markets with customized versions of software
Finally, in the blog Gupta posed questions about market expansion and differentiated pricing and new pricing strategies to address emerging opportunities.
He explained that, “Here, I was thinking of a scenario where an ISV starts selling a full-featured product that enterprise customers are ready to pay the full price for. Let us say the price for the enterprise market is X number of dollars. The company has a great success in building its position in the enterprise market space, but by the end of third year, they start struggling to keep their revenue growth as a company since the enterprise market is already penetrated. The company has to go to the SMB or SOHO market space which is unlikely to pay the same price as paid by the enterprise customers. So, the company decides to launch an SMB/SOHO version of its product that is a subset of its enterprise version and is limited by features or by performance or by number of users or a combination of these.”
This means a different and lower price point. The challenge for the ISV is that it would be sub-optimal and costly to expend money on developing two different products. It has to be one single code base where features and functions for various versions can be easily enabled and disabled depending on the market being targeted and the licensing options need to be flexible in adapting to these types of differentiated offers.
Gupta said the benefits here are that, not only is the ISV able to save its R&D resources by continuing to develop on one unified code base, but is will have the flexibility in its pricing without cannibalizing its revenue. He concluded by saying, “To be clear, the value differentiation is an important part of a product manager’s (PM’s) role. However, once the PM has decided on what features/performance to be offered in a differentiated version then licensing can then enforce the changes to avoid confusion and possible compliance and monetization issues.”
The above illustrates just how complicated properly protecting IP from a monetization perspective has become for ISVs. The good news is that SafeNet has not just answers to the questions, but solutions that enable ISVs to protect their IP and optimize monetization through the entire product lifecycle.
Edited by Stefania Viscusi
[ Back to Software Monetization Featured Articles ]