GDS International - Next - Generation - Telecommunications - Summit - Europe - 2

V1.0 28th Feb 2012 Copyright 2012 Alclarus Limited 1

Product Rationalisation

1.1 Introduction

Product rationalisation is an essential element of the product lifecycle. It is well-established in industries such as the automotive and pharmaceutical sectors that execute product rationalisation with the vigour they apply to product development. However, in the telecoms sector it tends to be overlooked because of the drive to launch new products and the assumption that once a product has been launched it can be left to generate revenue for relatively little cost. But a continued refusal to trim a growing catalogue of legacy products can lead to serious difficulties. Take a moment to reflect on how many new products your organisation has launched recently and contrast it with the number that have been retired over that period. In the telecoms sector launches will almost always outnumber retirements. You may feel this isn’t a problem and that your organisation has the expertise, systems and resources to manage an ever-increasing product portfolio. If you believe this you’re either very good or deluded. I believe this problem is going to grow as operators face demands to launch more and more products and to increase their focus on business to business products.

I’ll examine the problems that arise when product volumes grow unchecked and approaches you can adopt when deciding how and when to rationalise your product portfolio.

1.2 Why should you rationalise your product line?

You have a product that’s been delivering revenue for a few years. Why should you think about killing it off? There are a number of below the line costs incurred by every product – although they are not immediately apparent they are real and can hobble your ability to respond to market pressure.

Product Rationalisation Drivers


Management Time

A large number of products can be difficult to manage. A product manager’s ability to administer her portfolio will be defined by the management information she has and the ease with which she can make changes to products. Management information needs to be accurate and timely. There is often a delay of days between a customer using a service and that information appearing on management reports. Many telecoms business and operational support systems were designed to cater for a world of monthly contracts and don’t offer the flexibility to easily adjust products and prices. Valuable product management time can be absorbed in collecting management information and then shepherding changes through out-dated systems.

Revenue

If you analyse your products and the revenue generated it’s very likely that 80% of revenue is generated by only 20% of products. If this is true for your portfolio you have an opportunity to focus on the “good” 20% of products and to reduce some of the 80% that are less viable. Undertaking a product clean up will free your product managers to spend more time understanding what your customers want and to improve the most viable products in your portfolio.

Legislative And Regulatory Changes

These are changes that are required by law and thus cannot be avoided. Examples are changes to tax rates or competition commission rulings. The change may impact some or all of your products and the way in which you implement them will be governed by your product architecture. If you’re lucky you’ll have a consolidated product catalogue that enables changes to be made once and applied across your product range. However, if your products are based on older and more diverse technologies you will have to make changes on a case by case basis increasing both time spent and the likelihood of making mistakes.

Obsolete Platform Maintenance

As products age the platforms on which they sit are likely to be retired by suppliers. Keeping alive a product that is sitting on an obsolete platform can be expensive as vendors incentivise their customers to move away from ageing platforms with costlier end-of-life plans. You may also find you need to hire expensive subject matter experts to keep the platform functioning.

Sales Focus:

Your sales team may be happy selling products they know well but this familiarity may be a barrier to selling newer, more efficient products. Taking the easy option of a familiar sell may impede take up of new products – removing the obsolete product from your portfolio will drive sales staff towards selling the new product.

Another tool for ensuring your sales teams have the right focus is their incentives package. What products are they being incentivised to sell and what measures are being used to drive them? Do you want to reward your sales teams on the number of sales, the revenues achieved or the profitability of those sales? Lack of alignment between products, incentives and the strategic key performance indicators of the business can be another reason for retiring products that don’t fit with your strategy.


Technical Efficiencies

When a company upgrades or replaces the systems (such as billing and ordering) it uses to support existing products, migrating those products to the new system is expensive and time-consuming as older products are often built as customised solutions that do not easily move to a more standardised system. The product may not be fully documented and the people who built it may have moved on. You may find yourself having to choose between supporting a legacy product with a mixture of out-dated hardware and unsupported software or retiring that product from the market.

Customer Satisfaction

As the market evolves it becomes harder to keep older products in step with customer demands for more responsive and cheaper services. Older products may not perform as well as newer ones, they might be inconsistently priced or not available as quickly. Customers will notice these inconsistencies which will undermine their trust in the operator’s ability to deliver their promises – all of which contribute to brand damage.

The Future

Think about the rate of innovation within your organisation; how many products have been launched in the last 2 years and how many have been withdrawn? If these levels continue how many products will need to be managed and how complicated will it be to manage them? Do you have the systems and processes capable of managing these volumes? The number and variety of service providers is increasing rapidly. Many of them are free from the standards-based approach to development adopted by telecom providers and so can create and adapt products very rapidly. The service landscape can change significantly in a few months and the typical 9 to 12 month product development process adopted by telecom providers means a product can be out of date before it hits the market. Users move freely between services, dropping those that are out of favour. The rate of innovation will increase and telco service providers will need a product retirement policy that matches your strategic objectives.

1.3 Approach

First, assess the desire in your organisation to undertake product rationalisation. It requires commitment from across the business, particularly in the marketing, product development, finance, operational and technical domains. Is this a one-off activity or will it be applied continuously and so need integrating with existing working practices?

Identify your stakeholders and tell them what you’re doing so you know who needs to be persuaded of the benefits and who will promote them. Key stakeholders are the people within your company who own the revenue and costs of products. Be honest and open with them about the true cost of implementing rationalisation, win their support and ensure you keep them informed of progress and obstacles.

Leadership

Product rationalisation is a complex task because it affects so many parts of your business. To be successful it’s essential to have an owner for the process who will manage the activity from end to end and be accountable for delivering the benefits of rationalisation.


Scoping

Decide whether you’re going to assess all the products in your company portfolio or a limited selection. Try and answer some basic questions about your chosen products – how many products are in your company portfolio, how many have been introduced and retired recently, what revenue does each product generate, how old are your products? The answers to these questions will help you scope the size of the challenge.

Commercial Context

Start by assessing the current and potential commercial performance of the products. Your strategy or marketing team may already be doing this but this sort of information often doesn’t cross departmental boundaries. If they’re not doing it you can use tools such as the Boston Matrix to objectively analyse your products market share and potential for market growth and categorise them as Stars (high growth, high investment), Cash Cows (high market share, low growth), Question Marks (low market share but high growth potential) and Dogs (a low share in a low growth market). The Dogs are the most likely candidates for retirement. It may not be possible to retire all Dogs – there may be regulatory requirements that prevent you from retiring these or they serve a particularly important customer.

It is important that you apply the criteria as objectively as possible. You should have information about the performance of your own products. Market data is widely available – if you can’t find what you need work with your team to agree a set of market information that you can use to assess the growth potential of all your products.

BCG Matrix for Assessing Product Commercial Value


You should also assess which customers are using which types of products. A product may initially appear to be low value but mapping the value of customers to the products they buy from you can also provide valuable insight. A customer may be using a low value product alongside higher value ones, so you’ll need to communicate your plans to retire the product very clearly and provide the customer with alternatives or incentives.

When you have a commercial view you can move to the next stage which is to understand the costs involved in supporting these lower value products. The level of detail to which you analyse these costs will depend on your organisational culture. Some businesses will require a full breakdown of estimated savings before embarking on a rationalisation project; others will be want to push ahead on the basis of growth and revenue analysis.

Analysing Costs of Supporting Products

The actual costs entailed in supporting a product will differ by sector and company. However, from an IT/Telecoms perspective these are the headline cost areas you should assess:

Operational

Customer support – what volume of support requests are being generated by the product? How much does it cost to handle each call and how much employee time is taken on issue resolution? Are there any dedicated support systems required for this product? Can the product be supported using standard business processes?

Hardware

What hardware is this product running on? Is the hardware dedicated to one product – if so what are the associated power and cooling costs? What hardware licence fees are you paying?

Software

Does the product depend on customised software? Does the software integrate with your other systems? Does it require specialist knowledge or skills to keep it performing. To what degree is it future proof? Customised software can be expensive and difficult to maintain. What are the associated software license costs?

Suppliers/Third Parties

If the product relies on third party components what are the plans for support of these components? Will there be an upgrade or replacement cycle that will drive product costs or savings? How long will the current version continue to be supported?

Skills

Does the product need someone with specialist skills to support it? How much time are specialists spending on supporting the product? You may be paying extra for resources that spend 5 or 6 days a year actually using their specialist skills. You may also find you’re completely dependent on the knowledge of one or two individuals to keep the product running.

Future Proofing

Finally, project how the costs will evolve over the next couple of years. Will third party support or supply of product components be withdrawn? Are there any significant programmes planned which will require you to migrate products from legacy to new systems? Replacing or


upgrading elements of your Business or Operational Support systems can be a catalyst for a thorough review of your product portfolio and can deliver immediate cost benefits.

1.4 Planning

You have identified the products to be retired and have a business case to support this, so you can move to the implementation phase. It is essential to plan this phase carefully – get it wrong and you risk alienating your customers. There are a number of key factors to successful product rationalisation:

Key Factors for Successful Product Rationalisation

Your retirement plan should include:

Products

• Products to be retired • Alternative product options to be offered to customers

Customers

• Which customers are using products to be retired

Financial

• Customer incentives to swap products

Legal

• Updated customer contracts • Confirmation of company rights to withdraw products


Stakeholders

• Map the stakeholders in your company within Marketing, Finance, Legal, Operations, Technology

• Include impacted third parties – suppliers, partners, regulators

Communication

• Define your communication strategy, write your key customer messages and communication schedule

• Employee and stakeholder communications

Technology

• Map of systems impacted • Customer/product migration schedule • Plans for retirement/closure of redundant systems

Business Change

• Changes to processes/work instructions • Staff training (support and operational) • Escalation procedures for customer complaints related to retirement • HR – staff redeployment

Supplier Management

• Re-negotiation with partners following product retirement or migrations

Message Testing

• Test your key messages with a sample of real customers. How do they respond to the message? Do your messages address the range of objections customer might have, is the emotional tone right? Are your customers attracted to the alternatives on offer?

• Retest and refine your messages with customers until you’re sure they’re right.


1.5 Implementation

When testing is complete you should be ready to implement. Remember this is a process you will probably need to use again and again so use your experience to refine subsequent implementations. The major steps in the process are:

Product Rationalisation Implementation Cycle

Inform Customers

Tell your customers what’s going to happen, when the product will be retired, why you’re doing it and what their alternatives are. Provide them with a call to action that they can follow so you can assess how many customers are going to respond positively. Collect and retain customer responses which you may need to support customer queries and for audit purposes.

Migrate

What you do at this stage depends on your country or sector legal requirements situation and on your company’s attitude to handling customer migrations. You may be able to migrate all customers to an alternative product or you may be constrained to moving only those who have agreed to a move. Data migration must be carried out in a well-structured and managed way and you may need expert assistance to manage this phase of retirement.

Manage Down Support

If your product is still in the market but no longer being sold you can consider withdrawing or reducing the level of support for retiring products. You must inform your customers ahead of implementing this. You can manage down levels of support by reducing support hours, no longer updating the product, introducing charges for support or withdrawing specific support channels such as a live agents. It’s critical that you keep your customers constantly informed of the reasons for these changes and of their alternatives.


Retirement

There may be a substantial delay between the announcement of a product retirement and the actual switch off. But a failure to take this last step will prevent your business from full realisation of the benefits that drove your decision to retire products. Before the final product switch off issue reminders so customers still using the products are fully aware of what’s going to happen.

You should have analysed your product to ensure there are no cross product dependencies in place before embarking on rationalisation. However, it’s essential to have a roll back plan in place before executing final shutdown. Once the product has been closed down you should continue to monitor systems and customer support requests for a period to ensure that any unexpected consequences are assessed and resolved. You will receive calls complaining that a product has been withdrawn and that the customer wasn’t informed. Not all messages will get through or be digested so you’ll need the ability to respond to complaints and take customers through the migration or retirement process.

1.6 Realise the Benefits

It’s now time to deliver the efficiencies that drove the decision to embark on product rationalisation. Retire systems, redeploy resources, implement changes to business processes and make commercial changes. Assess whether the benefits are what you expected and ensure that the benefits are accurately reflected in company accounting systems so the programme stakeholders see real benefits for their participation. Review the programme and ensure you understand what worked well and what went wrong.

Review the results with your stakeholders – if this was successful they’ll probably want you to do it again! Product rationalisation should be something your organisation does regularly – without it you will almost certainly end up with an unsupportable, unfocussed product sets that consume your resources and distract you from staying focussed on your customers.