This week, Nadine Spenser and I organised the first meet-up in Barcelona focused on Customer Voice and Insights. We gathered professionals from Customer Success, Product and Customer Experience from some of the best known start-ups and scale-ups in Barcelona.
I always go to these events thinking I will find a magical solution for our challenges, that for sure someone else figured out the optimal way to improve a process or metric. Every single time, I leave realising most companies in the industry share similar problems. And that’s a better outcome. Although challenges might be similar, each company is different, and the magical solution for one will probably not work for us. I find it’s much better to learn from others’ experiments, what worked and what didn’t, so we can pick up different learnings and build our own solution.
Over the past five years at Typeform, I led the team that defined the way we gathered and shared customer feedback with Product and Marketing teams. In a constant need to iterate and improve the process, I took every opportunity I had to connect with other professionals in the industry, to share learnings and best practices, so we could keep adapting and evolving our Voice of the Customer Program (VoC). In this post, I will explain three of the processes that best worked for us:
UNDERSTAND PRODUCT PRIORITISATION PROCESS
As a software company, from the beginning we identified Product and the Leadership teams as the main stakeholders for the Voice of the Customer Report. We wanted to influence the Product roadmap, by giving voice to our customers in the prioritisation process, so we needed to understand it. How did they decide the features to work on? The bugs to improve? What data and insights did they take into account? How did they perform research? Only when we understood their process we were able to adapt our report to their needs, in a format that was useful, clear and actionable.
SHOW TRENDS, NOT ISOLATED DATA
Before we started an official VoC Program, we were sharing customers’ feedback in the weekly company all-hands. Mainly based on Support tickets, we highlighted frequent bugs, the most requested features and common usability issues. We later launched the Churn and NPS surveys and started sharing what customers were saying along with the score. Since we were showing one report at a time, the common reaction from the Product team was “it’s a good suggestion, but we can’t prioritise based on the request of 40 customers, when we have 20k”. As much as we wanted to satisfy customers’ needs, they were right.
We started looking at different ways to analyse the data, how could we make more sense out of it, in a way that was useful for Product. That’s how the idea for the VoC Report emerged. Although it was true that only 40 customers were requesting that feature, it was also true that we had 20 detractors because of it and, worse, 15 customers had churned for the same reason. When we started combining data from multiple sources, we were able to show trends across the customer journey, from Sales calls to Support tickets, NPS and Churn survey submissions, even calls our Account Management team was having with their customers.
BRING PRODUCT AND CUSTOMER SUCCESS TOGETHER
For the first couple of years, the VoC was mainly a presentation we were giving every quarter to the entire company. While we were able to have some influence in the Product roadmap, we started to understand most decisions where happening daily or weekly, not quarterly. Of course, big releases were planned ahead, but small improvements were often prioritised during Sprint meetings and even daily stand-ups. If no one from Customer Success (CS) was there to give front-line data, we were missing the opportunity to help highlight which improvement could have the biggest impact on customers, not to mention the need to communicate these changes, internally and with customers.
It became even more clear we needed to change the process when we stared working on the final stages of the second version of our product. For a few months, all stakeholders were meeting daily to decide what to include and what to take out of the scope, what on-boarding was needed, how would the communication strategy look like. By having a representative of our CS team in those meetings, we could not only make sure there was a constant flow of information between Product and Customer Success, but we could also provide CS data to inform decisions in the moment these were being made.
From that moment on, we made the role official and 4 members of the Customer Success team became what we called CS Ambassadors. Their mission was to be an active voice in Product Roadmaps, representing customers needs. They attended Sprint Planning, had regular catchups with Product Managers and for at least two days a week would actually sit together with their designed Product team.
It’s frequent to see an Us vs Them dynamic between Product and Customer facing teams. I was certainly guilty of it. That’s why we understood early on it was important to build relationships with Product Managers and Engineers. We don’t have to be friends, but simple gestures as having coffee or lunch together, having real interest in each other problems and challenges and even small talk about family and holidays go a long way in building empathy and rapport. Once this foundational human connection is established, it’s so much easier to understand each other’s point of view, help and ask for help, and have a bigger impact in the company and customers.
If you would like to know more about how we collected, analysed and shared customer feedback in the early days at Typeform, there are three resources available: