For several years, Kayako was a small side project run by Varun and myself. We are bootstrapped and have built everything on our own – we built the platform, ran the business-side of things and, most fun of all, handled customer feedback and complaints. This will be a familiar story to many of you.
Handling a flood of customer feedback is overwhelming when you’re on a big, established team, let alone managing a company.
As a growing startup with thousands of customers, we needed to make use of valuable feedback to grow our product, while providing our customers with a great experience.
When the customer requests started piling up on our to-do list, we knew we needed a better solution to be more effective in how we managed customer feedback.
The problem with managing customer feedback
When we weren’t filtering and prioritizing feedback effectively, we started to develop a pile of feature requests. In many cases, we ended up directly implementing what the customer asked for, only to realize it wasn’t right for us… or even the customer!
I remember one particularly embarrassing feedback misstep we made, which lives in Kayako today.
Kayako customer service software is used by our customers to have conversations with their customers over any channel. When it comes to managing these conversations, Kayako presents conversations much like in an inbox: threaded support tickets which you can open and scroll through messages chronologically.
A popular feature request which we would hear often was a need to be able to add private replies to a ticket, which wouldn’t be visible to the customer. This would be a lot of work; it required significant changes across Kayako. The feature request attracted a number of votes over time, and customers grew impatient.
So we went ahead and implemented the feature request, making several customers happy in the process.
A couple of years later, while performing an end-to-end user experience review, we evaluated private ticket replies. We were confused about why they were there – why couldn’t agents simply use ticket notes, which are also private, belong to tickets and have been there since the dawn of time?
We dug into the conversations customers had with our support team to find out what exactly they wanted to achieve when asking for private ticket replies.
It turns out that all customers wanted was for ticket notes to appear chronologically and inline in the ticket. At the time, ticket notes were simply pinned to the top of a conversation at all times.
After all that, it turns out we could have simply made the existing ticket notes appear inline in the ticket, rather than inventing something completely new and convoluted to achieve the same thing.
The mistake we made was to accept the feature requests at face value: a rush to implement fast and a rush to make our customers happy.
Had we uncovered the customer’s root goal in this example, we would have implemented something much more elegant, easier for new customers to understand and easier for us to maintain. Instead, we didn’t nurture the feedback we received or take the time understand the use case and the root problem or goal that the customer wanted us to address.
It turns out that a customer doesn’t have the time or necessarily the expertise to think as holistically as a product manager and product designer does. What they ask for is very often not what they want.
For most customers, all they can realistically do is think superficially and therefore submit superficial feature requests, for a setting here, an exception there. The result is superficial implementations and layers upon layers of new settings and tweaks, rather than well thought out and well designed user journeys to achieve goals.
Customers just want their problem solved, and it’s not always necessary to do it with the solution they suggest. It’s not enough to just take the feedback at face value. It’s crucial to ask the right questions and dig deeper to find the root cause.
The 5 Whys
Around the same time as Kayako was really starting to grow, there was renewed interest in the product development world around the 5 Whys, a management concept developed by Toyota Motor Corp. Created in the 1950s, the 5 Whys concept was coined to help engineers get to the root cause of manufacturing errors. (You can read more about that here.)
Essentially, by asking “why” five times, you’re able to tease out the real root cause so not only can you fix the symptoms of a problem, but you’re able to make the changes needed to kill the underlying issue for good.
In the tech world, the 5 Whys technique has reemerged, favored by sysadmins and coders alike who used it to discover the real root of the problem following the belief that “people don’t fail, processes do.” When a company has really screwed something up, using the 5 Whys concept can help them find a solution to, and prevent, the underlying issue in the future.
This is what it looked like when Buffer did it following a system-wide outage:
Peeling back the layers opened up these undiscovered links between problems and their causes. What looked like a standalone issue, was actually caused by several process issues – and without doing the 5 Whys, these issues might have occurred again.
While the 5 Whys are known to work wonders for technical or process fail post-mortems, they can also be useful to getting to the bottom of customer feedback requests.
Using the 5 Whys to manage customer feedback
Let’s go back to the deluge of requests we were getting from our customers. This backlog of ideas was frustrating for me, because we weren’t able to filter through the noise for features that we should actually implement.
Customers were frustrated because their ideas weren’t getting incorporated fast enough. It wasn’t a good situation for anyone. We needed a better way to categorize feedback and tease out the needs of customers, not just the wants. It was time to implement the 5 Whys.
When a customer requests a new feature, we now take the time to ask “why?”, not just once, but multiple times. Sometimes we ask this question with our inner voice: “Why would the customer be asking for this?” Other times, it might be a conversation with the customer: “What would you like to do with that feature?” or “What goals would having that functionality help you accomplish?”
When we started applying the 5 Whys to dig deeper into customer feedback, our team discovered three trends:
- Many feature requests were already in Kayako, the customers just didn’t know where to look.
- Some feature requests were bugs or problems we could troubleshoot.
- Less than 10% of feedback was actually a valuable and viable feature request.
For example, a customer recently asked us to add individual view permission settings to public support center articles, so they could granularly control who could see which article in their public support center. This would be an involved and large implementation task, so we dug deeper.
1. Customer: I need to be able to set view permissions for each of my articles in our public support center.
a. Kayako: Why do you need to be able to set view permissions to individual articles?
2. Customer: So that I can control who can see my articles, per-article.
a. Kayako: Why do you need to control who can see your support center articles?
3. Customer: Because sometimes I don’t want customers to see support center articles.
a. Kayako: Why and in which sort of cases do you not want your customers to see your support center articles?
4. Customer: Because sometimes it takes us a few days to draft an article together, and a support center article isn’t ready to go public.
a. Kayako: I see. It sounds like a ‘Save article as draft’ option, which would save your in progress article, but keep it hidden from your customers until you ‘Publish’ your article, would do the job?
5. Customer: Yes, that would work too.
In this case, it only took us four whys to understand that the customer’s pain point, their goal and that both could be satisfied with a much simpler feature improvement, rather than a big, new permissions system.
When we incorporated the 5 Whys methodology, we found we were adding fewer items to the backlog, and actually solving more customers problems with greater elegance. After a little digging, we could better characterize problems and fix them right then and there – one less item to add to the backlog, and one more customer who was helped immediately.
Talking to your customers is truly insightful
Taking the time to dive deeper into a customer’s feedback means you can gain more insight. You can open up a line of communication, show you’re really listening, and demonstrate that you’re thinking about what they need. This email Adii Pienaar, founder of the early stage startup, Receiptful, sends to customers is perfect:
Hi Sally,
Unfortunately Receiptful can’t do that at the moment.
Can you perhaps explain what you were hoping to achieve though (in the event that Receiptful did support that feature)? If you let me know, I can possibly recommend a workaround or alternative solution. 🙂
This makes you part support, part investigator and part negotiator. And this is how customer feedback must be done. Anything less just leaves the support team with a growing complaint repository and no value added anywhere.
Conclusion
Dig deeper (five times deeper!) when customers ask for a feature to see what they really need. Not only will you get to know your customer better, you’ll also be able to scale your customer feedback more effectively.
At Kayako, we now have a deeper understanding of our customers’ needs, and have got our pile of product feedback under control. Time to take over the world! Just kidding, we’ve still got a long way to go.
How does your company deal with the flood of feature requests?
