As announced last today, I’ll take on the other side of the relationship within the product team and talk about the collaboration between the CS team and the Product Manager and, more specifically, the fundamental part of the team working on planning and implementing product changes. Enjoy your reading!
The role of Customer Success in the product development process + suggestions for need recognition experiments
The most important task of the CS team in creating new products or improving existing ones is to advocate for the customer’s interests by making sure that their opinion (VoC — Voice of the Customer) is heard. The CSM works with customers and should understand their needs, which means being the person on the project team who provides vital information on how a feature will address a business need. If a product, or functionality, addresses the needs of the customers or future audience, then it should not be created at all. How is the CSM supposed to gather this feedback? I have a few suggestions below, but there is way much more to exceed this topic.
Interview the customer
The simplest, quickest and easiest option. All you have to do is sit down with the customer and talk with a focus on getting information about his tasks, problems, what additional benefits he would like to achieve and whether he is willing to pay the additional costs. I strongly recommend writing a script for such an interview so that all answers can be grouped for later analysis. While the Product Manager or CSM can conduct the interview itself, it will often be up to the CS team to get people for interviews (protip: it is good practice to build a database of people willing to participate in the survey for future reference). Unfortunately, if something is quick, easy and straightforward, it also provides little value. In the case of interviews, we may find valuable feedback right away, but the vast majority of proposals will require further work by the team. We can gain general information through surveys, but we must be sure about future customer behaviour. Henry Ford once said
If I had asked customers at the beginning of my career as an entrepreneur what they wanted, they would have all agreed: we want faster horses. So I didn’t ask them.
While I don’t recommend not asking customers, remember that some of their comments may be misleading.
A day in the life
A second suggestion that needs to be more expensive but gives much more valuable data is to spend one day with the customer and see how he uses the product. Organising such an experiment requires preparation, but the opportunity to perform an ethnographic analysis in the workplace with the user is often a source of high-value feedback. Notably, the person who conducts the study should observe behaviour rather than teach the customer. Ideally, she should collect on a sheet all the activities performed and her observations while performing them. Before completing the experiment, you and your SD team can see what are the most commonly reported errors so that you can target your observations.
Product analytics analysis
This is a broad topic and wants to stay within bounds. The first two experiments focused on so-called zero-party data, while analytics uses first-party data. A brief description of what the differences are
0-party data: Made available to the company by the consumer.
1st-party data: Collected by the company as a result of interactions with the consumer.
2nd-party data: First-party data is made available to another company as part of a contract.
3rd-party data: Aggregated data from various sources.
You can read more here
A whole host of tools can be used for product analytics, the most recognisable being Google Analytics. Not about tools, however, but about what you can gain from product analytics. Mainly it will be customer behavioural trends in our application or the study of whether a new feature is in demand (for this, you can use, for example, 404 Tests, Feature Pod or Social Media advertising).
You may wonder where the CS team is in all this. Well, everywhere! By preparing and organising people for testing, participating in experiments through later analysis and creating proposals for changes, the CS team not only should but is crucial to control whether the changes will apply to users.
You can read more about the experiments mentioned and others in the book “Testing Business Ideas. A Library of Experimental Techniques” by David J. Bland and Alexander Osterwalder.
SD + CS + PM
Last week you knew about the collaboration between the Service Desk and CS teams, and today I talked about how Customer Success can work with the Product Manager, so it’s time to put it together.
The most apparent task at the interface of all three teams is to analyse the bugs that the SD team logs for later analysis if any of these bugs or issues lend themselves to something other than the idea of new functionality.
The SD team is also involved in implementing products, so it must have a good idea of what is implemented, what is being worked on and what will not be implemented shortly so that the need to involve others can respond efficiently to users.
Finally, both the CS and SD teams are, in a way, clients of the product teams, so they should take an active part in acceptance testing (UAT) to give the green light to the “product guys” to add functionality to the package, which will be deployed to customers. We wouldn’t want the customer to get changes that not only don’t solve their existing problem but generate a completely new one ;)
What to pay attention to and what to avoid
First of all, communication. It may be trite, but in my experience, it’s the main factor behind the success or failure of products or changes, especially in distributed teams working in different time zones. Here are some suggestions you can use with your teams.
Hold periodic meetings to stay on track and have a forum to establish and exchange ideas
In addition to using email, support yourself with instant messaging tools such as Slack or MS Teams for conversations and working on shared files. Office 365 or GSuite, with its collaborative work capabilities, will also work well. If you can’t or don’t want to use cloud solutions, try implementing a versioning system such as CVS or SVN to eliminate the possibility of errors resulting from working on the same thing but in multiple files simultaneously.
Collect submissions in one system to have a consistent base of what was submitted and the result. Jira, Azure Dev Ops or AHA will work great for this!
Don’t limit yourself to just your job. Taking care of customer success has to be a holistic process. Hence, if you don’t have a default assigned responsible person, then set some rules so that submissions can be noticed in the flurry of other responsibilities.
Don’t be afraid to say if an idea goes unaddressed. Customers may report problems that affect only them, and you will need more time to commit resources to change that. A good CSM knows when to communicate a nuisance to the product team, but he also knows when to tell the customer that a particular problem will not be addressed anytime soon.
Always gather as much as possible about a requirement or problem from the customer. Feedback is only better for a Product Manager than feedback that is one sentence without information on why the user needs a change and what he will gain from it. Without that, sooner or later, you or someone from the product team will have to go back to the customer to figure it out.
That would be it. Through both articles, you will better understand the collaboration within the team that creates the product and how different roles address customer success. What does this look like for you, and do you have any individual tasks from the CS team? Please share it in the comments!
Comments