Founder notes on customer feedback systems:
(Featuring founders from: Notejoy, Typeform, VideoAsk, ProdPad, EnjoyHQ, Intercom, and Geckoboard. And ideas such as: “feedback rivers,” Slack communities, and open roadmaps)
1: Notejoy’s founder and CEO, Sachin Rekhi on a Slack-based “feedback river,” which includes customer comments from NPS surveys, cancellations, feature requests, an app-wide ‘feedback’ button, and exact search queries from their help center (source):
The way we’ve implemented Notejoy’s feedback river is actually as a Slack channel called #feedback. And this is a feed that anyone can look at, at any given point and get an aggregated signal on various sources of feedback…
Let’s go through some of the very specific kinds of feedback that actually get published into this feedback river.
So the first one is NPS…
That’s one example of what we’re feeding into the feedback river.
Another one is our ‘cancelling the account’ reason. So within Notejoy if you cancel the account before you’re allowed to cancel the account we give you a little text box that asks you why you cancelled. Every user is required to fill this out. And actually as you’d expect many times you get garbage. People just tell you, ‘no reason’ or they just type ‘asdf’ but sometimes you get some gems where they’re actually telling you why they decided to cancel….
What’s exciting about this is that these feedback river elements not only become opportunities for us to learn but actually become real time opportunities for us to engage with our customers…
We also have this ‘comment feedback’ button within Notejoy that at any point you can press it and just say whatever you want. We encourage people to do it.
We’ve also built something called a ‘feature request tracker,’ so anytime anyone upvotes a feature that comes directly into our feedback river. So we’re getting real-time insight about what customers want.
And it turns out when you make it easier for people to just upvote on something as opposed to having to send you a ‘contact us’ form and giving you feedback, you get way more signals.
It’s been amazing how much feedback we’ve gotten in from going from an open text box, ‘send us feedback,’ to now having a structured way for people to give us feedback. And participate, almost as a community, in where they’d like to see our product go.
Here’s another interesting one which we find pretty valuable, which is the ‘help search’ queries. So one of the things we all aspire to do when we’re building our product is to build products that don’t need documentation. And that should definitely always be goal no. #1.
And we want to get there. Turns out we don’t always get there. But when we don’t, we want to make sure we have an incredible experience for people to self-serve and understand how to use your product more deeply. And so one of the ways we’ve been judicious about building is by piping every search query that someone executes within Notejoy’s help centre into the feedback river.
What we do with this is that one of us on the team always goes and executes that query against our search results, in our help centre and makes sure we’re happy with the quality of the results. That the ranking of the content that’s most likely relevant shows up high. We’ve done this with every search query that’s happened within Notejoy. And usually within 48-72 hrs if there’s a gap we’ve created content, so that the next time someone searches for that search term, there’s now great content.
We started the Slack community super early on when we were still in beta. I’m part of some Slack communities, for example, our investors interact through a slack community. So we thought it would be a good way to easily talk to customers as we built out the product. We’re building relationships as opposed to the normal ticketing system for support.
The community members are early adopters that want to share stuff, so it’s a really good way to get to learn from people. We’re getting constant feedback through the community. It’s also a good place to test out features and tell people: “Hey, this is what we’ve been thinking of”…
The hard thing is that you have to provide a certain level of service. We hang out in the Slack but have to be careful it doesn’t become a support channel since we can’t be there all the time. For support, we have a VideoAsk and that allows us to stay responsive to for example users paying for priority support. The principle: If we’re around and can answer your question, we’ll answer, otherwise, try talking to other members as well. We’re starting to see people actually helping each other* out inside the community…
Getting other people involved helps shape your ideas. But you can spend a lot of time going to customer interviews, digesting all that and trying to crunch data. It can be valuable, but I personally just use it as input into my thought process to make the right decisions…
The people that join the slack community really like the product, want to be involved, and stay close to the team that is building it. It’s a certain type of person who will give good feedback and such. It’s a bit biased, actually, because you’re not getting feedback from the not so techie person that might be just *stuck in the onboarding funnel because they just don’t get it.
We don’t encourage joining the community too much because then there will be too many people. There are nearly 1000 people in it at this point, I don’t think we need that many to be completely honest. But we keep it open as long as it’s useful and manageable. This way it’s a good place to launch features early on and get great feedback if something is not quite right…
Keeping our product roadmap public is the roux to our secret sauce.
There’s always an up-to-date, high-level version of our roadmap available online that anyone can look at—including customers, leads, and potential partners.
Our public-facing roadmap—which an early customer requested—is an open invitation for customers to share their feature requests and suggestions. It opens up a line conversation that we would never have otherwise.
We use it as an opportunity to find out what they’re looking for and what problem they’re trying to solve.
Sometimes, we can work up a solution within our existing product. Other times, their feedback helps us shape product features in our pipeline.
There’s always a kernel of truth in something if someone puts the time into saying it.
All feedback is good feedback, even an angry ALL-CAPS RANT!
But not all customer feedback is equal. Some customers are able to give you really strong insights that end up shaping a feature’s future. Maybe they present a compelling use case you hadn’t considered, or perhaps they’re willing to pay upfront for functionality you planned to build anyway.
Like our impromptu Trello integration, sometimes feedback and timing work together to create a golden opportunity.
Keep your eyes open for those gems. There’s nothing wrong with veering a little off course to make a customer happy, especially if it will benefit other customers too.
Founder notes on the thinking that should inform feedback systems:
(featuring the nuances of NPS comments, the when and where of feedback, and how not to get drunk on customer ideas)
One of the biggest challenge for NPS surveys is that somebody can say, ‘I’m going to give you a score of two,’ which is a detractor, but their comment might say, ‘I gave you two because, you don’t have this feature that I want, but I really really love your service.’
So that’s like, okay, what does that mean, are you happy or not happy? So those are difficult to gather so you cannot guide the analysis only by the score. You have to guide the analysis with ultimately what is the driver of the customer. So there’s something there, but overall their experience is good, so you can group that request among other requests that might be similar, as opposed to saying, ‘because we don’t have this feature, people are angry at us and they aren’t going to recommend us.’
It is about having a bit of interpretation behind it and when we quantify feedback, all we’re trying to do is to try to understand commonalities of what people say but that doesn’t mean we’re trying to find commonalities behind why people say it. And that’s what I want to emphasise over and over again. You have to do the job of understanding why people say that.
#2: Intercom’s co-founder and CSO, Des Traynor, on meticulously documenting the when and where of customer feedback (source):
So when you’re getting good product feedback, make sure you’re recording the basics.
Who is the user – are they a free or paying customer? Active or inactive?
When did they say this – was it on their first session? Or their 300th?
What are they saying – was it a feature request? Or a bug report?
Where are they saying it – was it on the “teams” page? Or on the “new project” page?
How are they saying it – are they positive or negative? Patient or urgent?
Every piece of feedback contains so much information. It’s a mistake to only index on one.
Be way more stringent and diligent about segmenting customer feedback. It’s wonderful to get customer ideas and feedback, whatever else, but it can also be intoxicating and I think I got a little bit drunk on all of the feedback and said, ‘yeah, we should try this and try that.’ So I think being a bit more sober about how to evaluate feedback, particularly about segmentation…
For example, we definitely got some interest from agencies early on who wanted to use this as a way of communicating data to their clients. And I thought, well, this is a great use case, but actually when we started digging into it, it needed a huge amount of custom work because of their data sources…
One of the tenets of our product is that we try and make visualisations that are designed for human visual systems, our visual cortex and how that works, and I remember we were quite strict about that. We wanted to make it easy to understand at a glance, not take a little while to understand. I remember one of my early conversations with an agency and them saying, ‘but our clients really like gauges, can you give me a gauge with two dials on it.’
I felt like we were dragged into a rabbit hole after rabbit hole; it was a section of the market with its very own specific needs that we would not have been able to meet at least not at scale. Yes, we did end up building stuff, wasting time, doing all sorts of crazy one-off initiatives, while there was a very real opportunity cost associated with that.