Customer Support and Building Relationships

This is Building Better Developers, the Develop-a-Noor podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Well, hello and welcome back. We are continuing our season where we're looking at the bright side of things. We are looking at these challenges that we face daily and where there is a pot of gold at the end of the rainbow. Where getting through these things are actually valuable to us and actually make us better developers. These are some of the things that we go through. We survive and it doesn't kill us. It makes us stronger. This episode, boy, the last one was a tough one, but this one, customers, customer support. You may think, wow, customers are not negative at all. They are our bread and butter. They are our lifeline. They are the reason we have paychecks. You would be correct. However, I think we've all been in situations where there is either a request that a customer makes that is maybe at an inopportune time or is a feature that's just a pain to deal with or if you've worked support, you're in a situation where you're actually having to support a specific customer. request for a feature or customer support as they're having problems, they can be a challenge. They can be a drag. You think at the most, it may seem very simplistic, but one of the most simplistic, easy ways to look at it is when you're doing enhancements and maintenance and upgrades, there's a lot of times that you can look at a situation. When you look at the software you've got, the problems you've got, the enhancements, the features, maybe there's some re-architecting that you need to do, some refactoring, and you can look at it and say, wow, if we didn't have customers to support right now, we could get this thing knocked out or we could really make a good version of this, but you can't. You have people to support, you have a live product, you have expectations to meet, and particularly from the development point of view, if you don't have much time that you've spent on the business side of things and looking at the why we're solving the problem, customers, they can be quite a drag because they're going to want, I don't know, a solution that works that is not going to allow us to do the things we would really want to work on from a programming point of view, from a coding point of view. Sometimes the problem itself that we are solving is made a bigger challenge because maybe they don't understand the problem, maybe they've got multiple problems and we can't solve all of them at once. There's a lot of situations where dealing with customers can be a negative, can be a problem, but these all have an upside as well. I think that first one I want to talk about is actually what I just wrapped up, I just talked about, is the idea or the situation where we're figuring out what is the problem we're solving. Usually the way this situation arises is when we are proposing a solution or probably better yet, sort of hashing through a solution, talking to a customer and getting their problem. Maybe we've sat down and we've talked through the problem to the point where we think we understand it, but usually this arises when we don't. We may understand it to some extent, but they have a different view. We run into situations where we're trying to essentially solve one problem and they're needing us to solve another or in the same boat where we are trying to solve the problem, but they don't recognize it as a solution. This could actually go either way. We don't realize that our solution is not what they need or they don't recognize it because of some predisposition one side has that a certain thing has to be included. A common way that you would see this would be somebody for some reason thinks that, let's say, C sharp is the language that needs to be used as the development language to solve this problem. And actually the problem has nothing to do with the programming language. So you end up in a situation where they're insisting that the Java solution that you propose doesn't work because they are sure that you have to have C sharp in it. We do this as well as they do. This is not, I pick on the customers, but it's a situation where if the customer didn't exist then we would go off on our merry way anyways. The positive that comes out of this is that it's one of those things that forces us eventually, it may take a while, whichever side is on or whatever, but to really examine a problem from a couple of different points of view. Because that's usually the root of why, or the rut if you want to call it that, of why we have this disagreement or this challenge is because we're looking at the problem from one point of view. They're looking at the problem from a different point of view. And so both of us are not wrong. We are right in our view, but because we're coming at it from a different point of view there is some disconnect there. And one of the things that we can definitely all do more of is look at problems from multiple points of view. Bias is everywhere. There's all kinds of, go out and search, do a Google search on bias and forms of bias, and you'll see that we have a lot of biases that we don't even know about and it basically comes down to our point of view. At some point, hopefully we recognize that there are multiple points of view and that means that that's not that they are wrong, it's just that they are looking at a problem from a different perspective. And so we need to be able to understand how the solution works from that perspective well, or to make sure that the solution covers that perspective as well. And so this actually has a sort of a two pronged positive. One is that it forces us to look at the problem from a different point of view. That specific different point of view that they have. But also is an experience where we can see that we thought we were 100% right, maybe we were. They thought they were 100% right, maybe they were, but we still disagree. And so as we go forward, I think that is when we move forward from that situation, I think that's one of the things that helps us in the future examine problems better. Because it helps us be sensitive, I guess, to the idea that there are different points of view. And so when we ask questions and when we examine a problem, it makes us a little more likely to keep that in mind and to try to make sure that we are covering all the points of view that we need to for the problem when we propose a solution. Now the other thing is, this is another, it's a two-edged sword. But when we deal with customers, whether it's, like I said, this can be bothersome to us because there's customer requests and then we've got to stop what we're doing to fix those or we've got to incorporate those into the next release or whatever the negative side of it is. The positive is, it's an interaction with the customer. That is always, now like I said, maybe a two-edged sword because you could screw it up. You could do something and tick off your customer and then lose that said customer. Or the better way to look at it, the positive way to look at it is this is an opportunity for us to win over the customer, to make them happy, to do something for them so that they like us more, that they have more confidence and trust in us. And they, honestly, they've already got some level of trust or faith because they're a customer. They didn't just give us their money because they just wanted to spend money. They gave us the money because they had some faith or trust that we were going to deliver for them. They're paying for a solution and so they had some confidence, some level of confidence that we were going to deliver that solution. And so now this is an opportunity to help reinforce that. And in so doing, either make them more likely to buy in the future if there are other buying opportunities or to go out and to be a positive force, maybe a good reference when they're talking to others where they'll say, hey, we worked with these guys. They're great. They helped us out. They solved our problem. So you can win with that. And this is not always, you go to a salesperson and even really, I think a lot of marketing people, although they've got a slightly different focus, when you talk to them about the idea of having communication with customers, having the customer's ear, you will realize, I think when talking to them that that is important. The whole, the worst thing in sales, probably the most challenging thing maybe in sales is the cold call. This is the, I don't know you. We haven't had a conversation. We have zero relationship and I'm trying to sell something to you. That doesn't mean you're going to sell right away. You probably want to build a relationship, all that kind of good stuff. I don't want to go into it other than the fact that a cold call is difficult and that's no relationship. So that's on one end of the spectrum. But you go further to the other end of the spectrum. The more you go along that spectrum, the more likely in that spectrum of a relationship with your customer, the further you go along that, the more likely they are to buy from you. Think about it. If you think of the person you probably have maybe the strongest relationship with, maybe your mother, she would probably buy anything from, I mean, obviously if you sell ERP systems, she's not going to buy an ERP system from you unless she happens to be in the market for one. But in general, the people in a family, that's the first people to sell to. Girl Scout cookies, who buys most of Girl Scout cookies? Family members. And so those are the people with the strongest relationship. So if you take the situation that is a challenge, and it may be very well that the customer recognizes it's a challenge, that actually is a bigger win because they realize that you didn't really, either you didn't want to be there or it didn't help you as much as it helped them, however it is, but that you put them first. And when they do that, they're going to feel special because you've made them special. You've said, yes, I'm going to put you first. And so now you've got a better relationship. And even as a developer who maybe doesn't spend much time talking to customers, this is something that we do run into at times where maybe we're working technical support or maybe we're included in on a call or something like that. Or maybe we're just asked, maybe we don't have a direct conversation with the customer, but we're asked, hey, can we get this thing in for this customer? There's always reasonable limitations and stuff like that, but it does help for us to do so. So building a relationship is a huge positive in this customer relationship thing. Another thing which is, it comes from that relationship, is that the customer is more likely to, I will say vent. They're more likely to share pain points and problems and I'll say honest feedback. Now if you tick them off, if they have a bad experience, you may get more honesty than you want, but also they're going to be, even then they're going to be focused on that negative thing that set them off. If it's a bad review or if they're calling to complain, they're not really going to, they're not going to be in a situation where they're going to talk to you about the overall experience that they've had. But when you're in this situation where you're really working with them off of a feature or request, a support call or something like that, then there's a, it's a little more, I'll say usually it's a little more casual kind of relationship that you're building where you'll be able maybe to hear about some of the other challenges that they have. What is it that they like? What is it that they don't like about your product, about their job? And this is a goldmine of opportunities for new features for your product, possibly even whole new products. And I know that we have, I've been in companies where we were, the developers were essentially frontline or frontline-ish, second, third line, whatever, support. And the conversations we had with customers directly led to new products. We would talk to them, the challenges we had working with them, supporting them, trying to get them through their problems. So putting ourselves in their shoes and seeing what they had to deal with. But also just hearing where there were some other things that we didn't really directly solve, but where we saw that we could, that we had a possibility for another solution. And this is something we've talked about in other areas where it is very, when you're looking for a product to create an idea for a product, that you just start talking to people, what are their pain points? What is it that bothers them? Ideally, what is it that keeps them awake at night? Because if you can solve those things, people will pay money for it. And thus, you have a product, maybe even a company, maybe even an entire enterprise. But it starts with having the kind of a conversation that will allow you to learn what their struggles are. It's going to give you a whole different perspective on the problem and the environment that they work in. That leads us to the last thing I want to mention is that these conversations actually give us a mirror of sorts to look into. In these conversations, in these interactions that we have with these customers, in the feedback that we get from customers, we get to see whether our product actually solves a problem it's supposed to solve. If it does so in a way that's a good user experience or a bad user experience, we get to learn possibly the ugly truth or maybe the pretty truth about our product, about our solution. Besides just features of the product, we get to see how we are viewed, how our organization is viewed. And while our products are one thing or solving a problem, our organization and how it's viewed is a piece of that as well as a piece of our success. Because you can build the greatest product ever and if everybody hates you, they probably still won't buy it unless it's just really, really good. And then they'll be, you know, maybe they'll do so but not be very happy to spend, send over their money. Versus if you've got a decent product, maybe not the best ever, but everybody likes you, then you're more likely to get customers and customers that stick around, which are the best kind of customers. So that brings us to the challenge of the week. When was the last time that you found yourself struggling with something that was related to a customer? Whether it's a customer request or an approach or tact that you had to take because there was customers, because there were customers out there. For example, like a maintenance window at three in the morning as opposed to doing it at three in the afternoon because you don't want to interrupt the customers and their work on your product. And then were there any positives that came out of that? Can you think of a positive that comes from that? What did you, you know, maybe what did you learn being awake at 3 a.m. doing a maintenance jam for a maintenance window? That one may be a little more tougher, but maybe you, maybe you in that process learned how your customers use your product. What your peak times are, what your non-peak times are. Maybe you spent some time doing that and realized that, wow, this product takes forever to do a maintenance. These maintenance windows should be much easier than that. Or maybe our backups are not very good. Or maybe our backups don't exist. There's all kinds of neat little things you can learn in those situations. And that being said, I'm going to go let you learn in whatever situation you happen to be in and go out there and have yourself a great day, a great week, and we'll talk to you next time. Thank you for listening to Building Better Developers, the Developer Noir podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues, or visit our site at developernoir.com. Just a step forward a day is still progress. So let's keep moving forward together. There are two things I want to mention to help you get a little further along in your embracing of the content of Developer Noir. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developer Noir site. You can also find it on Amazon, search for Rob Rodhead or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our mastermind slash mentor group. We meet roughly every other week and this is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time. We talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at developernoir.com if you would like more information. Now go out there and have yourself a great one.