As a product manager, one of the challenge is to be aware of your users’ needs, and to collect feedback. One doesn’t always have the time or skills to run proper user testing sessions, and then analyse the data. A simple thing that many companies have is a customer support team. It is an asset that is often under estimated in product management.
Build a relationship with the CS team
In companies, the CS team is the team in touch with users. They gather the feedback, both feature requests and issues to fix. They will often ask product managers for some new features, sometimes quite a lot. Then, being a PM is about taking their feedback into account and managing their expectations.
In order to do so, include them in your routine. One easy thing to do is setting up a weekly or biweekly session with the head of customer support. That will allow them to keep you up to date with upcoming issues, or suggestions. On the other side, you will be able to present upcoming projects or insights you have.
It will also push the CS team to centralise their requests through one person, and thus only push further the ones that are really valuable.
Don’t hesitate to discuss your roadmap, to present how projects succeed to each other and where their requests could fit or not. Don’t forget to mention trade-offs. The more transparent you are, the less pressure you’ll get from them to get things through.
Overall, the important piece is to get used to include the CS team and have an open conversation with them, rather than consulting them or being consulted on demand.
Gather CS data
A lot of the quantitative data is very insightful. For example, a pie chart showing the split between the main contact reasons is great. Such a categorisation can further be applied to direct contacts (phone, email, chats), or even to reviews you get on app stores. You can then break down each subject with the CS team. For example the parent subject “Transaction status” could be broken down into “When will the transaction be done”, “I don’t understand the status of my transaction”, “My transaction is delayed”, etc. Knowing the split between high level categories, and their sub-categories is helpful.
Every time you release a feature that impacts the user experience heavily, another good metric to track is the contact rate. If users encounter issues, they will contact the team to get help. If you want to see the impact of your feature even more clearly, try to look at the contact rate specifically for the topic of your feature. For example if you are adding some promotion, you can filter out anything unrelated to prices or to the business model.
Tip: when looking at contact rates, look the number of tickets in comparison to users activity. Don’t forget to divide it by the number of active users, or by the number of purchases (whichever is the most relevant).
Knowing how many tickets or requests can be solved with one-answer-only is another good metric. Those tickets are usually easy to close. It can be from the CS team itself through a macro generating answers, by adding some self-service in the product, or through a bot that would pick up the information the user needs or process the request internally, as a CS agent would do. Then prioritise. If it is easy to group answers using a macro, but the automation is heavy, maybe the work on such a feature can be delayed for now? Such data informs well on projects’ impact.
It is great to have all this data to identify issues, but you will need to follow up with the CS to adjust with qualitative data, and go beyond.
Include the team in your process
A lot of the ceremonies a PM runs would benefit from the CS team input.
A good session to invite them to is your sprint demo, they will give very good recommendations for your next iterations. You can even go beyond, and present them wireframes or designs before you bring them to engineers. They will be able to confirm whether the experience matches the need, and might raise important edge cases.
In a past experience, we had some monthly presentation to the C-levels about our progress. We were talking about issues identified, the solutions implemented, and impact on KPIs. We ended up including the CS team as presenters for some parts of the session. Having them was consolidating our message on user satisfaction, and united us a lot. We were feeling more like squad with one goal, rather than multiple teams working in parallel to try and make it happen.
For example, when brainstorming a problem, to try to find a solution within a range of many solutions, definitely include the CS team. They will add some options that might be very relevant. But beyond that, they will help you identify the solutions that match your users’ mind set.
Before we had proper quantitative data to prioritise everything, I went through this process:
- Give your group a problem. Good to have a bit of CS, design, product, 1–2 engineers in there. Ask them to breakdown your problem into smaller chunks.
- For each chunk, ask them to brainstorm potential solutions
- Last round is voting. Give them (for example) 2 votes each, and make them vote on the problem chunk that is the most important, then 2 votes each again for solutions.
Such an exercise will trigger very good cross team conversations. We ended up with an ordered list of action items, quite driven by the CS insights. When the quantitative data came up, it confirmed the prioritisation we had from the brainstorming. You can trust your CS team.
To summarise, working with the CS team can only bring you some more awareness on your users. Don’t take their requests as a burden, include them in your work routine as much as possible. They will understand your constraints, you will save a huge amount of time, and it will make your reasoning more solid.