Converting customers to ‘Raving Fans’

Overview

Every one of us knows the importance of good customer service – whether in the products or services industry. Over the last few years, the world appears to have changed. Technologies such as Web 2.0 (and Web 3.0 going forward), mobile devices and applications, and social media are all putting the end consumer at the center of the universe. In such a consumer centric world, concepts such as next generation customer service and customer experience management become all the more significant.

Ken Blanchard, in his book “Raving Fans: A Revolutionary Approach to Customer Service” explains that even in case they customers are dissatisfied, they often don’t want to take the effort of providing feedback or complaining – since many feel that it won’t make a difference either way. He also says that most customers are so used to poor service, that they have very low expectations. Meeting those (low) expectations is usually sufficient to satisfy many customers.

However, the author says that it is not enough to have satisfied customers. It is important to convert your customers into “Raving Fans” – people who advocate your products and services and vouch for you.

The author outlines three principles for creating Raving Fans:

1. Decide what you want
2. Discover what your customer wants
3. Deliver + 1

Decide what you want

The first step is to create a ‘vision of perfection’ for your business that is centered on your customer. This vision should be as detailed as possible, and should focus on every aspect of the experience you want your customer to have.

How does this apply to us? In the products business, one of the best examples is Apple – whose products appear to indicate a strategy where every aspect of the end customer’s experience has been thought through while designing the product in the first place. In the services business, if I were to look at IT services (the industry I am a part of), this means creating a vision of what we would want every customer to experience: from the first introductory meeting, to the pre-sales and sales cycle, to the project planning and staff ramp-up, to the delivery and execution of the project, to the production roll-out of the software and finishing with the post production support. While this sounds simple and obvious, not too many companies may have such a detailed, end-to-end, customer centric vision in place.

Discover what the customer wants

The second step is to figure out what your customers want. Among the techniques used, a simple one is: Ask Them. Once you find out what your customers want, you might want to alter the original vision and fill in any gaps if required. Sometimes of course, your customers might not be able to state their needs very clearly and precisely. The original vision can then serve as a framework for filling in any gaps in your customers’ vision. One interesting insight from the author is on “silent customers” – he suggests that these are customers who are neutral about your products or services, or dissatisfied but not keen to take the trouble to provide feedback. In either case, if a large majority of customers are silent, it should be a cause for concern according to the author.

In the IT services industry, one challenge we often face is “Customers are not always clear what they want”, giving rise to the entire discipline of change management. However this applies to individual projects. I believe from an overall experience point of view, it should be possible to put a framework in place and get that validated with customers.

Deliver + 1

The third step is to deliver on the vision, plus one percent. The additional one percent is what wins over customers and converts them into raving fans. The author provides an example of a Taxi driver who keeps her cab spotlessly clean, provides a complimentary drink, newspapers and magazines, a telephone, television and radio to make her passengers have a memorable experience. The author also cautions that it is important to meet expectations first, and then exceed them.

We can think of several examples. One would be an insurance agent who advises the customer on the policy best suited for the customer, rather than the policy that will fetch the agent the best returns. Another would be an agent in a retail store assisting the customer with the best deals available, rather than just pointing out which products are in which aisle. In the IT services world, one thing I discovered a long time ago was that a little effort put in towards some additional documentation (above what has been signed in the contract) on the software and systems being built, that helped the customer understand what was going on, always made a huge difference.

Summary

Meeting customer expectations is just the first step. What is important is to create “Raving Fans” – customers who are vocal advocates of your products and services. To accomplish this author suggests a three step approach: Decide what you want, Discover what the customer wants, and Deliver + 1.

What do you feel contributes to converting customers to raving fans? I would be happy to know your opinions and experiences.

Elephants can Dance: Five Leadership Lessons from the IBM Turnaround

I recently read the book “Who says Elephants can’t Dance?” by Lou Gerstner, who led the remarkable turnaround of IBM in the mid-nineties as its CEO.

