Very good. So welcome everyone. I'm really sorry that this tech happens at the beginning. Always happens. I won't share slides with all of you.Instead, I'm going to share these things because I want you to think and I want you to get some ideas for how you're running your own product and customer support um organizations. So take some notes if you want or uh follow me on linkedin where I'm talking about the same thing over and over again. So I'm Valentina, I'm Empress of remote and quality support at clause which is the customer support quality platform. And before being the empress of remote, I actually worked there as the head of product. And before that I was leading customer support teams. So the customer support world and the product world are basically where I feel most at home. And it's one of my, my passion is to bring both together. And one of the things that I've learned working in both of them is that how customer support facing teams and how product teams view things that happen in their day to day life on a timeline is very, very different. And that's where a lot of friction comes from.

So what we are going to dig into today, we have about 15 minutes because I want to also give you time for questions is how to product and support. Actually view customers and feature requests. Like what is that for them? How they view time and what you can do, like very, very practical in order to solve for these differences. If you have any questions, feel free to put them into chats, like I'm going to scroll through it afterwards and see if there's anything that I can help you with. If you have questions that are related to these topics and crisscross with remote, feel free to follow me on linkedin. I do once a month a session where I answer open questions from anyone in the community and you're very welcome to come there. But let's start, let's start defining what we're actually talking about. So let's start talking with customer first slide customer. So what is a customer? If we are looking at support, not slide. If you're looking at support, then the customer is somebody who needs help. Now they need help with your product or your service. Um And they need this now, they usually have a problem. They might be emotional or not emotional about, about it, but they are with you because something happened that you hopefully can help them as a customer facing person.

Um very often the emotional, the emotion underlying the customer there is negative, confused, maybe unhappy because not many customers actually get to chat in order to tell you how amazing you are, that would be great. And if you ever talk with the customer rep, tell them they're great because it's nice to hear that too, but it's slightly negative. So if you look at it from a product point of view though, uh product people, we are now on product, not on support. Uh product. People usually see customers as a resource that they can dig into when they are going to develop new features. That means uh the interaction with customers is usually very positive because they're trying to find out uh what else they could do how their customers are using them.

They trying to find out how customers are using may maybe their product in edge cases so that they can push this to marketing and do something about it. So the the emotional tone underlying the old interactions is very explorative, very interested and very positive, which is different to what's often happening in customer support. And what here happens is then that customer support says, oh, product, you are always building the things for sunny day customers for really happy customers. And product says, oh, but it's only 0.2% of whatever of our customers who actually complain. So you are only talking about a tiny minority that's not really relevant to us. And then we have the first disconnect that even though we both call it customers. We're actually thinking about very different mindsets about what that means. So that's our first topic, customers.

So the next one is feature requests and feature requests can come in very different ways. Sometimes, um, companies have like a board where you can put the feature requests. Sometimes they talk a lot with their uh customers to find new feature requests and very often support also passes feature requests uh to product. So feature requests, sometimes they also come bundled with uh bug reports, feature requests for support. Basically being uh how can we solve this customer's product for the future? So support when it comes to uh feature requests, um actually has the kind of urgency to it because sales, for example, promised something and our customer support has the people in chat asking for when this this feature is actually coming out or marketing didn't get the question right out.

So when the custom, when feature requests end in support, it adds an added layer of stress because usually I can't um solve this problem. Now, as a customer support representative for product on the other side, for product feature requests are opportunities. They are amazing.

They can be the next big thing. They can tell us what we need to build next. They are basically um a tiny hole into the future about how the product could look like at some point. And here's the thing at some point because uh when we look at time, time is very, very different in customer support compared to product time in customer support is now support wants time to basically stop so that they can solve anything and get an answer right in this moment out to the customer ASAP in support means yesterday.

So if somebody tells you, you are in support and somebody tells you, yeah, I'll get back to you ASAP. They expect that you get back to them today because they have the customer on chat and they can manage expectations, but they're going to manage this expectation as if so if a customer support person asks product, hey, when do you think will this bug be solved or when will this to request come out?

And, and, and uh product says? Oh yeah, I guess in about like two weeks or so then customer support will tell the customer yeah, two weeks. Well, if they are very experienced, they're going to say next month. Uh but they kind of take it as if, if you tell them two weeks, they're going to trust that it's too weak. And that's the other very big friction that often comes on comes up with time because for customer support, elapsed time is crucial. It's the time that is from now I get the request to, then I have it solved. And very often this is also a KP I for many customer support teams. How many first reply solves can I actually get out there. So for the product team though time is based on due dates, time is based on cycles that can be two weeks, six weeks, two months or even six months, like depending on what their development cycle is. So when a product person tells you ASAP, they don't mean tomorrow, they don't mean today, they mean within the next action cycle, which may well be in three months from now. So it may take a long, long time for this to happen. So of course, when these two teams talk with each other, there is a lot of friction around. Uh I need this today and oh, I would love to, to develop this for you um in the next three months. So how can we basically bring these two closer together?

Not that they talk about the same thing, but that they actually understand what they're talking about. So how do we act on this difference on customers? Something very positive customer, something, someone who comes in super stressed product is something that they never do what we need them to do or support somebody who's always nagging that we need to do this s things quicker and no, never appreciate what we're actually doing here.

And how can we uh bring these two together so that they work together? Because we cannot uh forget that customer support has a lot of very good insights for product, but these insights will only flow from one part to the other. If we actually have good relationships and this is the crux in this situation, you need to create first awareness that there's a difference in how you view the world. Basically, one is having 11 has a green lens and the other one has a blue lens and they kind of see the same but they see it in different shades and you need to create relationships because as humans, we relate to other humans. So you can do processes help and you can have as many processes as you as you want. If the people that are using these processes are kind of um unhappy with each other or like go into these processes already like bristling with, oh, they never do what we need anyway, then all these processes won't help you. So first things first as a team, if you're on a product team or if you're on a uh customer support team, write down how you view the customer, not how you view it in terms of company values and what we wish to happen.

No, like how do you view your customers in day to day? And that means if you're a fash fashion brand, you are going to view your customer different than if you are a payment provider because the stress level and payment provider like I'm not getting paid, I don't have access to my money is a lot um higher than I bought this t-shirt in the wrong size.

So like how does your customer support team uh relate to the customers? And then also how does your product team relate to the customers? Does your product team regularly talk to customers or is this like an entity that's out there, write down and make this information accessible to the other team? So that the other team also now knows how you view the customer and that and how you view time, how long is your uh action cycle? And how do you view feature requests in this um hold a how we work session. And you can actually, especially if you're in a remote environment, you can record that session and make it accessible to the other team. So that you know how the other team is working include your KPIS. If as a support team, one of your KPIS is first reply time, the product team needs to know that because they might not be able to speed up the development cycle for you, but they definitely can help you understand how long ASAP actually means for them. So just having this understanding can take a lot of tension um out of the the conversation between these two teams and then see if you can update your processes so that they actually um reflect this reality.

For example, the product team will answer customer support within X hours, doesn't mean that they're going to solve everything in X hours, but they're going to let them. If customer support has a question, they will get some kind of answer even if it's around expectations within, I don't know, five hours or five days, but like make it, make it a number on the flip side. The customer support team will and this is examples. You can make up what, what uh out of that, what works for your own company. Uh The customer support team will create regular information about what are the most requested information. What is the most requested topics, et cetera for the product team and the product team, for example, will create the documentation that is needed when a new uh new feature is um uh is released or the product team will give the the customer support team access. I don't know, three days, one week in advance so that they can create the the documentation like define all of these things. You don't want to just wing it because as you scale winging, it doesn't really scale very well. At some point, you need to define who is responsible for what so these are and then this is the final one and like really, really take this to heart.

I really want you to do this, set up regular calls between the customer support team and the product team and you don't need to get the entire team together, but make sure that the decision makers and the team managers regularly talk to each other. And if you can create um like regular meetings where not random people basically from the product team, meet random new people from the customer support team so that they can just talk for half an hour or an hour about how their work goes so that they can get to know each other on a human level that will help you so much with taking tension out of the conversations because it's very easy to be angry at an avatar on Slack.

It's very different if you know that this is uh Maria Luisa who is the product marketing manager and who also has a cat that has the same color as your cat. Like if you can put some humanity in this conversation, um it's so much easier to then uh move it from a human connection to the work connection and work with each other instead of against each other. So create processes that work for both, both parts of the aisle. Relationships are important, especially across departments and nurture these relationships both on a leadership level and also as at an individual contributor level. So that's uh my talk for today. I hope you uh you got something out of it. Let me just check if there's some questions in here because we still have three minutes left. Uh Okay, it resonated with you people. That's perfect. So now go back and tell your product lead or your custom support team and said you have to do that and, and then implement this because like I have seen really, really big changes in, in companies as soon as customer support and product actually started talking to each other and stopped screaming at each other.

And sometimes you may need a meet up where you put people into the same room for dinner or for lunch and have them, have them have a cocktail to for together or whatever and have them talk about things that they love about jobs, things that they find challenging about their jobs and things that they love in life in general and see if you can create those connections um across the different teams.

And if you then do the same with sales and mar and marketing and just make sure that there is this spider web of human interconnections across departments. That's the way you can avoid silos and one final team lead recommendation, you'll have introverts on your team, you'll have extroverts on your team and you'll have a special subtype of extroverts on your team. I call them connectors. They kind of know everyone, they always know everything that's going on. Um encourage your connectors to continue connecting to kind of feedback to you. What's the vibe in the different teams and use them to put people in touch that they think might get along with each other, not necessarily might be useful to each other in the company. That's like that's the long game you're planning, but just that they are interested in each other and might love to um to share with uh with uh things with each other. Do you have a priority system or something that you use across the teams to help define the level of importance across both teams? There are lots of, lots of ideas on how you can do this uh in terms of how many customers are affected, et cetera, et cetera.

The most important thing here is get the product team and the customer support team together and make sure they understand the priority system because one of the big problems is very often that product has a priority system which usually is based on um how many customers, how much MRR or how much A RR is actually um impacted.

And customer support has never heard of MRR or a RR, which is the uh recurring revenue and doesn't know that this actually is a thing that influences they just look at who's screaming the most. So just by bringing people together and saying, hey, this is actually the priority that we use in product. Does it make sense to you or not? Then we can do this? And wow, this is what amazing that this went fast. Connect with me on linkedin. Actually, I think I had a slide somewhere for this as well. And of course now, oh, there we go. This is where you can find me volunteer turn.com and on linkedin as valid the order or just search for my name because until my daughter comes of age, I'm the only volunteer turn on the internet. Have a great day. Everyone.