How to get your product and support teams to work together

Interview with Aistė Sobutienė, the customer support director at Vinted

Support Insights Community
Join a community of 2200+ customer-focused professionals and receive bi-weekly articles, podcasts, webinars, and more!
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Understand your customer’s problems and get actionable insights
See pricing

In today's interview we caught up with Aistė Sobutienė, customer support director at Vinted, to discuss the incredible process they've built to encourage active, two-way communication between their product and customer service teams.

Through an innovative three step communication model, which you'll hear all about today, the Vinted team have made easier to make sure feedback is constant, everyone feels heard, and better product and user experience's are built.

There's so often a communication gap between those two teams, both of which ultimately want the same thing.

In this episode, we hear a ton of best practices, tactics and techniques for bringing the teams together to provide the best customer experience possible.

P.s. If you like this episode, we recorded another one last week with Aistė tackling some common customer service myths.

No time to listen? Here are the highlights 👇

Why is there a communication gap between product and customer service teams

Question: On the product side, product people love customer insights and need them to build better products. However, support teams often filled unheard, sidelined and not listened to by product teams. Why is there this conflict?

Answer:  Well, the thing is, every manager knows that exchange of information is essential. Yet in practice, it's not that easy to ensure everyone's in the loop all the time. And I think part of the reason for that is that we, as managers or companies in general, we far too often rely on a common knowledge or expectation that people would just talk, you know, that they would share what they have to say, what's on their mind, what kind of feedback they've collected.

And, as a result, we don’t invest into actually building structures and tools and processes for that. While, perhaps, it's not that big of a deal when you have a company of like 10 to 20 people, because it's fair to expect that they will just talk to each other, when we go past that point and when companies grow...then failing to recognize that you need to invest into proper communication processes and structures, this is where we have this problem. And the problem grows if we don’t start working on that. 

And one more thing is that I find that many companies, including ourselves a while back, and probably still a little bit today, we struggle with the translation of feedback or the thoughts that we want to share into the language that the product teams can work with. 

And at the same time, many companies simply fail to recognize the potential of having their support people at the table and involved in building the product. 

So while these two problems exist and they're not thought of as connected, it’s difficult to find a solution.

How Vinted closed the knowledge gap between product and customer service teams

Question: How have you approached this problem at Vinted?

Answer: We went through a lot of trial and error, but eventually where we landed is that we realized that in order to solve this communication gap and to make our company successful, we have to get our heads together with the product teams, to co-create a process and this tool, and to make sure that this communication structure that we're building, it takes into account both teams, the product team and the CS team. 

product knowledge customer service


So we spent months iterating and the process is still ongoing, but after all this talking, I believe we finally managed to get down to two simple principles that basically defined what we wanted to build

And those two principles were involvement and feedback.

And once we decided that these two words define the kind of partnership and collaboration that both teams want to have, it got a lot easier to move on to the actual steps of the communication process. 

To go a bit further into detail, we developed a three phase process that basically revolves around the actual building of the product:

  1. Pre-launch
  2. Launch
  3. Post-launch 

Each of them have different steps that we take to make sure that the communication is flowing. 

Question: Oh wow, so you embed into the typical stages of the product development process. Were your product team aware of all the great data and insights available in customer support that they weren’t using?

Answer:

Oh, yeah. I have a good example to describe the situation that we were in, and sadly I'm pretty sure that there are a lot of companies at this precise moment who are dealing with the exact same thing.

It would often happen that we get a ticket from our user (customer) and then they describe a problem that they're having. Then, for a while we're over there guessing if it's a bug or a feature, so we go to our product teams and they would be like, “Yes, a feature. We've had it for a while now.” When then have this back and forth conversation that happens frequently, and those conversations reveal the pains of a lack of communication. 

So I wouldn't say that we have to do any convincing of our product team. I think what we really had to do was reveal the magnitude and the pains of the teams not talking and how it affected team morale because you know, the customer service teams felt not listened to and product teams felt attacked for no reason. So that was a good enough reason for us to take a look into this. 

The details of Vinted's three-phase communication model

Question: So, what does the three-phase communication model actually look like in practice?

Answer: 

Phase 1: Pre-launch

At Vinted we believe in open communication. Therefore we have this internal communication platform that serves both as a means to share information and as a knowledge-base for reference. So we made sure that all teams that were planning a new release posted a comprehensive summary of what they were going to launch and when, so that the CS, and every other team for that matter, could both ask questions and share early feedback using all the insights we’ve gained from working with our users day to day. 

The next pre-launch step we included into our routine was a DEMO session with the developing team. The user experience is presented at this point. Both teams have different insights about what our community wants and expects. Putting them together raises awareness and another feedback round helps ensure the UX is flawless. This way, not only were we ready to assist our users, but we made sure that all the assumptions are vetted and the need for re-work is minimised.

And finally, we make sure we test out the full feature flow ourselves before the users do. It seems obvious that support agents have to know their product inside and out but more often than not we tend to rely only on the information of how it SHOULD work rather than how it does and end up guessing if that’s a bug or a feature we have at hand. Operating with real information eliminated the uncertainty and made us more confident. 

Phase 2: Launch

We keep the communication flowing after releasing a feature to our users. No matter the amount of preparation, there are always new questions to answer and new problems to solve, so we turn to our product teams again, but we do so in a way that allows everyone involved to make the best-weighed decisions - we use data. How many users, what sort of problem, what are potential risks and ways to mitigate them. We bring this information to the table because a commonly understood language gets us to where we want to be a lot faster. 

We also constantly update the rest of the organisation with how our community is taking the changes and what their feedback is. By doing so, we make sure everyone has access to the freshest insights for future projects and course-correcting actions. 

Phase 3: Post-launch—closing the feedback loop

Cooperation doesn’t end after the feature is launched. We do a post mortem analysis together with the product guys to share different insights that give a great overview of the success of the launch. 

Closing the feedback loop is a very important step, that's where we get to actually look back and reflect on not only the final result that we brought to our users, but the process as well. So that helps us both deliver better products and that also helps update the communication flow and collaboration process.

The product team usually looks into metrics, conversions and other numerics while we compliment the big picture with the feelings and impressions from our community.  Together we make one strong team with confident decisions and a higher chance for success.

The benefits of improving this process

Question: What tangible benefits have you measured?

Answer: I have several very specific examples to share. So the ‘time to ship’ has been definitely affected in a positive way by us creating this communication structure.

Previously, it was rather often that we would have to remake certain parts of the feature of the launch after it's been launched to our users already, which of course extends the overall time to ship. So with this process in place, it has been reduced by a significant amount.

And the amount of tickets, for example, or whatever you have to work with (voice, live chat, etc), the amount of complaints, the amount of inquiries from users, they've been affected positively as well. 

Because they’ve been through a process with our customer service team, and more user testing, our features are better and more self-explanatory. So there’s less need for customers to contact the support team with questions. 

We always aim to build features that do not require opening up an FAQ page on how it works, but you just know how it works from the flow. So we always try to use our insights to facilitate this way of doing things.

Watch the Episode

In the next 5 years, customer experience is 45% of companies top priority. Investing in CX initiatives has the potential to double your revenue within 36 months. 86% of buyers are willing to pay more for a great customer experience.
  • In the next 5 years, customer experience is 45% of companies top priority.
  • Investing in CX initiatives has the potential to double your revenue within 36 months.
  • 86% of buyers are willing to pay more for a great customer experience.
Source: CX statistics

Try SentiSum today

Democratise voice of the customer insights across your company

Free 2-week trial

How to get your product and support teams to work together

Interview with Aistė Sobutienė, the customer support director at Vinted
Interview with Aistė Sobutienė, the customer support director at Vinted
Join a community of 2139+ customer-focused professionals and receive bi-weekly articles, podcasts, webinars, and more!
← Browse other podcasts

In today's interview we caught up with Aistė Sobutienė, customer support director at Vinted, to discuss the incredible process they've built to encourage active, two-way communication between their product and customer service teams.

Through an innovative three step communication model, which you'll hear all about today, the Vinted team have made easier to make sure feedback is constant, everyone feels heard, and better product and user experience's are built.

There's so often a communication gap between those two teams, both of which ultimately want the same thing.

In this episode, we hear a ton of best practices, tactics and techniques for bringing the teams together to provide the best customer experience possible.

P.s. If you like this episode, we recorded another one last week with Aistė tackling some common customer service myths.

No time to listen? Here are the highlights 👇

Why is there a communication gap between product and customer service teams

Question: On the product side, product people love customer insights and need them to build better products. However, support teams often filled unheard, sidelined and not listened to by product teams. Why is there this conflict?

Answer:  Well, the thing is, every manager knows that exchange of information is essential. Yet in practice, it's not that easy to ensure everyone's in the loop all the time. And I think part of the reason for that is that we, as managers or companies in general, we far too often rely on a common knowledge or expectation that people would just talk, you know, that they would share what they have to say, what's on their mind, what kind of feedback they've collected.

And, as a result, we don’t invest into actually building structures and tools and processes for that. While, perhaps, it's not that big of a deal when you have a company of like 10 to 20 people, because it's fair to expect that they will just talk to each other, when we go past that point and when companies grow...then failing to recognize that you need to invest into proper communication processes and structures, this is where we have this problem. And the problem grows if we don’t start working on that. 

And one more thing is that I find that many companies, including ourselves a while back, and probably still a little bit today, we struggle with the translation of feedback or the thoughts that we want to share into the language that the product teams can work with. 

And at the same time, many companies simply fail to recognize the potential of having their support people at the table and involved in building the product. 

So while these two problems exist and they're not thought of as connected, it’s difficult to find a solution.

How Vinted closed the knowledge gap between product and customer service teams

Question: How have you approached this problem at Vinted?

Answer: We went through a lot of trial and error, but eventually where we landed is that we realized that in order to solve this communication gap and to make our company successful, we have to get our heads together with the product teams, to co-create a process and this tool, and to make sure that this communication structure that we're building, it takes into account both teams, the product team and the CS team. 

product knowledge customer service


So we spent months iterating and the process is still ongoing, but after all this talking, I believe we finally managed to get down to two simple principles that basically defined what we wanted to build

And those two principles were involvement and feedback.

And once we decided that these two words define the kind of partnership and collaboration that both teams want to have, it got a lot easier to move on to the actual steps of the communication process. 

To go a bit further into detail, we developed a three phase process that basically revolves around the actual building of the product:

  1. Pre-launch
  2. Launch
  3. Post-launch 

Each of them have different steps that we take to make sure that the communication is flowing. 

Question: Oh wow, so you embed into the typical stages of the product development process. Were your product team aware of all the great data and insights available in customer support that they weren’t using?

Answer:

Oh, yeah. I have a good example to describe the situation that we were in, and sadly I'm pretty sure that there are a lot of companies at this precise moment who are dealing with the exact same thing.

It would often happen that we get a ticket from our user (customer) and then they describe a problem that they're having. Then, for a while we're over there guessing if it's a bug or a feature, so we go to our product teams and they would be like, “Yes, a feature. We've had it for a while now.” When then have this back and forth conversation that happens frequently, and those conversations reveal the pains of a lack of communication. 

So I wouldn't say that we have to do any convincing of our product team. I think what we really had to do was reveal the magnitude and the pains of the teams not talking and how it affected team morale because you know, the customer service teams felt not listened to and product teams felt attacked for no reason. So that was a good enough reason for us to take a look into this. 

The details of Vinted's three-phase communication model

Question: So, what does the three-phase communication model actually look like in practice?

Answer: 

Phase 1: Pre-launch

At Vinted we believe in open communication. Therefore we have this internal communication platform that serves both as a means to share information and as a knowledge-base for reference. So we made sure that all teams that were planning a new release posted a comprehensive summary of what they were going to launch and when, so that the CS, and every other team for that matter, could both ask questions and share early feedback using all the insights we’ve gained from working with our users day to day. 

The next pre-launch step we included into our routine was a DEMO session with the developing team. The user experience is presented at this point. Both teams have different insights about what our community wants and expects. Putting them together raises awareness and another feedback round helps ensure the UX is flawless. This way, not only were we ready to assist our users, but we made sure that all the assumptions are vetted and the need for re-work is minimised.

And finally, we make sure we test out the full feature flow ourselves before the users do. It seems obvious that support agents have to know their product inside and out but more often than not we tend to rely only on the information of how it SHOULD work rather than how it does and end up guessing if that’s a bug or a feature we have at hand. Operating with real information eliminated the uncertainty and made us more confident. 

Phase 2: Launch

We keep the communication flowing after releasing a feature to our users. No matter the amount of preparation, there are always new questions to answer and new problems to solve, so we turn to our product teams again, but we do so in a way that allows everyone involved to make the best-weighed decisions - we use data. How many users, what sort of problem, what are potential risks and ways to mitigate them. We bring this information to the table because a commonly understood language gets us to where we want to be a lot faster. 

We also constantly update the rest of the organisation with how our community is taking the changes and what their feedback is. By doing so, we make sure everyone has access to the freshest insights for future projects and course-correcting actions. 

Phase 3: Post-launch—closing the feedback loop

Cooperation doesn’t end after the feature is launched. We do a post mortem analysis together with the product guys to share different insights that give a great overview of the success of the launch. 

Closing the feedback loop is a very important step, that's where we get to actually look back and reflect on not only the final result that we brought to our users, but the process as well. So that helps us both deliver better products and that also helps update the communication flow and collaboration process.

The product team usually looks into metrics, conversions and other numerics while we compliment the big picture with the feelings and impressions from our community.  Together we make one strong team with confident decisions and a higher chance for success.

The benefits of improving this process

Question: What tangible benefits have you measured?

Answer: I have several very specific examples to share. So the ‘time to ship’ has been definitely affected in a positive way by us creating this communication structure.

Previously, it was rather often that we would have to remake certain parts of the feature of the launch after it's been launched to our users already, which of course extends the overall time to ship. So with this process in place, it has been reduced by a significant amount.

And the amount of tickets, for example, or whatever you have to work with (voice, live chat, etc), the amount of complaints, the amount of inquiries from users, they've been affected positively as well. 

Because they’ve been through a process with our customer service team, and more user testing, our features are better and more self-explanatory. So there’s less need for customers to contact the support team with questions. 

We always aim to build features that do not require opening up an FAQ page on how it works, but you just know how it works from the flow. So we always try to use our insights to facilitate this way of doing things.

AI for customer service ebook

Watch the episode

Join a community of 2139+ customer-focused professionals and receive bi-weekly articles, podcasts, webinars, and more!