While it is clear that the fixes applied may not be directly replicable at other companies, there are several takeaways that can be an important source of learning for most organizations and leaders. For those of you who have read the book – I would encourage you to write in and share your own learning. For those of you who have not yet read it, I would recommend the book very highly from a management, business and leadership point of view regardless of which industry segment you are a part of. For people in the IT industry however, I would go further and say it is a must read for some of the things we can learn from it. In this note, I present five of the lessons that I learnt from the book.

Leadership Lesson #1:  Overcoming doubts about your own ability

However confident and self-assured we might be, we often face situations in leadership where we honestly wonder to ourselves, “Will I really be able to do this?” or “there is no way I can do this”. Gerstner is quite candid about his initial reluctance to take on the role of CEO of IBM. In the book, there are occasions especially during the initial few years, where he admits being overwhelmed with the task at hand. And yet, he hung in, resisted the urge to throw in the towel, and took the tough initial decisions that helped IBM survive.

The learning is that as a leader, it is normal to sometimes have apprehensions and doubts about the journey ahead. However, it is usually the initial period that is the toughest and if you can hang in, get through that, and just survive, it gives you a platform to thrive later.

Leadership Lesson #2: Culture is everything

In one of the memorable passages in the book, Gerstner mentions how he came to realize that culture is not just one of the most important ingredients of a successful company, but the most important. If we look at the IBM turnaround a bit more closely, perhaps the single biggest accomplishment during his leadership was the culture change that he was able to influence – from an inward, technology centric approach to a customer focused, business centric approach.

The lesson here is that if we are to be truly successful as leaders, we need to devote significant individual time and effort to influence the culture of the team and organization. This applies equally to the two diverse scenarios of an established large organization where a culture transformation is needed, or in the case of a new organization where the culture is yet to be established. When we look back at our leadership tenure, the fundamental question to ask ourselves would be “What sort of an impact did I make towards the culture of the organization?”

Leadership Lesson #3: Decisions and Risks

The near-death scenario at the company when Gerstner took over meant that there were rapid decisions to be taken from day one, and each involved significant risks. Whether it was preventing the breakup of the company into “Little IBMs”, or the move into services, or the acquisitions during his tenure – each demonstrated two critical aspects of leadership.

First, the speed of decision making is often as important as the decision itself. Second, our ability as a leader to take risks directly influences our speed of decision making. In other words – aversion to risk slows down decision making. Perhaps as a leader, you might want to set a self-objective over a period of time to increase your speed of decision making, or increase the quantum of risks being taken, or both.

Leadership Lesson #4: On structure – The whole is more important than the parts

So many of us belong to organizations large and small, where there is no doubt about the brilliance of the individuals or groups who make up the larger organization. Yet, we are acutely aware that somehow the results and performance of the overall organization don’t reflect that. Similar was the case at IBM when Gerstner took over. He mentions how he was convinced that the company, in spite of being perilously close to shutting down, was made up of some of the most brilliant and competent people he had met in his professional career.

The problem really was in the structure, and there lies an important lesson for the leadership and management teams of several organizations. In the name of decentralization and giving authority to the individual groups of the organization, a culture of “local empires” can get created. Each then becomes a fiefdom with its own identity, goals and objectives – and often these fiefdoms operate with so much independence that they compete with each other rather than with competitors.  One factor triggering this internal competition is that individual groups have the same objectives regardless of whether it suits the original purpose of the group being set up or not.

It is interesting to note how Gerstner pushed through restructuring and re-alignment by informing some of the groups that they were no longer profit and loss (P & L) making units of their own, but support functions for the core business units. We see the analogy in several large organizations today with matrix structures, especially in the IT services industry – with the vertical axis being industry and customer focused and the horizontal axis being technology focused. While the original purpose of the horizontal axis is to support the vertical one, this gets defeated the minute the horizontal axis is measured on the same yardstick of P&L as the vertical one.

Lesson # 5: The customer is the center of the (business) universe

Gerstner describes how the IBM that he took over was very inwardly focused – the structure and culture were both tuned towards IBM itself being at the center of most activities. He recognized this early and put in place several measures to ensure that every IBM employee understood it was the customer who was the center of the universe and not IBM itself.

Another of my favorite passages in the book is when Gerstner indicates his amazement at how obsessed the industry is with technology, regardless of how useful it might be for the end customer. He goes on to suggest that every individual in the technology industry spend time at customer locations to try and understand what customers really need technology for.

It is an interesting exercise for each of us to reflect on the organizations we are a part of, and ask ourselves whether the customer is truly at the center of our universe. Some simple questions to ask would be

• Has the organization structure I am a part of, been put in place keeping the customer in mind? Can it respond rapidly to addressing a typical customer request?
• Does the large majority of the organization (including myself and my team) spend a large majority of time per day on customer focused work?
• Does every member of my team have a deep understanding of the top three customers that the team is working with, including the business problem that we are attempting to help the customer solve?
• For the work that she or he is currently doing, can every team member name three customers to whom that work might be applicable over the next three months?

Six Steps to Private Cloud Adoption

Over the last couple of years, one of my interest areas in the “Business Technology” space has been Cloud Computing. In the jargon-rich IT industry, “Cloud Computing” appears to be yet another addition to the dictionary. However, when something has the promise of saving money, getting things done quicker, and being extremely flexible to changing requirements, it usually has a fair chance of success. Cloud Computing promises this, and much more.

Cloud Computing originally was interpreted as computing resources (say computers themselves, or storage space, or software platforms, or software applications) delivered as services over the (public) internet in a shared manner, for multiple customers.  The idea was to convert computing power into a utility such as electricity or water – to be consumed when needed, and paid for based on consumption.

The promise of cloud computing revolves around three simple ideas: Cost Optimization, Agility, and Improved Cash Flows.

Cost optimization is a simple consequence of the concept of a shared resource being available at a lower cost than a dedicated one. In this case, the benefits and cost savings from the increased utilization of computing resources that are shared across multiple users, are passed on to the individual users.

Agility results from the fact that cloud computing resources are intended to be ‘elastic’ – that is, they can be provided to the consumer when needed, and taken away when not. This helps business respond rapidly to changes in the environment – for example, sudden increased traffic to a web site because of some breaking news.

Improved cash flows are made possible by cloud computing because, instead of paying an upfront cost for the computing resource, the user is charged a “rental” or “usage” fee. This could be based on actual usage, the well known term being “Pay as you go” or could be a monthly flat rental.

Cloud services that were delivered over the internet came to be known as “Public Cloud” services. However, many of us are aware how internet technologies have been adopted within enterprises to form “Intranets”. In a similar manner, it is now increasingly accepted that we can have cloud implementations within the enterprise – the terminology, not surprisingly, being  ”Private Cloud”.

Private cloud implementations involve scale, complexity and uncertainty. A systematic approach to such implementations can help address these challenges. One such approach is outlined in a white paper, called “Six Steps to Private Cloud Adoption”. You can find the paper at the following link:

http://www.happiestminds.com/resource-center/white-papers

Feel free to reach out to me for any feedback or clarifications.

Leadership Anti-Patterns

Leadership is such a fascinating topic – there is no dearth of literature, opinions and examples of good leadership. In the corporate world for example, the stories of people like Jack Welch (GE), Lou Gerstner (IBM), Steve Jobs (Apple) to name just a few, have already become the stuff of legend.

Sometimes though, it is also interesting to study and be aware of effects (or disasters) of poor leadership. In the technology world, we sometimes use the concept of “anti-patterns” to illustrate certain practices that are known to have bad results and therefore need to be avoided. This post is about leadership anti-patterns.

