“What does the ‘voice of the customer’ mean in business?” you might ask.
Voice of the customer programs are methods created by companies to best understand the experience and needs of their customer base through feedback.
In October 2021, Easyship’s Head of Customer Success, Andrea Greco, outlined his best practices for implementing an effective voice of the customer program.
Here, Andrea outlined the best ways to manifest these strategies in your day-to-day work. 👇
Q: What processes can be implemented to help a product team better understand the customer’s request?
A: It’s important to have a process in place that allows the requester – whether that’s the Customer Success Manager or the customer themself – access to a template, which gives the product team what they need to understand the feature in question.
My first bit of advice is to ensure transparency, above all. In your feedback form, I would suggest you include fields to capture the precise information about what the product team needs to implement the right changes.
These fields are critical for the product team to understand the feature in question correctly, avoiding any unnecessary back and forth.
Secondly, ensure you have regular meetings with the product team - on a monthly to quarterly basis - to review the features.
Sometimes a product team doesn’t always fully understand every feature request, or they push back in some capacity.
In my experience, some product teams can be left unconvinced by customer requests, partly due to having their vision and strategy. It helps to have regular meetings with them to review the features and help them understand their significant role in this process.
Transparency plays a vital role to help customers stay updated, and helps the customer success team know the progress made by the product team.
Q: Have you experienced a situation where the product team feels reluctant to be transparent with the CS team regarding the feature updates?
A: I have. However, for the most part, this reluctance has been caused by busy workloads, and decisions to prioritize other major releases.
If you feel a member of your product team is reluctant to share updates, my suggestion would be this: take a step back and empathize with them. Try to understand what's going on, maybe they feel the feature isn't important.
One potential reason for this miscommunication is the medium of the feature request. Ask yourself whether the medium of communication is reflective of the integrity of the task.
Are you reaching out to them with this request through a transparent, finely-tuned process, or have you notified them with a rushed, brief message on Slack?
Let’s be honest, if somebody requested something important and urgent from you via Slack, wouldn’t you be irked too? The gravity of the request must follow the appropriate medium. While it may be frustrating from your perspective, it’s important to put yourself in their shoes.
Like you, they too will have a roadmap that they adhere to, and without the proper project management processes in place, you’ll inevitably have some fractious moments between teams. This is why cohesive, transparent cross-departmental collaboration is crucial.
In general, product teams prefer to have requests that are planned, so my advice is to implement a defined process and stick to the process like superglue!
In my experience, if you share a monthly meeting to discuss feedback, and consider what to prioritize in the future product-customer success roadmap, I don't think you're going to get a lot of pushback.
Q: Do you time surveys at particular points during the customer journey based on business milestones?
A: Normally, we try not to be too trigger-happy with surveys. Instead, we try to identify particular segments of clients. For instance, whenever we release a new feature, we have a population or a segment we think it's going to be interested in that feature.
We send surveys to collect feature requests from the customers who adopt a feature. If they don't have the feature, we want to understand whether they know it existed, or if they didn’t understand how the setup works. In essence, those are our two main angles for surveys.
Q: How often do you think CS should conduct product roadmap sessions with our clients?
A: I don't think a CSM should own the responsibility of hosting product roadmap sessions. Normally, the system collects feedback through ongoing interactions, either a QBR or 1:1 session.
Ordinarily, these sessions go a little something like this: you collect feedback, discuss the product and the client might complain about certain product features. When this happens, it’s vital to have a well-defined process that is easy for the team to log feedback and move on to the next thing.
However, supplying the CS team with a form that allows them to log the feedback whenever they have a call with a client, will put you in a better position to collect and action that feedback.
At Easyship, customer success doesn't own roadmap sessions with clients, but we are launching a product advisory board program. In a nutshell, it's a form of membership.
Every company will have a certain pool of customers who tend to be more active and forthcoming when suggesting new features. This product advisory board will reach out to those customers and ensure they become part of our decision-making process when it comes to defining features.
Q: Can customer success drive impact with a public roadmap?
A: Public roadmaps are tricky topics. For instance, there are great SaaS companies like HubSpot that don’t have a public product roadmap, but they do have a product roadmap blog.
External product roadmaps are great at creating transparency, but you need to have somebody whose job is to follow them closely. Otherwise, it can easily become a toxic environment where anybody can ask questions about anything they want.
Overall, I believe customer success can drive impact with a public roadmap. Since clients are always asking about feature releases, having a public roadmap would alleviate a lot of questions asked and force CS teams to be more proactive.
Effectively, public roadmaps aim to put the customer in the driver's seat, or they at least provide a greater level of transparency. I would urge caution when implementing public roadmaps, making sure you have someone to monitor it.
Q: How can voice of the customer programs tackle diversity, equity and inclusion best practices?
Often a company’s largest customer base is in the ‘home market’ and the foreign market - the customers in Asia - are considered a minority. Sometimes the APAC customer feedback is brushed aside or not addressed because the ROI doesn’t benefit the majority.
But how can we help our minority customers have their feedback put forward and adopted? Three words (or one, depending on your use of acronyms): return on investment (ROI).
You’ve got to remember: little drops of water make a mighty ocean. So, while smaller customers may be considered to be the minority, they shouldn’t be ignored.
In reality, the bigger the customers, the more complex and demanding the customization tends to be. Usually, if you have one client requesting a feature update or something, it will normally only apply to them, as opposed to small clients who tend to have use cases that apply to other clients.
But if you have a product roadmap you can identify clients who are interested in raising suggestions and log their requests. In effect, putting together say 5, 10, 15, or 20 smaller clients, you automatically have a stronger, more proportional argument than basing your decision on a feature request from one big client.
If you are to take away one point from this interview, it would be this: focus on the process of logging your request.
Put them on a board and make sure you know what your clients are interested in and quantify the ROI, the subscription, or whatever revenue target your company follows. Then you can quantify what is the expected ROI or how that feature would benefit a segment of our population of clients.
Psst.. Want some exclusive insights from SaaS experts? Why not become a FoSaaS member?