How to Improve End User Relationships By Learning From Others’ Mistakes

Introduction

Welcome back everyone!  I hope you all enjoyed the Thanksgiving holiday (I know I did).  As some of you may know, Blizzconn (a convention for Blizzard’s video games) took place a few weeks ago, and  I was hoping to hear news about a Diablo 2 Remaster. For those of you who have no idea what I am talking about, Diablo 2 was a popular game in the early 2000’s and one of my personal favorites.   I was slightly disappointed when I realized that Blizzard was really working on making their new Diablo game for mobile phones, but was appalled with the way they handled the outrage from their core user base. As I pondered the situation further, I realized that this is hardly an isolated incident, and many tech giants have made mistakes in maintaining relationships with their customers.  So today, I would like to spend a few minutes with you discussing some mistakes I have seen from these titans and how we can learn from them.  

Actively Engaging With Your Customers

If you have not had a chance to watch the Q&A for Diablo Immortal, please take a minute to view its most notable highlight below.   Let’s examine the response to the booing for a moment.  The presenter saying “Do you guys not have phones” exposes a couple mistakes.  First, Blizzard assumed what its core fanbase wanted when they should have engaged with them to create a product.  This does not mean that the company should have refrained from developing a mobile Diablo game, as there are many users of that platform out there who would likely enjoy it.  However, the crowd they were presenting to mostly consisted of gamers who prefer the PC platform, a much different target audience. The question also suggests that Blizzard blamed them for not liking the product, which no business in their right mind would do to their customers.  So what does thing have anything to do with being in IT?   As tech professionals, we are expected to listen to our users so that we can provide them with the best solutions possible for their problems.  However, it is all too easy for us to experience a disconnect because we think we know what is best. Take Windows 8’s user interface as another example.  Can you imagine how frustrating it must have been for enterprise Windows users to go from doing 15 years of this…   To this?   Being tech savvy, most of us just saw a change to the user interface, and were not bothered by it considering the OS logic acted the same as it had for the last decade and a half.  But for most end-users, this flipped the world upside down. In an effort to make their UI friendlier to the mobile computing crowd, Microsoft made it more complex for the target audience they enjoyed since the mid-90’s.  A little one-on-one with those users would likely have driven them to keep the original menu, or allow users to alternate between the original UI and its replacement. The company was able to make up for this by offering free upgrades to Windows 10 (which brought back the classic start menu), but I personally believe that everyone should have saw complaints about the UI coming miles away.   Actively engaging with the end users to make a technical solution for their problems seems like a no-brainer, but instances like these show that even the best of us are capable of forgetting to do so.  If we actively involve them in the process of developing requirements, we significantly reduce the chances of us releasing a product that they will dislike.  

Declining Requests…Politely

Sometimes our users have a set of requirements they want met and ask us to provide technical solutions that do not make sense.  Take the video below as an example. In a separate Blizzard event, a fan asks if the company would stand up servers for an online game (World of Warcraft) that ran on legacy versions, and was met with a very condescending response from the production director (J Allen Brack).     I am sure we can all agree that Brack makes excellent points on why the request would be problematic.  Being tech professionals, we understand that the problems from previous versions of the game would still be there and that such environments would be a nightmare to support.  But was his response the best way to communicate these concerns? In my opinion, he came off as callous and made the audience member feel dumb for asking such a question, which you should never do when interacting with your users.  I think this could have been handled much more constructively. Maybe something like…   “We take pride in providing the best service possible to our players, which is why we cannot stand up these servers at this time.  The reason for this is that the bugs that existed in these versions would still be present, which would have a negative impact on our customers.”   See?  We have successfully provided the same explanation without being snarky, which allows us to preserve the image that we are helpful while politely telling the user “No”.  Being respectful goes a long way, because it helps build trust between us and our users. If we act disrespectful to them, they may chose not to work with us and seek out their own technical solutions, which can include (but are not limited to) the following issues:  
  • The “solution” is not vetted by IT and could contain malware.
  • When the “solution” does not work, IT will be expected to support a product that they have no knowledge of.   
  • Since the “solution” is technical in nature, the cost for it could be taken out of IT’s budget.
  But what do we do if our users keep pressing us to implement a request that we have already declined?  This is where I think Mr. Dale Carnegie can help us out. In his book, “How to Win Friends and Influence People”, Carnegie stresses that rather than arguing with people, we would should find common ground to help them agree with us.  He calls it, “Principle 5: Get the other person saying ‘yes, yes’”. So how can we use this in our profession?   Let’s say we have a user, named Ted, who is self-employed and works from his office and on the road.  Ted works with a lot of documents, and needs to have the ability to access them from any location. Because of this, he asks us the following:   Ted: “Could you setup a server to store my files?  I need to access them from multiple devices, as I am either in the office or on the road while working.”   Right away, we can tell this is a legitimate business need, and suggest he use Google Drive for this purpose, as it is an already existing application that is free to use.  But Ted still feels that his own file server is the best solution, and keeps pressing us to set one up for him…   Ted: “I do not think Google Drive would work as well as my own file server would.  Would you please set one up?”   Rather than decline his request once more, we take the opportunity to help him understand that it is not the best solution by being agreeable and asking questions…   IT: “Is Google’s platform free to use?”   Ted: “Yes, it is free.”   IT: “Is it true that there would be costs associated with setting up a file server, such as paying a developer to write applications that would allow you to easily access your documents?”   Ted: “I had not considered that before, but yes.”   IT: “Would it also be true that you would need to maintain the infrastructure by paying someone to host this server?”   Ted: “Yes.”   IT: “Does Google likely have a team of professionals that ensure their service is secure and easy to use?”   Ted: “Yes.”   IT: “Would it also be true that one IT professional would not be able to provide the level of service and security that an entire team at Google could?”   Ted: “Yes”   IT: “Bearing all this in mind, would you agree that Google Drive would better serve your needs than a personal file server?”   Ted: “I suppose so.”   Congratulations!  We convinced Ted that Google Drive is indeed the best option for his needs.  If we had outright said no, he would either not have a solution to his business problem, or would have found someone to implement the solution in his vision (and paid out the nose for it).  

Parting Words

Before I return to my exciting life of eating Thanksgiving leftovers and drinking decaf, I want share some useful advice from Fred Meijer:   Customers do not need us; we need them”   We must remember that without our users, our technical knowledge is worthless.  We must always strive to listen to their needs and be respectful (especially when denying a request).  IT departments exist to help find technical solutions to business problems, and having good working relationships with our users helps us craft the best solutions possible for them. Have any questions, comments, or concerns about this post?  Notice anything that can be added or approved? If so, please let me know in the comments.  I look forward to hearing from you!