Last week, I came across a very interesting article at McKinsey Quarterly “How leaders kill meaning at work”. The authors say that the sense of having made progress in meaningful work is a powerful motivator at the workplace. They also go on to caution people in leadership roles to avoid four traps that can make work less meaningful for their teams. My interpretation of these four traps is the following.

One, We need to avoid day to day work from becoming so transactional that the team loses sight of the bigger picture and the purpose of the organization’s existence. In several organizations, so much energy is spent on transactions that they become the end rather than the means.

Two, we need to avoid frequent changes in strategy, be clear about the direction we are headed towards, and communicate the same. However in reality, we often see knee-jerk reactions to external stimuli (for example, quarterly changes in priorities based on the performance in the previous quarter).

Three, we need to avoid situations where there is a huge amount of effort being put in from multiple sources, but in an uncoordinated manner – which could negate the overall individual efforts. This is often seen where organization structures are complex and overlapping (for example, multi-layer matrix structures) and the goals of various groups are not clearly demarcated.

Four, the organization vision, mission and goals need to connect with and provide meaning to every employee. The best way to illustrate this is the following: if a few employees were selected at random and were asked “Are you aware of the vision and mission of your organization, do your goals match, and do you have a sense of purpose in what you are doing?”. The answers will give an indication of how well the leadership is making life meaningful for employees.

In my opinion, all the four traps mentioned can be connected to one root cause, which is the successive layers of abstraction [multiple management levels] between the leadership and the trenches. Like the game of “Chinese Whispers”, messages between the trenches and the leadership (in both directions) could be quite different from what the originator intended to convey. One way to address this would be to connect the top and bottom of the pyramid in the organization structure – perhaps in the future the pyramid structure might need to give way to a spherical one. What do you think?

Note: I recommend you read the article, you can find it at https://www.mckinseyquarterly.com/How_leaders_kill_meaning_at_work_2910

 

A Simple Technique for Multi-Tasking

Introduction

Multi-tasking can be defined as the ability to execute multiple tasks at the same time. While computers and software are getting better and more powerful at multi-tasking, one of the demands of modern life is for people to increasingly have the ability to “multi-task”. The minute people are involved, output and results cease to be as predictable as they are for computers and software. Therefore we see that certain people are extremely good at multi-tasking, while certain other people struggle.

This note describes a practical technique for multi-tasking. The technique is derived from the technology approach of “Time Division Multiplexing” – applied in a human context. It is likely that a large number of people (you, the reader included) already follow this technique consciously or sub-consciously – I would request you to bear with me if you find this very elementary. To the few who might find this of interest, this is my attempt to articulate the approach in a form that is hopefully easy to understand and follow.

Example Scenario

For the sake of simplicity, let us define “Task” as a piece of work with a clearly defined objective. Let us also assume that a task can be split up into smaller units called “Transactions”. Consider a situation where there are three tasks to be completed in a period of time, say 3 hours. Let us also assume that the effort for each task is such that it can be completed in 1 hour. Finally, let us assume that each task can be divided into 10 transactions, with each transaction on an average taking 6 minutes.

Sequential Approach

One way of approaching the situation above is to complete the tasks sequentially – finish the first task with the 10 transactions in the first hour, then move to the next, and finally the third.

Problems with the sequential approach

-          A delay in any of the earlier transactions or tasks has a cascading impact on the subsequent ones

-          If the time for each task is increased to say 1 day each, then a sequential approach results in no work getting done for the second task till the second day, and the third task till the third day. This can leave the stakeholders for the second and third tasks very unhappy.

Parallel Approach: Multi-Tasking

Since the limitations with the sequential approach are easy to understand, most people would be in agreement that it would be much more beneficial to follow a parallel processing approach. The real problem, and where a lot of people get stuck, is how to actually implement multi-tasking.

Proposed Technique

1. Divide the total time available into “time slots”, with the duration of each time slot just enough to complete one transaction. In the current example, we can divide the total time of 3 hours into time slots of 6 minutes each, since each transaction on average can be completed in 6 minutes.
2. In each time slot, focus on sequential transactions, but from different tasks.
3. The first three time slots will therefore have the following transactions: Task 1 – Transaction 1; Task 2 – Transaction 1; Task 3 – Transaction 1.
4. The next three time slots will then have the following: Task 1 – Transaction 2; Task 2 – Transaction 2; Task 3 – Transaction 2
5. The figure below illustrates the approach.

Benefits of the approach

1. Over the given period of time (in this case 3 hours), all the tasks get completed, just like they would have in a sequential approach.
2. However in a shorter time interval, say 1 hour, some work gets done on all the tasks.
3. This helps manage perceptions for the stakeholders of all the tasks, none of whom feel neglected.
4. At a high level, it appears that multiple tasks are being executed in parallel – which is true over a 1 hour period in this example.
5. However, at a transaction level, it is still one transaction at a time. However since the amount of time for each transaction is small, it appears at the higher level that there are multiple tasks getting executed.

Things to keep in mind

1. Speed of transaction closure is critical. Duration for individual transactions should be very short, preferably a few minutes at most.
2. While closing a transaction, focus only on that transaction and nothing else. To that extent, multi-tasking over a longer period of time is really very fast and very efficient uni-tasking in shorter time slots.
3. Context switching is critical – since the transaction in every time slot is from a different parent task. People often find this the most difficult thing to do.

Summary

With practice, it’s possible to increase the number of simultaneous tasks, and also greatly reduce the time taken for individual transactions. People who do this, consciously or sub-consciously, appear to have the ability to execute several tasks in parallel. A look at the details however reveals what is really happening!

Incremental versus Radical Innovation

Innovation has always been at the heart of human endeavor since time immemorial. The invention of the wheel, discovery of fire, automobiles, aircraft, space travel, computers, the internet, and so many other things – advancements in the species can usually be traced back to some innovation or the other.

There are two types of innovation that are well known. One is incremental innovation and the other is radical or disruptive innovation.

Incremental innovation is essentially about optimization. What this means is that if you consider an existing process or way of doing things, there is always the scope to execute a step or activity a little differently or in some novel, innovative manner. Innovations of this sort build on what already exists, and result in improvements and optimizations to the end result. For example, the cycle time of a business process could be reduced by means of some innovation at one or more steps in that business process.

Incremental innovation is typically seen in large organizations, where the focus is more on processes, optimization, and improvements and where risk taking abilities are on the lower side. In fact, when large companies talk about implementing innovation in their organizations, it is usually incremental.

Radical innovation is related to those “Eureka!” moments of inspiration or insight, when we are able to look at a problem in a fundamentally different way. One example of radical innovation is web email. Traditionally, email was about installing client software on every machine, with the client connecting to the mail server to send and receive mails. This also meant that you could check email only on the machine where the client software was installed. With web email, all that was needed was a web browser and an internet connection. This not only eliminated the need to install and maintain client software, it also ensured that we could check mail from any machine with a web browser. Web mail possibly was the first major “online software” application. With the current focus on cloud computing and online software, it appears only a matter of time before web email becomes the default way to send and receive email.

The implementation of radical ideas usually involves a high element of risk. Therefore, radical and disruptive innovation is usually demonstrated by smaller organizations and start-ups (with a few notable exceptions like IBM, Apple and Google) rather than established and large organizations. Interestingly, it is this very aspect of radical innovation that enables small organizations and start-ups to succeed and displace the larger ones. In other words, possibly one of the biggest threats to the survival of large organizations is their limited ability to foster and encourage radical innovation.

Perhaps it is time for large organizations to devote a significant portion of upper management time and effort towards radical innovation, since there is a possibility they may not be able to survive and thrive without the same. Meanwhile, the smaller companies need to continue and increase the pace of radical innovation – since it is a certainty they will not be able to survive and thrive without the same.