My company has recently launched a new product that is being distributed to millions of users around the world. I have been tasked with providing user support for this product.

Some of the power users, however, are used to the old product, and have rather strong dislike for this new product. It is becoming hard for me to convince them about using the new product. Most of the times when I explain the features of the new product, they respond with, "oh, but the old product did it much better" (or equivalent).

Management is convinced that the new product is great, and it will bring in more users. While I understand the management's zeal to promote the new product, I am also struggling to present it with the same enthusiasm to the users who are resistant to change.

I want to raise these concerns with the management. I clearly don't want it to come across as "the new product is bad, nobody likes it" and douse the enthusiasm. However, I also want to bring it to their attention that the users aren't quite as excited. These power users are only a small portion of the customer base, but they have a lot of say in deciding what other people in their team decide to use, so these power users have to be kept happy or else our company will lose a lot of business.

My goal is to find a practical solution to the issue which allays the concerns of the power users, while at the same time ensuring that the management doesn't lose face. How should I approach the management to try to achieve this goal?

  • @JoeStrazzere The old product was a software library designed for a specific purpose. The new product is also a software library developed from scratch, which makes things easier by doing some things inside the library which were formerly done by the user. Nonetheless, the users still prefer the old approach.
    – Masked Man
    Commented Oct 11, 2017 at 17:27
  • 1
    @JoeStrazzere That sounds like a good idea. I will have to think about it. It sounds difficult on the face of it. The closest (although highly misleading) analogy I can think of to describe the situation is teaching someone to drive an auto-transmission vehicle, when they have been driving a manual transmission their whole life.
    – Masked Man
    Commented Oct 11, 2017 at 17:39
  • If you don't have one at your company, create a user focus group and allow them to see potential significant UI changes BEFORE they go public. I have included this in my answer.
    – Neo
    Commented Oct 11, 2017 at 18:08
  • 53
    Power users are intended to hate new and user-friendly products. Didn't you hate the new MS Office toddler-friendly menu that appeared in 2007 and had only the commonest features available? Power users are probably right - the old product seems to be "closer to iron" and thus better. Management is probably also right - the new noob-friendly new product will get more new users into your product. Just don't lie to existing clients - they shouldn't be forced into the noob version...
    – Džuris
    Commented Oct 11, 2017 at 20:32
  • 3
    @MaskedMan the "manual vs auto" analogy may actually be useful for your boss. It is very true that 'auto' is more comfortable for the casual driver, while also being true that a poweruser can no longer drift, or control the car's stability, or save petrol by using the 'wrong' gear, or prevent tire wear, etc. Worse case scenario, if they try their existing tricks with the new car, they might crash. So it is entirely reasonable to expect they would be upset (while also being entirely reasonable that 'auto' is a far better solution for general driving, and particularly for the casual driver). Commented Oct 12, 2017 at 10:02

5 Answers 5


My goal is to find a practical solution to the issue which allays the concerns of the power users, while at the same time ensuring that the management doesn't lose face. How should I approach the management to try to achieve this goal?

As User Support, your job in this context is to relay the concerns of these power users to management. Then management will get to decide what (if anything) to do about it - that's their job.

Gather the responses (perhaps in summary form) and send them to management for their review (or communicate them via a ticketing system if you use one). Once management has made a decision, it's your job to support that decision when asked by your users. If you aren't sure how to communicate that effectively, ask your boss. That's a typical role for the head of User Support - crafting an effective message.

It can be difficult to be in User Support. You don't design the product. You don't develop the product. You just try to help the millions of users in their use of the product.

Since millions of users use your product, clearly not everyone will be happy with any change. And as anyone who has spent time in Support knows - happy users seldom contact Support. (I've managed Customer Support in the past. It wasn't always fun.)

Management, and the Product Team, must decide if the feedback from a few outweighs the non-feedback of the millions. And they must balance any feedback against the intent of the change.

Many power users tend to like things just the way they are. But catering to the desires of the few tends to limit progress.

  • 18
    Concerning "the limit progress" remark:+1, despite: Change is costly. Changing a library is pulling the rug under the power-users, while they are not looking for a new rug. Some companies (insert a very big name here) get their user base used to change, so, while not welcoming, they expect and accept it. But, in general, it's a nuisance. Realize it is, and now you need to find ways to sweeten the bitter pill, and a promise of a bright future isn't enough here, because these people have things to worry about right now. Plus, there is no guarantee that the change is ultimately better. Commented Oct 11, 2017 at 18:12
  • 3
    Of course - however, the way OP's question is posed, it appears to me that the change is substantial. Otherwise, what would be the cost for the power users to just continue business as usual and then to start to "ease" into the new options with time? This would be the natural line of argument for OP in that case. Or else - give the power users a short training into the best practice with the new library. I suspect it is not as cheap as that in the present case, but only OP can tell us whether this is indeed their dilemma. Commented Oct 11, 2017 at 19:22
  • 1
    This is a good answer. I would only add that if your company is already audio recording some these phone calls "for quality assurance or training purposes", that you should try to submit a few audio clips of those customers to your bosses. It's one thing to read what customers are saying. It's another to hear them, hear their insistence, and their emotions. Commented Oct 11, 2017 at 19:37
  • As User Support, your job is to relay the concerns of these power users to management. - Citation Required - is it really or is it their job to enter the feedback into the system they have been provided to do this? Commented Oct 11, 2017 at 20:58
  • 3
    I personally hate change. Even if the products is improved and the new product is better, generally I will hate it. Typically only over time I get used to the new product and will be happier. This could also be the case here. Commented Oct 12, 2017 at 9:13

