As a CSM, one of my core responsibilities is to be the voice of the customer (VoC), which has traditionally been: speak to customers, be their friends, hear what they have to say, and translate it into feedback that follows a cohesive story and makes sense for internal teams. However, in an industry that's becoming more and more product-led, focused on automations and optimizing for overall efficiency through things like AI, the status quo for CSMs will no longer be the process that I outlined above (outside of enterprise-level relationships, where their requests have much greater influence).
I like to refer to this change as a shift in the ratio of outbound vs inbound work for CSMs. With most PLG products, CSMs & AEs will mostly be outbound (+ warm outbound), but I will save that for a separate post.
CSMs have historically done a lot of inbound work that could honestly be replaced by better in-product UX or scalable public resources, like knowledge bases or videos. Product feedback is a huge one. Why do users need to sit with you on a live call to explain the feedback they have when it could have easily been done through a channel that provides them the ability to do it in the context of what they were working on at the time?
Of course, having direct relationships with users through interactions definitely helps. Soliciting feedback is hard. I get that. It can be hard to get users to actually speak up for what they want. Think about the last time you actually went out of your way to submit feedback to a product you use.
But why is it so hard? Well, because it's how it's always been done… It has been the tradition in the industry that if you don't have a CSM or AE as a customer/user, you have to go to a website/community, send an email to support, go on social media, or even call a number to accomplish the simple task of sharing what you think. This isn't only the case for B2B relationships, the same is true for B2C.
For example, I use a variety of SaaS products and have often found myself encountering issues or having suggestions for improvement while using the tool. My only options are typically to either navigate to a separate feedback or community page to submit my feedback or bug report, or submit a ticket to the support team if there weren't any paths for me to submit directly. However, this process can be time-consuming and often results in me forgetting about the issue altogether. There are too many obstacles and distractions between me and actually getting my feedback to the right people. That's why I believe that all SaaS products should have in-product feedback or bug submission functionalities. It just makes sense to allow users to submit feedback or bug reports right in the moment they encounter an issue or have an idea for improvement.
Let me show you some examples of what I mean from my Good-UX page. These are just a handful of the tools I use that very clearly provide easy keyboard shortcuts to submit product feedback directly within the product. No social media. No emails.
Ok, this is the last time I post a product’s feedback/bug submission options. Just making a point for my recent blog post 🙂
Another clean in-product bug/feedback submission. This will be the norm for most SaaS products.
Like in Arc, reporting bugs and requesting new features is easlily accessible. Well done Raycast 👏🏽.
Reporting bugs and giving feedback shouldn't be complicated. Every product should have a feedback & bug submission built into it. Well done Arc 👏🏽
Now, I know that some product folks out there would cringe at giving users the ability to submit tickets independently, so here’s Mr. GPT with a quick Pros & Cons table to unpack both sides 👇🏽
Pros | Cons |
Convenience: Users can easily submit feedback or report bugs without having to leave the product, which can improve the user experience and increase the likelihood of receiving feedback. | Development time: Implementing an in-product feedback or bug submission feature can take time and resources away from other development priorities. |
Contextual information: Feedback or bug reports submitted through the product can include contextual information such as user actions, device information, and error messages, which can help developers reproduce and fix issues more quickly. | Spam: In-product feedback or bug submission features may be vulnerable to spam or abuse, which can increase the workload for developers and decrease the quality of feedback. |
Prioritization: In-product feedback or bug submission features can help teams prioritize issues based on the number of reports, severity, and impact on user experience. | Security and privacy: Collecting user data through in-product feedback or bug submission features can raise security and privacy concerns. |
User engagement: Allowing users to submit feedback or report bugs in-product can increase engagement and foster a sense of community and collaboration between users and developers.
| Scalability: As the number of users and feedback submissions grows, it may become more challenging to manage and prioritize issues, which can lead to a backlog of unresolved issues and a decrease in user satisfaction. |
I personally don’t believe that the cons I provided are enough to warrant not implementing something like this, but it all depends on your product. It’s been really interesting to be able to follow Arc’s videos and “build in public” style product development where they expand on their decisions. I can’t seem to find it right now but I remember they posted something explaining how many feedback & bug tickets they received over a period of time, which was an insane number. It would be really cool to hear from them on how this funnel has worked for them.
That all being said, simply implementing this functionality won’t in and of itself give your product team the “customer obsessed” title, it still requires some structure about how you funnel the feedback and how it is sorted/addressed.
This suggestion I’m making is not all encompasing; providing other avenues for users to provide feedback is also great, like public documentation/community pages, Slack/Discord communities, and through social media.
Public Documentation
I’ve always found that API & Developer documentation has been extremely easy to navigate and understand. I feel like the gold standard is Mozilla’s MDN Web Docs. Another company that has a variety of different resource options is Webflow, their developer docs are nice too 🙂
Slack/Discord Communities
This has become a lot more popular and is an amazing way to create a low friction way for users to get involved with the community, ask questions, and submit feedback.
Social media
This one is probably one of the harder things to pull off. Most companies dream to have the kind of engaged community that companies like Notion have. It’s also much more common for developer tools to have an extremely engaged community. Some reasons being:
- Devs understand the realm of possibilities, they are less hesitant to give feedback
- They’re generally more technologically adept, so they know where and how to submit feedback
- They understand the value of feedback
These are all great, but it’s still weird how many massive SaaS tools don’t give users the immediate and obvious funnel to give PF & submit bugs. So don’t be weird, be cool and create a shortcut or a button that lets your users submit feedback easily. ✌🏼
Thank you for making it this far! Please give me feedback. Writing is hard.
Contact Me
shayanmz12@gmail.com