Category Archives: Maintenance and Revenue

Can Your Product Make Espresso?

young girl standing and juggling with red balls

Wish lists and their management are a frequent point of discussion in the customer support and success world. A wish, or enhancement request, is created when a customer would like the product to act differently than it currently does. Enhancement requests are added to the product team’s backlog, together with requirements from marketing, bug fixes and other development items, such as platform and technology upgrades. All items in the backlog are usually prioritized by product management, some will eventually be developed while others won’t

Customer Success and Support teams, focusing on single customers or transactions, are usually concerned with enhancement requests that represent the needs of individual customers. Conversely, Product Management and Engineering will focus on the needs of broader segments of the customer base as well as the overall needs of the market. Consequently, discussions with product management or engineering tend to break down and leave everybody frustrated. The question is therefore, how can Customer Support and Success teams succeed in making the case to Product Management for product enhancement?

From my own experience, there are several key actions to take:

  • Screen – Ensure that any enhancement requests you promote are in line with the product’s strategic direction. If they are not, then you’ll be misleading customers and losing credibility both externally and internally
  • Quantify – the number of customers that need, or are expected to need, this enhancement. [How do you know how many will need it? Sometimes it is obvious, for example, customers using a certain application or technology platform, customers subject to certain regulations]
  • Assign value – Estimate the risk the company is facing as a result of not implementing this enhancement. Consider what the company will lose due to not implementing this enhancement, this can range from having a single disappointed system administrator to losing revenues from multiple large customers for several products
  • Bundle – Are there several enhancement requests that are similar enough to be combined, or close enough to be developed jointly?
  • Recruit Customers – create a forum for customers to help refine the definition of the enhancement requests and solicit votes and comments. Doing so will help you in assigning value to the each enhancement. Françoise Tourniaire has an excellent blog post on managing wish lists in your customer forums

Following these steps will help you come to the product planning discussion equipped with high quality information and better, more strategic arguments than the fairly common “VIP Customer x wants the product to make espresso” argument, and hopefully you’ll have better results to show for it.

Are Your Technology and Policy Aligned?

time to upgrade

An interesting discussion on the ASP Group on Linkedin asked for ways to address customers who won’t upgrade their systems and keep requesting support. There are several valuable suggestions in that discussion, but I’d like to use this opportunity to address the how vendor choices impact customers upgrade decisions.

There are two main choices vendors can make that impact customers’ decision. First are policy choices: for example, the number of supported release and the options available to a customer on a non-supported release when encountering a problem. Second are engineering choices: complexity of the upgrade process, the amount of work the customer need to invest in the upgrade and whether any equipment needs to be acquired. These decisions influence customers and their ability, and desire, to upgrade. The interaction between policies and and technology choices will tend to drive customer choices and the resulting actions vendors can take.

The following matrix offers a quick visualization of the choices and their impact.

matrix

If we think about these four options, we can identify some familiar categories and use cases:

  • Quadrant I is empty due to the fact that simple or automated upgrades make it easy for customers to upgrade vendors can get away with strict policies, sunsetting releases rapidly, reducing support levels for backward releases and sometimes charging high maintenance fees.
  • Quadrant II Is for situations where upgrades involve high expense and risk, and the vendors are willing to continue supporting these releases either for customer retention of for the increased maintenance fees. The most famous example is Microsoft’s extended support for Windows XP.
  • Quadrant III Represents cases where software upgrade is simple and in many cases automated. A typical use case would be Anti-Virus software with auto-update capabilities and little effort investment on the customers’ side.
  • Quadrant IV Here we find extremely complex technology deployments (think large scale ERP systems), requiring extensive customization, and subsequent testing and adaptation when upgrading. These are extremely expensive, time consuming and very risk prone. Frequently customers would rather stay on their original release and avoid upgrading Vendors who refuse to support their older releases or who impose high costs for doing that may find their customers defecting to third party maintenance providers.

Understanding these categories and the choices you make will help you understand how your company’s policy and technology choices impact customers’ upgrade decision and your maintenance business.