First off, the basics:

  1. People hate change
  2. Life is change
  3. Change is not inherently good or bad.

If I were in this situation, I would stress the importance of having the old code available for rollback, if possible, or, to have all concerns expressed by the user base thoroughly documented and outlined for future enhancements.

Then sit back and wait.

The important thing to do is to separate out what is simple resistance to change, and what is genuine dissatisfaction. If you're getting complaints within the first few weeks, it is to be expected. Categorize each complaint and group similar ones together. If the number of complaints for a particular category decline over time, it's usually just resistance to change. If, however, you are finding the same complaints over and over, watch your user base and see if there is a decline.

If there is a decline in users combined with consistent complaints of the same nature, and those complaints expressed by those who stop using your product, then those need to be addressed immediately. Report those trends to management immediately.

Also, solicit user input:

Hi, you may have noticed the following changes in our product, we think they're great, but as always, we appreciate your input. Please let us know what you think so we can continue to build the best product with you, the customer, in mind

Finally, while you should take the concerns of the power users to heart, understand that they may only be the most vocal. This is a tight-rope act as power users and vocal critics can start a sort of "cyber-stampede", and with the pace of change in the software industry, trends can shift very quickly. Keep on top of it, but most importantly, keep communication going. Don't let it get to the point where any of your users feel that their concerns are being dismissed. This way, you can attract new customers without alienating the old ones.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat. Commented Oct 13, 2017 at 2:46

How should I approach the management to try to achieve this goal?

Document every legit item in detail, and include the specific users who reported them to validate your findings.

Once you have a sufficient amount of documentation, set up a meeting with the appropriate parties and layout what was reported. I would also be prepared with several legitimate doable suggestions that the users, and even yourself provide.

Once the meeting has taken place, be prepared for nothing to happen quickly. The folks in charge of the product will need time to digest the information and to weigh the impact of any proposed changes.

Once any decision is made, it will take time and money to make any accepted updates turn into production reality.

Another suggestion I will make, if you don't have one already, create a focus group consisting of some of your key users, and run any of these types of changes through them first. This will minimize the chance of surprise negative feedback when a feature goes live because if you give your users a voice, they most likely will use it.


How should I approach the management to try to achieve this goal?

I have to agree with other answer in that it is not your job to design or decide what features the app will or should have. It is your job, however, to relay and communicate all this feedback you get from users (regular or power users) to management, so they can decide how and if to act based on that feedback.

Now, when designing Software Products (as per UX and HCI theory) one should always try to consider the most types of users possible, so you can satisfy most of their needs. This usually involves power, regular, newcomer, old, and many other types of users. This is so your app is well received by most of your user base.

Usually, HCI theory states that "if you satisfy your hardest type of user, then the others will also be satisfied". This may be a valid point for you to relay or consider, so that the opinion of these power users are taken into consideration and so there is a chance other not-so demanding users to be satisfied as well.

However, it is not wise to deviate or alter the functionality or appearance of an application just based on the feedback of a "numerically insignificant" amount of users. By trying to please this few users you may probably lose a whole bunch others in the way.

What could be done, and what is suggested in these cases, is to include some functionalities in your app to be exploited by your power users while leaving the other, more widely usable features for the rest of users. Think of it as "easter eggs" in your app, the ones that only power users will know about and want to use, but that regular users will not be confused by it's mandatory use (usually not in plain sight or obtainable by some sort of metric like reputation). This enables your users to have the freedom to chose how the want to perform certain task, either the fast and pro way or the slower but safer way of action.

  • Note that the product in this case is a software library not a complete program, which changes things a little in that you can make a good argument that All users are in some sense power users. Breaking changes in libraries are a hard problem, and really the correct answer from your users perspective is to keep the old version available on maintenance for at least a few years, their development cycle will NOT line up with yours and if you are in the business of selling libs the power users (You know, the software architects, the team leads) are the only people who matter.
    – Dan Mills
    Commented Oct 11, 2017 at 22:16

You should not if you want to continue growing your career with this company.

In theory the way the Mister Sort of Positive explains here is the best way to collect and prove your point to management. An objective management team would evaluate that data and realize they need to do something to recover (assuming your assessment of the change is right.)

However the reality is that management is still made up of human beings, as they may wish they could transcend that. And they are typically type-A personalities with bit of narcissism and egotism. Humans with these traits often find it difficult to accept when a major decision of theirs is received poorly. Especially when the decision is a personal preference.

The only way I can see something like this being acceptable, is if you have a sympathetic manager who is willing to champion your cause by essentially making it your own, or if a manager asks you to put together that document. If you take it up on your own initiative this is more likely to be seen as insubordinate, than as an attempt to help the company.

And since the manager can not disipline their "Stupid Users" instead often times managers will label the messenger as a trouble maker. This is not fair when judged by any objective standard I can see, but it is a reality of dealing with human beings.

It usually will not take too many months for a manager determined to make one of their reports' look like the trouble maker, that needs to be let go, or have you exiled to the department that handles the legacy system, that no one wants to work on. This transfer will be on your record and while your record may not have any marks you can see, this department is known by management as the department that problem employees are sent to die. So while the practice may actually be illegal in some places, it is incredibly difficult to prove, and finding a lawyer that will try to prove it will be cost ineffective.

Save yourself the headache of this fight. It is not one you are going to win.

  • A valid perspective I had not considered. You could be buying yourself some pain by attempting do do some good. UpVoTeD
    – Neo
    Commented Oct 12, 2017 at 13:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .